From sip-admin@lists.bell-labs.com Thu Jun 1 00:31: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 AAA04365 for ; Thu, 1 Jun 2000 00: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 1552D44370; Thu, 1 Jun 2000 00:21:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6AFFC44337 for ; Thu, 1 Jun 2000 00:21:47 -0400 (EDT) Received: from dynamicsoft.com (1Cust28.tnt2.freehold.nj.da.uu.net [63.17.114.28]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA08173; Thu, 1 Jun 2000 00:28:23 -0400 (EDT) Message-ID: <3935E618.7DA5F8F4@dynamicsoft.com> Date: Thu, 01 Jun 2000 00:27:04 -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: "Paul E. Jones" , Plong@smithmicro.com, dwillis@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions References: <000b01bfca41$99f4b760$6701a8c0@plong> <39343C9C.F79563C0@dynamicsoft.com> <019501bfcac3$f8e00e50$0401a8c0@mds.local> <3934A96D.C353848A@dynamicsoft.com> <3934CA1E.5F3F4B3A@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 This is just my error; I made the statement without checking. So zero lines is fine as far as SDP is concerned. Even within SIP, I had forgotten about this tidbit in rfc2543: > B.4 Delayed Media Streams > > In some cases, a caller may not know the set of media formats which > it can support at the time it would like to issue an invitation. This > is the case when the caller is actually a gateway to another protocol > which performs media format negotiation after call setup. When this > occurs, a caller MAY issue an INVITE with a session description that > contains no media lines. See, thats what happens when you always post at 3 in the morning ;) -Jonathan R. James Undery wrote: > > Jonathan Rosenberg wrote: > > > Sorry; I meant at least a single m line (i.e., zero m lines not > > allowed). > > > > 4th paragraph of section 6 of RFC 2327 starts "An announcement consists of a > session-level section followed by zero or more media-level sections". While this > may be useful in a generic case the lack of media means the it is of no use to > SIP. I would suggest adding a line along the lines of, SDP used in SIP must > contain one or more media-level descriptions, to the bis draft. (Obviously > reworded to avoid my awkward prose ;^) ) > > James Undery -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 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 Jun 1 00:32: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 AAA04384 for ; Thu, 1 Jun 2000 00:32: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 3BE0E44381; Thu, 1 Jun 2000 00:23:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CFAEB44380 for ; Thu, 1 Jun 2000 00:23:18 -0400 (EDT) Received: from dynamicsoft.com (1Cust28.tnt2.freehold.nj.da.uu.net [63.17.114.28]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA08177; Thu, 1 Jun 2000 00:30:07 -0400 (EDT) Message-ID: <3935E680.B7598DA4@dynamicsoft.com> Date: Thu, 01 Jun 2000 00:28:48 -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: Scott Hoffpauir , sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server References: <3933EEB2.893C06AB@ubiquity.net> <39343EDC.2B4005FD@dynamicsoft.com> <3934CA2C.F4538AD5@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: > > Jonathan I agree that a service logic enhanced Proxy Server is an application server. > > However, I am not yet convinced this sits in complete harmony with the ISC App WG's > intention to separate the call signalling (Proxy/Softswitch) and service control (App > Server) and use standard RFC2543 SIP as the interface between them. In the case of > the service logic enhanced proxy isn't the interface between vanilla proxy and the > service control defined by CPL/SIP-CGI/Servlet API etc not RFC2543 SIP. No; the "vanilla proxy" speaks SIP to the application server, which is just a smarter proxy (or redirect server or whatever). This app server, internally, may use any number of APIs, including the ones you mention. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 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 Jun 1 01:04: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 BAA04621 for ; Thu, 1 Jun 2000 01:04: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 2CC214437F; Thu, 1 Jun 2000 00:55:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A82BD44337 for ; Thu, 1 Jun 2000 00:55:01 -0400 (EDT) Received: from dynamicsoft.com (1Cust28.tnt2.freehold.nj.da.uu.net [63.17.114.28]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA08248; Thu, 1 Jun 2000 01:05:06 -0400 (EDT) Message-ID: <3935EEB2.64525712@dynamicsoft.com> Date: Thu, 01 Jun 2000 01:03:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Schroeder, Tim" Cc: "'sip@lists.bell-labs.com'" Subject: Re: FW: [SIP] wg last call on reliable provisional responses References: <4D45BA2A58A7D3119E050008C7E69E290790E1@trimail2.tri.sbc.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 "Schroeder, Tim" wrote: > > James Undery writes: > I think what is being hinted at albeit subtlety is, is the transaction ever > going to end? (The Halting Problem.) Although I can't think of a case off > hand where you'd want to provisionally respond to a PRACK, specifically > allowing it is just asking for trouble between legitimate implementations. > [...] Except it may spawn another PRACK that spawns another PRACK ad > infinitum. I'd still argue that this just means you have a buggy server. Reliable provisionals are not sent "just for fun" - it is usually for a reason. So, the case I was considering was where the first PRACK had some special data in a provisional response that needs to be sent reliably. This data would itself be acknowledged with a PRACK, but there is no reason for the second PRACK to have a reliable provisional response. That said, if no one has any applications for this, and people think that folks will just get into trouble with it, I'll remove that. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 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 Jun 1 01:46: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 BAA10085 for ; Thu, 1 Jun 2000 01:46: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 30FCE4435C; Thu, 1 Jun 2000 01:36:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 911464434D for ; Thu, 1 Jun 2000 01:36:24 -0400 (EDT) Received: from dynamicsoft.com (1Cust28.tnt2.freehold.nj.da.uu.net [63.17.114.28]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA08290; Thu, 1 Jun 2000 01:46:31 -0400 (EDT) Message-ID: <3935F868.38C149C8@dynamicsoft.com> Date: Thu, 01 Jun 2000 01:45:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Schroeder, Tim" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] comments on draft-ietf-sip-100rel-01.txt References: <4D45BA2A58A7D3119E050008C7E69E290790DF@trimail2.tri.sbc.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 Thanks for your comments. Responses below: "Schroeder, Tim" wrote: > > Section 3, Paragraph 1: "Note that a UAS MUST NOT send a response reliably > unless there was a Supported header in the request indicating support for > this extension." > > This should be "... unless there was a Supported or Require header in the > request indicating support for this extension." Fixed. > > ----- > > Section 3, Paragraph 3: "The UAC can determine that the response is to be > transmitted reliably by the presence of the RSeq header." > > I believe this should read "... by the presence of a Require header > containing the option tag 100rel." The use of the Require header in the > response is mandated (correctly, in my opinion) by Section 5.2, Paragraph 6 > (UAS behavior). This also follows draft-ietf-sip-serverfeatures-02.txt > which "allows for the Require header to appear in responses. It is used to > indicate what options must be understood by the UAC in order to process the > response." > In general, I think it's best to explicitly state what extensions/features > are being used, rather than having the user agent deduce them from the > presence/absence of headers. This also will allow the Rseq header to be > reused in other extensions where it might make sense, rather than having to > create another extension-specific header. Good point. Fixed. > > ----- > > Section 5.1, Paragraph 2: "The rest of this discussion assumes this header > has been inserted into a request." > > This should read "... one of these headers has been inserted ...". The > previous paragraph was improved to allow for the UAC to insert either the > Supported header or the Require header, and this sentence needs to follow > suit. Fixed. > > ----- > > Section 5.1, Paragraph 11: "It is not necessary to include the Supported > header listing the option tag 100rel in the PRACK request." > > I disagree. Given that the UAS may try to send reliable provisional > responses to a PRACK (it's mentioned, and seems reasonable for completeness, > though I don't see an obvious use of this), I think the UAC ought to say > whether it supports or requires the 100rel feature. Yes, the UAS can deduce > that the feature is supported by the presence of the PRACK method, but (1) > the UAS cannot tell from the existence of the PRACK method whether the UAC > *requires* or merely *supports* the 100rel feature, and (2) the PRACK method > could never be used in support of any other feature. (2) might not be much > of a problem, but I think either a Require or Supported header is needed to > address (1). Mandating the header would also make PRACK more consistent > with the other methods, all of which mandate either the Require or Supported > header. Given the change that you can't send a reliable provisional response to PRACK, it seems this text is actually fine - its not needed to include this Supported header in PRACK. > > ----- > > Section 5.2, Paragraph 1: "The UAS may send any provisional response > reliably, so long as the initial request contained a Supported header > indicating that this feature is understood." > > This should read "... the initial request contained either a Supported or > Require header indicating that this feature is understood." Actually, not quite, since the strengths are different. It now reads: The UAS \MAY send any provisional response reliably, so long as the initial request contained a \header{Supported} header indicating that this feature is understood. The UAS \MUST send any non-100 response reliably if the initial request contained a \header{Require} header indicating that the feature is mandatory for all provisional responses. If the UAS is unwilling to do so, it \MUST reject the initial request with a 420 (Bad Extension) and include a \header{Unsupported} header containing the option tag {\sf 100rel}. > > ----- > > Lastly (and maybe I've missed my chance on this one, since the "open issue" > section went away), did we ever come up with an application where the > cumulative response mechanism was needed? I thought we had come to > consensus to drop it unless there was a demonstrated need (which I haven't > seen, though I may have just missed it). At the meeting, I thought we had decided to keep it, but there wasn't a whole lot of comment, and I am willing to entertain arguments for removing it. I can think of applications where its useful (using provisionals for call queue status, and having several changes all sent in rapid succession). > > The UAC must PRACK a provisional response, which seems to disallow > accumulating responses in the hopes of sending one PRACK for the group. That is a good point, and we would need to change that to SHOULD if this mechanism stays. > Only if a provisional response arrives which is known to be out-of-sequence, > and only if it is then cached by the UAC, and only if the previous missing > response then arrives, does it seem that the cumulative response mechanism > could come into play. The examples section uses "two provisional responses > in rapid succession" to address this, but I'm not sure that's sufficient. > When the first response arrives, I read section 5.1 (UAC behavior) to > require that the UAC construct and send a PRACK; I'm not sure waiting around > to see if another response arrives before doing so is reasonable -- it would > delay the acknowledgement of the first response in the usually vain hope > that another response would quickly arrive. THis is no different than data buffering in any stream oriented protocol - you wait for so long and then send. Maybe if the two responses were > sent together in a single UDP packet, the cumulative response would be > justified? > > Also, the last paragraph of section 3 and the penultimate paragraph of > section 5.2 both recommend that a UAS wait for acknowledgement of a > provisional response before sending the next one. Any UAS following this > recommended procedure would certainly never need the cumulative response > mechanism. The mechanism is for the benefit of the UAC, in the case where this recommendation is not followed. > > I'd take out all the verbiage dealing with the cumulative responses, in the > interests of simplicity and clarity. Any other opinions on this? > There'd no longer need to be any > difference in handling between the first reliable response (which cannot be > part of a cumulative group because of the need to agree on the first Rseq) > and any further reliable responses. I think that is a different issue. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 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 Jun 1 04:21: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 EAA17630 for ; Thu, 1 Jun 2000 04:21: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 3199C44362; Thu, 1 Jun 2000 04:11:43 -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 7A03044337 for ; Thu, 1 Jun 2000 04:11:37 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA27520; Thu, 1 Jun 2000 09:18:21 +0100 (BST) Message-ID: <39361C51.5C5974A7@ubiquity.net> Date: Thu, 01 Jun 2000 09:18:25 +0100 From: James Undery X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Schroeder, Tim" , "'sip@lists.bell-labs.com'" Subject: Re: FW: [SIP] wg last call on reliable provisional responses References: <4D45BA2A58A7D3119E050008C7E69E290790E1@trimail2.tri.sbc.com> <3935EEB2.64525712@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: > "Schroeder, Tim" wrote: > > > > James Undery writes: > > I think what is being hinted at albeit subtlety is, is the transaction ever > > going to end? (The Halting Problem.) Although I can't think of a case off > > hand where you'd want to provisionally respond to a PRACK, specifically > > allowing it is just asking for trouble between legitimate implementations. > > [...] Except it may spawn another PRACK that spawns another PRACK ad > > infinitum. > > I'd still argue that this just means you have a buggy server. Reliable > provisionals are not sent "just for fun" - it is usually for a reason. > So, the case I was considering was where the first PRACK had some > special data in a provisional response that needs to be sent reliably. > This data would itself be acknowledged with a PRACK, but there is no > reason for the second PRACK to have a reliable provisional response. My argument is the two entities aren't buggy because, you may decide the second PRACK can't contain data that requires a reliable provisional response, but how do you know some application won't. Personally I can't see the need for provisional responses to a PRACK except 100 (which can't be sent reliably anyway) and you know the final response will get there (or else you've bigger problems anyway). > > > That said, if no one has any applications for this, and people think > that folks will just get into trouble with it, I'll remove that. > 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 Jun 1 04:26: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 EAA17645 for ; Thu, 1 Jun 2000 04:26: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 5E53544358; Thu, 1 Jun 2000 04:17: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 978FC44351 for ; Thu, 1 Jun 2000 04:17:02 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA29924; Thu, 1 Jun 2000 09:24:16 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Rick Workman" , Sip Mail List Subject: Re: [SIP] SipUrl header BNF incorrect in bis Date: Thu, 1 Jun 2000 09:06:46 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <00053116384000.31243@gethin> <393548F0.201A5BF9@americasm01.nt.com> In-Reply-To: <393548F0.201A5BF9@americasm01.nt.com> MIME-Version: 1.0 Message-Id: <00060109230100.32012@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 with Rick here :) The quotation marks (") have been removed per the discussion, the use of the term "reserved" has been changed to un-reserved and the use of escaped characters has been clarified because of this. However, i also thought the "," should have been removed and the "[" and "]" added. I think there was just an error in transcribing all the information into the new bis. can we get final clarity on this matter? thanx gethin On Wed, 31 May 2000, Rick Workman wrote: > > Further to Gethin's point, an earlier discussion on the unreserved characters > for paramaters and headers doesn't seem to have been accuarately captured in the > May bis. I think the two key requirements for these character sets are 1) they > should be subsets of the URL reserved character set (ref RFC 2396/2732), and 2) > they should avoid any characters which would cause ambiguities in the SIP > grammar. > > 1. It was discussed that "," should not be included in param-unreserved (and by > extension with hnv-unreserved) "because URLs are allowed in certain headers and > allowing commas in SIP URLs will make parsing those headers sometime > impossible.". I thought this point was accepted, but maybe I missed something. > > 2. RFC 2732 adds "[" and "]" to the URL reserved set to support IPv6 address > syntax. As a consequence, I think these should also be added to param-unreserved > and hnv-unreserved, since I don't think they cause any ambiguity issues. > > -- 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 mailman-owner@lists.bell-labs.com Thu Jun 1 05:30: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 FAA17995 for ; Thu, 1 Jun 2000 05:30:21 -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 03EBC44818 for ; Thu, 1 Jun 2000 05:07:02 -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: <20000601090703.03EBC44818@lists.bell-labs.com> Date: Thu, 1 Jun 2000 05:07:03 -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 Thu Jun 1 06:10: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 GAA18239 for ; Thu, 1 Jun 2000 06:10: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 D232744343; Thu, 1 Jun 2000 06:01:19 -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 49D4144337 for ; Thu, 1 Jun 2000 06:01:10 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA06531; Thu, 1 Jun 2000 11:07:18 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Henning Schulzrinne , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Case sensitivity Date: Thu, 1 Jun 2000 10:43:19 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <3908D34E.58792A22@dynamicsoft.com> <390D8F1F.EE1C1F4E@dynamicsoft.com> <390D9531.B81CA74D@cs.columbia.edu> In-Reply-To: <390D9531.B81CA74D@cs.columbia.edu> MIME-Version: 1.0 Message-Id: <00060111060102.32012@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 Hi people. I hate to go over this topic time after time and appologize in advance for bringing it up again but I have to query the case sensitivity issue of the "user" element in the Sip URL. This message is in fact in response to Henning's posting one month ago (to the day!!) and again i appologise, this time for the lateness of this posting. My query arrises because of the examples given in the bis Section 2 after table 2. we have the example sip:alice%40example.com@gateway.com now this will be used, i suspect, by the gateway to convert to alice@example.com within the gateway.com domain. So the example.com has now become a host, which is case-insensitive (CI). however the user is compared case-sensitive (CS). so: sip:alice%40EXAMPLE.com@gateway.com will not equate to the former even though the gateway.com considers both to be the same. is this a problem? should the user not be CI as well as the host? then what if alice has a password? sip:alice%3Apassword%40example.com@gateway.com This would have to be CI as well. But then passwords are more often than not CS!!! i fear i may be over-concerned about this and worrying about nothing. i.e. what the gateway.com does is out of the scope of SIP and not our concern any thoughts? On Mon, 01 May 2000, Henning Schulzrinne wrote: > I believe we need to take a closer look at the annoying topic of > case-sensitivity (or not). > > A rough summary is: > > Method CS > Header field name CI > Any Accept-* token CI (includes compression, language, media type) > SDP encoding name CI (such as PCMU, L16, etc.) > URL mostly CS (except host) > > Some additional issues: > (1) Parameters like ;level or ;q in Accept. Are ;LEVEL and ;Q the same > thing? RFC 2616 seems to indicate this: > > 3.7: > > The type, subtype, and parameter attribute names are case- > insensitive. Parameter values might or might not be case-sensitive, > depending on the semantics of the parameter name. > > 2.1 Augmented BNF > > "literal" > Quotation marks surround literal text. Unless stated otherwise, > the text is case-insensitive. > > [This would apply to most enumerated parameters, like "hop" or "hide" > tokens in our case, or the "action" tokens in Contact or > Content-Disposition or the Priority values.] > > My general impression is that HTTP/1.x seems to treat tokens not > enclosed in quotation marks as CI and anything in quotation marks as CS, > with URLs as a separate matter. > > (2) HTTP-date (and, thus, rfc1123-date) is case sensitive. > > Any other cases? > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > _______________________________________________ > 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 Thu Jun 1 06: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 GAA18282 for ; Thu, 1 Jun 2000 06: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 D5E7F4434D; Thu, 1 Jun 2000 06:16: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 DEBE244337 for ; Thu, 1 Jun 2000 06:16:46 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA14028; Thu, 1 Jun 2000 11:23:16 +0100 (BST) Message-ID: <39363991.882283F9@ubiquity.net> Date: Thu, 01 Jun 2000 11:23:13 +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: Jonathan Rosenberg Cc: Scott Hoffpauir , sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server References: <3933EEB2.893C06AB@ubiquity.net> <39343EDC.2B4005FD@dynamicsoft.com> <3934CA2C.F4538AD5@ubiquity.net> <3935E680.B7598DA4@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: > Neil Deason wrote: > > > > Jonathan I agree that a service logic enhanced Proxy Server is an application server. > > > > However, I am not yet convinced this sits in complete harmony with the ISC App WG's > > intention to separate the call signalling (Proxy/Softswitch) and service control (App > > Server) and use standard RFC2543 SIP as the interface between them. In the case of > > the service logic enhanced proxy isn't the interface between vanilla proxy and the > > service control defined by CPL/SIP-CGI/Servlet API etc not RFC2543 SIP. > > No; the "vanilla proxy" speaks SIP to the application server, which is > just a smarter proxy (or redirect server or whatever). This app server, > internally, may use any number of APIs, including the ones you mention. Yes of course a separate SIP network element can talk SIP to a smart proxy/application server. But the point I was trying to make is that the application server encapsulates a vanilla proxy server, i.e. the proxy functionality as described by rfc2543, plus service logic accessed through CPL/SIP-CGI/Servlet API/whatever. My difficulty is in seeing how this fits with the ISC application working group premise of separating call signalling from service control via a SIP messaging interface. This seems like an unnecessary IN model of separation. In the App Server the proxy part does signalling but it is clearly not separated from controlling service logic by a SIP messaging interface. 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 Jun 1 07:02: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 HAA19083 for ; Thu, 1 Jun 2000 07:02: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 20ECD44358; Thu, 1 Jun 2000 06:52:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out5.prserv.net [32.97.166.35]) by lists.bell-labs.com (Postfix) with ESMTP id 7420B44337 for ; Thu, 1 Jun 2000 06:52:34 -0400 (EDT) Received: from cs.columbia.edu ([129.37.167.69]) by prserv.net (out5) with SMTP id <2000060111011324300m4457e>; Thu, 1 Jun 2000 11:01:13 +0000 Message-ID: <39364473.EEDB9B2E@cs.columbia.edu> Date: Thu, 01 Jun 2000 07:09:39 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Henning Schulzrinne , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Case sensitivity References: <3908D34E.58792A22@dynamicsoft.com> <390D8F1F.EE1C1F4E@dynamicsoft.com> <390D9531.B81CA74D@cs.columbia.edu> <00060111060102.32012@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 I agree that we're now getting into one of the more arcane areas. The reason that user names are CS is that they are CS in a number of operating systems and that RFC 822 defines local-part (the local name) to be CS. It is then up to the gateway to treat a user name like foo@bar appropriately. The CI/CS only matters for comparing registrations, for example, where this form is not likely to occur in any event. Gethin Liddell wrote: > > Hi people. > > I hate to go over this topic time after time and appologize in advance for > bringing it up again but I have to query the case sensitivity issue of the > "user" element in the Sip URL. > > This message is in fact in response to Henning's posting one month ago > (to the day!!) and again i appologise, this time for the lateness of this posting. > > My query arrises because of the examples given in the bis Section 2 after table 2. > > we have the example > > sip:alice%40example.com@gateway.com > > now this will be used, i suspect, by the gateway to convert to alice@example.com within > the gateway.com domain. So the example.com has now become a host, which is > case-insensitive (CI). however the user is compared case-sensitive (CS). > > so: > > sip:alice%40EXAMPLE.com@gateway.com > > will not equate to the former even though the gateway.com considers both to be the same. > > is this a problem? > should the user not be CI as well as the host? > then what if alice has a password? > > sip:alice%3Apassword%40example.com@gateway.com > > This would have to be CI as well. But then passwords > are more often than not CS!!! > > i fear i may be over-concerned about this and worrying about nothing. > i.e. what the gateway.com does is out of the scope of SIP and not our concern > > any thoughts? > > On Mon, 01 May 2000, Henning Schulzrinne wrote: > > I believe we need to take a closer look at the annoying topic of > > case-sensitivity (or not). > > > > A rough summary is: > > > > Method CS > > Header field name CI > > Any Accept-* token CI (includes compression, language, media type) > > SDP encoding name CI (such as PCMU, L16, etc.) > > URL mostly CS (except host) > > > > Some additional issues: > > (1) Parameters like ;level or ;q in Accept. Are ;LEVEL and ;Q the same > > thing? RFC 2616 seems to indicate this: > > > > 3.7: > > > > The type, subtype, and parameter attribute names are case- > > insensitive. Parameter values might or might not be case-sensitive, > > depending on the semantics of the parameter name. > > > > 2.1 Augmented BNF > > > > "literal" > > Quotation marks surround literal text. Unless stated otherwise, > > the text is case-insensitive. > > > > [This would apply to most enumerated parameters, like "hop" or "hide" > > tokens in our case, or the "action" tokens in Contact or > > Content-Disposition or the Priority values.] > > > > My general impression is that HTTP/1.x seems to treat tokens not > > enclosed in quotation marks as CI and anything in quotation marks as CS, > > with URLs as a separate matter. > > > > (2) HTTP-date (and, thus, rfc1123-date) is case sensitive. > > > > Any other cases? > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > _______________________________________________ > > 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 09:12: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 JAA22513 for ; Thu, 1 Jun 2000 09:12: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 2B1134434D; Thu, 1 Jun 2000 09:02:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id 700E144337 for ; Thu, 1 Jun 2000 09:02:39 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA11393 for ; Thu, 1 Jun 2000 19:27:22 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568F1.00493643 ; Thu, 1 Jun 2000 18:49:39 +0530 X-Lotus-FromDomain: HSSBLR From: bborthakur@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <652568F1.0049333A.00@sampark.hss.hns.com> Date: Thu, 1 Jun 2000 18:17:43 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] retransmission of BYE OPTIONS REGISTER request by proxies Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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! Section 10.4.1 states of the SIP draft states that a client using UDP should retransmit BYE CANCEL OPTION and REGISTER requests. Does this mean proxy servers dont retransmit them. If so what happens in a scenario like this: Client A connects to proxy P on TCP and sends a BYE. P connects to client B on UDP. Since A does not retransmit the BYE how can reliablity be achieved unless proxy P retransmits. thanks bhaskar _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 09:14: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 JAA22542 for ; Thu, 1 Jun 2000 09:14: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 BC0E344379; Thu, 1 Jun 2000 09:05:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uni03mr.unity.ncsu.edu (uni03mr.unity.ncsu.edu [152.1.1.166]) by lists.bell-labs.com (Postfix) with ESMTP id ED8C844376 for ; Thu, 1 Jun 2000 09:05:18 -0400 (EDT) Received: from unity.ncsu.edu (n01043-lau1.unity.ncsu.edu [152.1.112.43]) by uni03mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with ESMTP id JAA04551 for ; Thu, 1 Jun 2000 09:13:19 -0400 (EDT) Message-ID: <393661C3.3FC7F3D6@unity.ncsu.edu> Date: Thu, 01 Jun 2000 09:14:43 -0400 From: Mahesh Shankar 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] CPL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 was wondering if the CPL allows dynamic creation of services, or is that capability not part of the CPL's functionality ? Thanks. -M -- _________________________________________________________________________ If opportunity doesn't knock, build a door _________________________________________________________________________ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 09:20: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 JAA22669 for ; Thu, 1 Jun 2000 09:20: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 5125C44374; Thu, 1 Jun 2000 09:11: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 33B8A44358 for ; Thu, 1 Jun 2000 09:10:51 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA03215; Thu, 1 Jun 2000 14:17:33 +0100 (BST) From: "Jo Hornsby" To: Cc: Subject: RE: [SIP] retransmission of BYE OPTIONS REGISTER request by proxies Date: Thu, 1 Jun 2000 14:17:32 +0100 Message-ID: <001501bfcbcb$be739a30$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 In-Reply-To: <652568F1.0049333A.00@sampark.hss.hns.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 > Section 10.4.1 states of the SIP draft states that a client using > UDP should retransmit BYE CANCEL OPTION and REGISTER requests. Does > this mean proxy servers dont retransmit them. No. "client" is in the general sense; i.e., it is a SIP entity that transmits requests. (Have a look at the definitions under section 1.3). - 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 Jun 1 09:27: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 JAA22834 for ; Thu, 1 Jun 2000 09:27: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 93FC54435C; Thu, 1 Jun 2000 09:18:06 -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 EEBED44337 for ; Thu, 1 Jun 2000 09:18:03 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id IAA22057; Thu, 1 Jun 2000 08:27:23 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id IAA00505; Thu, 1 Jun 2000 08:27:23 -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 IAA15277; Thu, 1 Jun 2000 08:27:22 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id IAA06483; Thu, 1 Jun 2000 08:27:22 -0500 (CDT) Date: Thu, 1 Jun 2000 08:27:22 -0500 (CDT) Message-Id: <200006011327.IAA06483@b04a45.exu.ericsson.se> To: mshanka@unity.ncsu.edu Subject: Re: [SIP] CPL Cc: 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 X-BeenThere: sip@lists.bell-labs.com > > Hi, > > I was wondering if the CPL allows dynamic creation of services, or is > that capability not part of the CPL's functionality ? > > Thanks. > > -M > CPL is best thought of as a wire representation of service logic. It is probable that most servers will "compile" CPL into a more appropriate internal format for executing and storing. So to answer your question, I expect that there will be demand for service creation environments that you can use to build services (even dynamically) and one possible output format will be CPL. For example, it would be trivial to use CGI/ASP to dynamically generate CPL in response to an HTTP request to retrieve the service logic for a particular user. The utility of doing so is another question altogether ;) my two cents sean -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 09:41: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 JAA23106 for ; Thu, 1 Jun 2000 09:41: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 B983744358; Thu, 1 Jun 2000 09:31:38 -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 0434F44337 for ; Thu, 1 Jun 2000 09:31:36 -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 GAA02093; Thu, 1 Jun 2000 06:40:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA00110; Thu, 1 Jun 2000 06:40:24 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14646.26568.459517.980895@thomasm-u1.cisco.com> Date: Thu, 1 Jun 2000 06:40:24 -0700 (PDT) To: Sean Olson Cc: mshanka@unity.ncsu.edu, sip@lists.bell-labs.com Subject: Re: [SIP] CPL In-Reply-To: <200006011327.IAA06483@b04a45.exu.ericsson.se> References: <200006011327.IAA06483@b04a45.exu.ericsson.se> 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 Sean Olson writes: > CPL is best thought of as a wire representation of service logic. It is probable > that most servers will "compile" CPL into a more appropriate internal format for > executing and storing. So to answer your question, I expect that there will be > demand for service creation environments that you can use to build services > (even dynamically) and one possible output format will be CPL. For example, it > would be trivial to use CGI/ASP to dynamically generate CPL in response to an > HTTP request to retrieve the service logic for a particular user. The utility of > doing so is another question altogether ;) I'm going to show my complete ignorance here, but doesn't this beg the "sandbox" question? Related: how is authorization accomplished? Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 10:43: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 KAA24601 for ; Thu, 1 Jun 2000 10:43: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 598A944351; Thu, 1 Jun 2000 10:34:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from crash.netspeak.com (unknown [208.143.140.6]) by lists.bell-labs.com (Postfix) with ESMTP id A738044337 for ; Thu, 1 Jun 2000 10:33:57 -0400 (EDT) Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 10:42:14 -0400 Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A60B3EE3@crash.engineering.netspeak.com> From: Linden deCarmo To: "'Dean Willis'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Suspend a session?? Date: Thu, 1 Jun 2000 10:42:13 -0400 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 Yes, we've considered this, BUT, in your scenario, how does A (or in reality, the proxy) distinguish between a conventional hold and an on-hook hold? The reason the distinction is important is this: If B goes onhook during the prescribed time period, A should be billed. If B doesn't go onhook, A should be billed up to the onhook, but not during the "suspend" period. If B places A on hold, A should be billed for the time on hold. Will your proposal satisify these requirements? If so, could you explain how? Thanks. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 > -----Original Message----- > From: Dean Willis [SMTP:dwillis@dynamicsoft.com] > Sent: Wednesday, May 31, 2000 7:07 PM > To: Linden deCarmo > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Suspend a session?? > > > Have you considered building an auto-hold on switch-hook with a timer > that initaies a BYE into your UA? My first thought is that the suggested > behavior is a UA problem, not a proxy problem. Unless it is a flaw in > the billing model . . . > > B calls A. > B places receiver on-hook. > B sends reINVITE-to-HOLD to A. > B starts timer. > Timer expires. > B sends BYE to A. > > The only issue I see here is that B might vanish during the hold-period > and fail to send the BYE. This is a risk with call-hold in general, and > I believe there has been a proposal to use a configurable hold-timer in > end devices to recover from it. > > -- > Dean > > Linden deCarmo wrote: > > > > Right now, SIP smoothly handles one party putting another party on hold > via > > a re-INVITE with modified SDP. However, we have a scenario where the > > session needs to be suspended (not just placed on hold), and I'm not > sure > > how this can be done without using proprietary headers. > > > > Here are ther details. If party A calls party B , party B should be > able to > > hang up without immediately terminating the session. If party B picks > up > > the phone within some prescribed time window, the session continues. > > However, if they don't pick it up within the time window, the session > > terminates (via a BYE). > > > > We're looking for a mechanism for party B to communicate with either > party A > > or a proxy server, to inform the distant party that the session has been > > suspended, and not just placed on hold. The primary motivator for this > > notification is billing. Without notification of suspension, its > impossible > > to determine when to safely stop billing. > > > > Thanks. > > > > Linden deCarmo > > Netspeak Corporation > > 902 Clint Moore Road > > Suite 104 > > Boca Raton, FL 33487 > > > > _______________________________________________ > > 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 Jun 1 11: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 LAA25306 for ; Thu, 1 Jun 2000 11:11: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 E968F4437F; Thu, 1 Jun 2000 11:01:43 -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 7708044337 for ; Thu, 1 Jun 2000 11:01:41 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA06219; Thu, 1 Jun 2000 10:11:00 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA05365; Thu, 1 Jun 2000 10:11:00 -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 KAA23163; Thu, 1 Jun 2000 10:10:58 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id KAA06815; Thu, 1 Jun 2000 10:10:58 -0500 (CDT) Date: Thu, 1 Jun 2000 10:10:58 -0500 (CDT) Message-Id: <200006011510.KAA06815@b04a45.exu.ericsson.se> To: mat@cisco.com Subject: Re: [SIP] CPL Cc: mshanka@unity.ncsu.edu, 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 X-BeenThere: sip@lists.bell-labs.com > > Sean Olson writes: > > CPL is best thought of as a wire representation of service logic. It is probable > > that most servers will "compile" CPL into a more appropriate internal format for > > executing and storing. So to answer your question, I expect that there will be > > demand for service creation environments that you can use to build services > > (even dynamically) and one possible output format will be CPL. For example, it > > would be trivial to use CGI/ASP to dynamically generate CPL in response to an > > HTTP request to retrieve the service logic for a particular user. The utility of > > doing so is another question altogether ;) > > I'm going to show my complete ignorance here, > but doesn't this beg the "sandbox" question? > > Related: how is authorization accomplished? > > Mike > If you really want to take a dive here, I would argue that you re-use everything that HTTP/HTTPS provides in terms of security and authorization. Of course you can always sign the CPL script as you would any other XML document for another layer of security. Regarding the sandbox issue, yes, CPL was designed to avoid this by providing a limited set of capabilities and a simple DAG, etc. etc. You don't lose this by what I'm suggesting as long as you continue to use CPL as your on the wire format. (the sandbox on the CPL service execution platform is preserved even if the CGI/ASP server is prone to infinite loops or whatever.) Personally, I see the value in providing a sandbox, but I don't think CPL is the only way to do this. sean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 11: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 LAA25517 for ; Thu, 1 Jun 2000 11:20: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 B67324438D; Thu, 1 Jun 2000 11:11:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sonusdc3.sonusnet.com (mail.sonusnet.com [63.99.71.102]) by lists.bell-labs.com (Postfix) with ESMTP id 02F8F4438C for ; Thu, 1 Jun 2000 11:11:20 -0400 (EDT) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 11:20:41 -0400 Message-ID: <9581851D1FB3D21199190090273A744501439EB0@sonusdc3.sonusnet.com> From: "Farahmand, Fardad" To: Neil Deason Cc: Scott Hoffpauir , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: RE: [SIP] SIP Application Server Date: Thu, 1 Jun 2000 11:20:40 -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 Neil, In the ISC model, the role of the SoftSwitch is to present a single protocol/interface by which an AppServer can participate in servicing the call and controlling various legs of a call. While the communication between the AppServer and the SoftSwitch is proposed to be SIP, the actual endpoints can use various protocols including PSTN and IP based (and possibly none of them are SIP endpoints). This separates the task of the service logic from details of network and protocols, presenting a single SIP interface between the two. Considering just the interface between the AppServer and the SoftSwitch, the AppServer can act as a redirect server for applications such as LNP and 800 translation. It can act as a proxy server for applications such as calling card. And it can participate as a UAS in applications such as voicemail. As Jonathan mentioned, it is the complexity and functionality of the actual application which determines the role of the AppServer in its communication with the SoftSwitch. Fardad Farahmand ffarahmand@sonusnet.com > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Thursday, June 01, 2000 6:23 AM > To: Jonathan Rosenberg > Cc: Scott Hoffpauir; sip@lists.bell-labs.com > Subject: Re: [SIP] SIP Application Server > > > Jonathan Rosenberg wrote: > > > Neil Deason wrote: > > > > > > Jonathan I agree that a service logic enhanced Proxy > Server is an application server. > > > > > > However, I am not yet convinced this sits in complete > harmony with the ISC App WG's > > > intention to separate the call signalling > (Proxy/Softswitch) and service control (App > > > Server) and use standard RFC2543 SIP as the interface > between them. In the case of > > > the service logic enhanced proxy isn't the interface > between vanilla proxy and the > > > service control defined by CPL/SIP-CGI/Servlet API etc > not RFC2543 SIP. > > > > No; the "vanilla proxy" speaks SIP to the application > server, which is > > just a smarter proxy (or redirect server or whatever). This > app server, > > internally, may use any number of APIs, including the ones > you mention. > > Yes of course a separate SIP network element can talk SIP to > a smart proxy/application > server. But the point I was trying to make is that the > application server encapsulates a > vanilla proxy server, i.e. the proxy functionality as > described by rfc2543, plus service > logic accessed through CPL/SIP-CGI/Servlet API/whatever. My > difficulty is in seeing how > this fits with the ISC application working group premise of > separating call signalling from > service control via a SIP messaging interface. This seems > like an unnecessary IN model of > separation. In the App Server the proxy part does signalling > but it is clearly not > separated from controlling service logic by a SIP messaging interface. > > 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 11: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 LAA26111 for ; Thu, 1 Jun 2000 11:43: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 9DAD84438A; Thu, 1 Jun 2000 11:34:28 -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 91A0C4434D for ; Thu, 1 Jun 2000 11:34:23 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 1 Jun 2000 10:35:20 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 10:38:18 -0500 Message-ID: From: "Glenn Morrow" To: sip@lists.bell-labs.com Subject: RE: [SIP] Suspend a session?? Date: Thu, 1 Jun 2000 10:38:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCBDF.67D000F6" 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 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_01BFCBDF.67D000F6 Content-Type: text/plain It seems to me that this should be handled by the UA itself. Once the UA determines the correct functionilty that the real end-device/user wishes to achieve, it should signal proxies and far-end stations. For instance a legacy device may which to indicate flash and collect more digits for a 3-way call by the user using the hook as you say. This would result in a separate transaction but I believe it doesn't require something like a "suspend" method or indication at the SIP level. I suggest that the UA itself should handle this with timers, etc.. based upon the physical device and human interface it is trying to achieve. For the billing issue the UA could simply use a timer started based on physical off-hook stimulus to determine when to actually send a BYE or not. If this doesn't address your concerns please let me know. > -----Original Message----- > From: Linden deCarmo [SMTP:ldeCarmo@netspeak.com] > Sent: Wednesday, May 31, 2000 1:54 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Suspend a session?? > > Right now, SIP smoothly handles one party putting another party on hold > via > a re-INVITE with modified SDP. However, we have a scenario where the > session needs to be suspended (not just placed on hold), and I'm not sure > how this can be done without using proprietary headers. > > Here are ther details. If party A calls party B , party B should be able > to > hang up without immediately terminating the session. If party B picks up > the phone within some prescribed time window, the session continues. > However, if they don't pick it up within the time window, the session > terminates (via a BYE). > > We're looking for a mechanism for party B to communicate with either party > A > or a proxy server, to inform the distant party that the session has been > suspended, and not just placed on hold. The primary motivator for this > notification is billing. Without notification of suspension, its > impossible > to determine when to safely stop billing. > > Thanks. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFCBDF.67D000F6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [SIP] Suspend a session??

It seems to me that = this should be handled by the UA itself. Once the UA determines the = correct functionilty that the real end-device/user wishes to achieve, = it should signal proxies and far-end stations. For instance a legacy = device may which to indicate flash and collect more digits for a 3-way = call by the user using the hook as you say.

This would result in = a separate transaction but I believe it doesn't require something like = a  "suspend" method or indication at the SIP = level. 

I suggest that the = UA itself should handle this with timers, etc.. based upon the physical = device and human interface it is trying to achieve.

For the billing = issue the UA could simply use a timer started based on physical = off-hook stimulus to determine when to actually send a BYE or = not.

If this doesn't = address your concerns please let me know.

    -----Original Message-----
    From:   Linden deCarmo = [SMTP:ldeCarmo@netspeak.com]
    Sent:   Wednesday, May 31, 2000 1:54 PM
    To:     sip@lists.bell-labs.com
    Subject:       = [SIP] Suspend a session??

    Right now, SIP smoothly handles one = party putting another party on hold via
    a re-INVITE with modified SDP.  = However, we have a scenario where the
    session needs to be suspended (not = just placed on hold), and I'm not sure
    how this can be done without using = proprietary headers.

    Here are ther details.  If party = A calls party B , party B should be able to
    hang up without immediately = terminating the session.  If party B picks up
    the phone within some prescribed time = window, the session continues.
    However, if they don't pick it up = within the time window, the session
    terminates (via a BYE).

    We're looking for a mechanism for = party B to communicate with either party A
    or a proxy server, to inform the = distant party that the session has been
    suspended, and not just placed on = hold.  The primary motivator for this
    notification is billing.  = Without notification of suspension, its impossible
    to determine when to safely stop = billing.

    Thanks.

    Linden deCarmo
    Netspeak Corporation
    902 Clint Moore Road
    Suite 104
    Boca Raton, FL 33487



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

------_=_NextPart_001_01BFCBDF.67D000F6-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 13:10: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 NAA27680 for ; Thu, 1 Jun 2000 13:10: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 75AC14434D; Thu, 1 Jun 2000 13:00:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from crash.netspeak.com (unknown [208.143.140.6]) by lists.bell-labs.com (Postfix) with ESMTP id CE2BE44337 for ; Thu, 1 Jun 2000 13:00:23 -0400 (EDT) Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 13:08:52 -0400 Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A60B3EEB@crash.engineering.netspeak.com> From: Linden deCarmo To: "'Glenn Morrow'" , sip@lists.bell-labs.com Subject: RE: [SIP] Suspend a session?? Date: Thu, 1 Jun 2000 13:08:51 -0400 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 Here's the problem with the UA doing it: User goes on hook (time 0 ). UA starts timer. Timer expires (time 30 seconds). UA realizes session expires so it issues a BYE. Since the proxy sees the BYE 30 seconds later, thats when it stops billing. I do not believe your solution addresses how the UA signals to the proxy that billing should stop at time 0 rather than time 30. I realize I can do this with a proprietary method or header, but I'd rather not. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 > -----Original Message----- > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] > Sent: Thursday, June 01, 2000 11:38 AM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] Suspend a session?? > > It seems to me that this should be handled by the UA itself. Once the UA > determines the correct functionilty that the real end-device/user wishes > to achieve, it should signal proxies and far-end stations. For instance a > legacy device may which to indicate flash and collect more digits for a > 3-way call by the user using the hook as you say. > > This would result in a separate transaction but I believe it doesn't > require something like a "suspend" method or indication at the SIP level. > > > I suggest that the UA itself should handle this with timers, etc.. based > upon the physical device and human interface it is trying to achieve. > > For the billing issue the UA could simply use a timer started based on > physical off-hook stimulus to determine when to actually send a BYE or > not. > > If this doesn't address your concerns please let me know. > > -----Original Message----- > From: Linden deCarmo [SMTP:ldeCarmo@netspeak.com] > Sent: Wednesday, May 31, 2000 1:54 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Suspend a session?? > > Right now, SIP smoothly handles one party putting another party on > hold via > a re-INVITE with modified SDP. However, we have a scenario where the > session needs to be suspended (not just placed on hold), and I'm not sure > how this can be done without using proprietary headers. > > Here are ther details. If party A calls party B , party B should be > able to > hang up without immediately terminating the session. If party B picks up > the phone within some prescribed time window, the session continues. > However, if they don't pick it up within the time window, the session > terminates (via a BYE). > > We're looking for a mechanism for party B to communicate with either > party A > or a proxy server, to inform the distant party that the session has been > suspended, and not just placed on hold. The primary motivator for this > notification is billing. Without notification of suspension, its > impossible > to determine when to safely stop billing. > > Thanks. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > > > _______________________________________________ > SIP mailing list > SIP@lists.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 Thu Jun 1 13:31: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 NAA28179 for ; Thu, 1 Jun 2000 13:31: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 93D3D44379; Thu, 1 Jun 2000 13:21:54 -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 F2B0444376 for ; Thu, 1 Jun 2000 13:21:51 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 1 Jun 2000 12:28:02 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 12:31:00 -0500 Message-ID: From: "Glenn Morrow" To: "'Linden deCarmo'" , sip@lists.bell-labs.com Subject: RE: [SIP] Suspend a session?? Date: Thu, 1 Jun 2000 12:31:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCBEF.26E4AD2A" 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 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_01BFCBEF.26E4AD2A Content-Type: text/plain Perhaps we could timestamp the BYE? > -----Original Message----- > From: Linden deCarmo [SMTP:ldeCarmo@netspeak.com] > Sent: Thursday, June 01, 2000 12:09 PM > To: Morrow, Glenn [RICH2:C301:EXCH]; sip@lists.bell-labs.com > Subject: RE: [SIP] Suspend a session?? > > Here's the problem with the UA doing it: > > User goes on hook (time 0 ). UA starts timer. > Timer expires (time 30 seconds). UA realizes session expires so it issues > a > BYE. > > Since the proxy sees the BYE 30 seconds later, thats when it stops > billing. > I do not believe your solution addresses how the UA signals to the proxy > that billing should stop at time 0 rather than time 30. > > I realize I can do this with a proprietary method or header, but I'd > rather > not. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > > -----Original Message----- > > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] > > Sent: Thursday, June 01, 2000 11:38 AM > > To: sip@lists.bell-labs.com > > Subject: RE: [SIP] Suspend a session?? > > > > It seems to me that this should be handled by the UA itself. Once the UA > > determines the correct functionilty that the real end-device/user wishes > > to achieve, it should signal proxies and far-end stations. For instance > a > > legacy device may which to indicate flash and collect more digits for a > > 3-way call by the user using the hook as you say. > > > > This would result in a separate transaction but I believe it doesn't > > require something like a "suspend" method or indication at the SIP > level. > > > > > > I suggest that the UA itself should handle this with timers, etc.. based > > upon the physical device and human interface it is trying to achieve. > > > > For the billing issue the UA could simply use a timer started based on > > physical off-hook stimulus to determine when to actually send a BYE or > > not. > > > > If this doesn't address your concerns please let me know. > > > > -----Original Message----- > > From: Linden deCarmo [SMTP:ldeCarmo@netspeak.com] > > Sent: Wednesday, May 31, 2000 1:54 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Suspend a session?? > > > > Right now, SIP smoothly handles one party putting another party on > > hold via > > a re-INVITE with modified SDP. However, we have a scenario where the > > session needs to be suspended (not just placed on hold), and I'm not > sure > > how this can be done without using proprietary headers. > > > > Here are ther details. If party A calls party B , party B should be > > able to > > hang up without immediately terminating the session. If party B picks > up > > the phone within some prescribed time window, the session continues. > > However, if they don't pick it up within the time window, the session > > terminates (via a BYE). > > > > We're looking for a mechanism for party B to communicate with either > > party A > > or a proxy server, to inform the distant party that the session has been > > > suspended, and not just placed on hold. The primary motivator for this > > notification is billing. Without notification of suspension, its > > impossible > > to determine when to safely stop billing. > > > > Thanks. > > > > Linden deCarmo > > Netspeak Corporation > > 902 Clint Moore Road > > Suite 104 > > Boca Raton, FL 33487 > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFCBEF.26E4AD2A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [SIP] Suspend a session??

Perhaps we could = timestamp the BYE?

    -----Original Message-----
    From:   Linden deCarmo = [SMTP:ldeCarmo@netspeak.com]
    Sent:   Thursday, June 01, 2000 12:09 PM
    To:     Morrow, Glenn [RICH2:C301:EXCH]; = sip@lists.bell-labs.com
    Subject:       = RE: [SIP] Suspend a session??

    Here's the problem with the UA doing = it:

    User goes on hook (time 0 ).  UA = starts timer.
    Timer expires (time 30 seconds). UA = realizes session expires so it issues a
    BYE.

    Since the proxy sees the BYE 30 = seconds later, thats when it stops billing.
    I do not believe your solution = addresses how the UA signals to the proxy
    that billing should stop at time 0 = rather than time 30. 

    I realize I can do this with a = proprietary method or header, but I'd rather
    not.

    Linden deCarmo
    Netspeak Corporation
    902 Clint Moore Road
    Suite 104
    Boca Raton, FL 33487

    > -----Original Message-----
    > From: Glenn Morrow = [SMTP:gmorrow@nortelnetworks.com]
    > Sent: Thursday, June 01, 2000 = 11:38 AM
    > To:   = sip@lists.bell-labs.com
    > = Subject:      RE: [SIP] Suspend a = session??
    >
    > It seems to me that this should = be handled by the UA itself. Once the UA
    > determines the correct = functionilty that the real end-device/user wishes
    > to achieve, it should signal = proxies and far-end stations. For instance a
    > legacy device may which to = indicate flash and collect more digits for a
    > 3-way call by the user using the = hook as you say.
    >
    > This would result in a separate = transaction but I believe it doesn't
    > require something like a  = "suspend" method or indication at the SIP level.
    >
    >
    > I suggest that the UA itself = should handle this with timers, etc.. based
    > upon the physical device and = human interface it is trying to achieve.
    >
    > For the billing issue the UA = could simply use a timer started based on
    > physical off-hook stimulus to = determine when to actually send a BYE or
    > not.
    >
    > If this doesn't address your = concerns please let me know.
    >
    >       = -----Original Message-----
    > From:   Linden deCarmo = [SMTP:ldeCarmo@netspeak.com]
    > Sent:   Wednesday, May = 31, 2000 1:54 PM
    > To:     = sip@lists.bell-labs.com
    > = Subject:        [SIP] Suspend a = session??
    >
    >       = Right now, SIP smoothly handles one party putting another party = on
    > hold via
    > a re-INVITE with modified = SDP.  However, we have a scenario where the
    > session needs to be suspended = (not just placed on hold), and I'm not sure
    > how this can be done without = using proprietary headers.
    >
    >       = Here are ther details.  If party A calls party B , party B should = be
    > able to
    > hang up without immediately = terminating the session.  If party B picks up
    > the phone within some prescribed = time window, the session continues.
    > However, if they don't pick it = up within the time window, the session
    > terminates (via a BYE).
    >
    >       = We're looking for a mechanism for party B to communicate with = either
    > party A
    > or a proxy server, to inform the = distant party that the session has been
    > suspended, and not just placed = on hold.  The primary motivator for this
    > notification is billing.  = Without notification of suspension, its
    > impossible
    > to determine when to safely stop = billing.
    >
    >       = Thanks.
    >
    >       = Linden deCarmo
    > Netspeak Corporation
    > 902 Clint Moore Road
    > Suite 104
    > Boca Raton, FL 33487
    >
    >
    >
    >       = _______________________________________________
    > 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_001_01BFCBEF.26E4AD2A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 15:41: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 PAA01957 for ; Thu, 1 Jun 2000 15:41: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 13EF84434D; Thu, 1 Jun 2000 15:32:31 -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 3B15E44337 for ; Thu, 1 Jun 2000 15:32:28 -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 MAA22100; Thu, 1 Jun 2000 12:41:27 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA00125; Thu, 1 Jun 2000 12:41:18 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14646.48222.54575.33836@thomasm-u1.cisco.com> Date: Thu, 1 Jun 2000 12:41:18 -0700 (PDT) To: Sean Olson Cc: mat@cisco.com, mshanka@unity.ncsu.edu, sip@lists.bell-labs.com Subject: Re: [SIP] CPL In-Reply-To: <200006011510.KAA06815@b04a45.exu.ericsson.se> References: <200006011510.KAA06815@b04a45.exu.ericsson.se> 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 Sean Olson writes: > > I'm going to show my complete ignorance here, > > but doesn't this beg the "sandbox" question? > > > > Related: how is authorization accomplished? > > > > Mike > > > > If you really want to take a dive here, I would argue that you re-use everything > that HTTP/HTTPS provides in terms of security and authorization. Of course you > can always sign the CPL script as you would any other XML document for another > layer of security. What I had in mind here is how would a proxy know what kinds of actions a given user with a given CPL script is allowed to do? It could be as simple as a binary decision of if you allow CPL at all, you allow any arbitrary script to be executed. My suspicion is that the binary decision is too course though, which make the problem more difficult. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 15:48: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 PAA02035 for ; Thu, 1 Jun 2000 15:48: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 A943F44389; Thu, 1 Jun 2000 15:38:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from warspite.cnchost.com (warspite.concentric.net [207.155.248.9]) by lists.bell-labs.com (Postfix) with ESMTP id 131CA44337 for ; Thu, 1 Jun 2000 15:38:31 -0400 (EDT) Received: from ss8networks.com (gw-ss8networks.storm.ca [209.87.234.122]) by warspite.cnchost.com id PAA10290; Thu, 1 Jun 2000 15:47:49 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <3936BD56.8D8DEE0D@ss8networks.com> Date: Thu, 01 Jun 2000 15:45:26 -0400 From: Dave Walker Organization: SS8 Networks Inc X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Linden deCarmo Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Suspend a session?? References: <6C5713970B1FD411ACBE00AA00DCD9A60B3EEB@crash.engineering.netspeak.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 think that the solution was pointed out earlier in this thread. The problem seems to be that you want to charge for the existence of a signalling connection. If billing was based on packets, you would simply put the remote UA on hold. You want to put the remote UA on hold anyway because that may lessen the chances of additional billing. I feel what you want to do is to issue a re-INVITE to go on hold, then somehow issue some "STOP BILLING" request to entities in the signalling path that may be accumulating billing data. That kind of request would be subject to abuse of course. But couldn't that billing entity simply look at the successful hold to decide to suspend billing (or bill at some reduced rate)? The next signalling that would normally come through is a BYE or another INVITE which stops or will resume normal billing. Then I'll argue that if your UA is getting excessively charged for sessions that are on hold (i.e. generating zero media), then it's time to find a new service provider. Regards, Dave Walker SS8 Networks Ottawa, Canada Linden deCarmo wrote: > > Here's the problem with the UA doing it: > > User goes on hook (time 0 ). UA starts timer. > Timer expires (time 30 seconds). UA realizes session expires so it issues a > BYE. > > Since the proxy sees the BYE 30 seconds later, thats when it stops billing. > I do not believe your solution addresses how the UA signals to the proxy > that billing should stop at time 0 rather than time 30. > > I realize I can do this with a proprietary method or header, but I'd rather > not. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > > -----Original Message----- > > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] > > Sent: Thursday, June 01, 2000 11:38 AM > > To: sip@lists.bell-labs.com > > Subject: RE: [SIP] Suspend a session?? > > > > It seems to me that this should be handled by the UA itself. Once the UA > > determines the correct functionilty that the real end-device/user wishes > > to achieve, it should signal proxies and far-end stations. For instance a > > legacy device may which to indicate flash and collect more digits for a > > 3-way call by the user using the hook as you say. > > > > This would result in a separate transaction but I believe it doesn't > > require something like a "suspend" method or indication at the SIP level. > > > > > > I suggest that the UA itself should handle this with timers, etc.. based > > upon the physical device and human interface it is trying to achieve. > > > > For the billing issue the UA could simply use a timer started based on > > physical off-hook stimulus to determine when to actually send a BYE or > > not. > > > > If this doesn't address your concerns please let me know. > > > > -----Original Message----- > > From: Linden deCarmo [SMTP:ldeCarmo@netspeak.com] > > Sent: Wednesday, May 31, 2000 1:54 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Suspend a session?? > > > > Right now, SIP smoothly handles one party putting another party on > > hold via > > a re-INVITE with modified SDP. However, we have a scenario where the > > session needs to be suspended (not just placed on hold), and I'm not sure > > how this can be done without using proprietary headers. > > > > Here are ther details. If party A calls party B , party B should be > > able to > > hang up without immediately terminating the session. If party B picks up > > the phone within some prescribed time window, the session continues. > > However, if they don't pick it up within the time window, the session > > terminates (via a BYE). > > > > We're looking for a mechanism for party B to communicate with either > > party A > > or a proxy server, to inform the distant party that the session has been > > suspended, and not just placed on hold. The primary motivator for this > > notification is billing. Without notification of suspension, its > > impossible > > to determine when to safely stop billing. > > > > Thanks. > > > > Linden deCarmo > > Netspeak Corporation > > 902 Clint Moore Road > > Suite 104 > > Boca Raton, FL 33487 > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.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 Jun 1 16:08: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 QAA02501 for ; Thu, 1 Jun 2000 16:08: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 B834544385; Thu, 1 Jun 2000 15:59:02 -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 5FD5144379 for ; Thu, 1 Jun 2000 15:58:55 -0400 (EDT) Received: from research.telcordia.com (shim-pc [192.4.8.82]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e51K8Gj20220 for ; Thu, 1 Jun 2000 16:08:16 -0400 (EDT) Message-ID: <3936C2AF.1953A082@research.telcordia.com> Date: Thu, 01 Jun 2000 16:08:16 -0400 From: Hyong Sop Shim Organization: Telcordia Technologies X-Mailer: Mozilla 4.72 [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] Could you provide a scenario? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, RFC2543bis provides the following as the definition of "Initiator, calling party, caller": "The party initiating a conference invitation. Note that the calling party does not have to be the same as the one creating the conference." Could anyone provide a scenario, in which demonstrates this noted case, i.e., a UA creates a conference and a different UA initiates a conference invitation to other UAs? Thanks, --Hyong Shim (hyongsop@research.telcordia.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 Jun 1 19:00: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 TAA06373 for ; Thu, 1 Jun 2000 19:00: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 2707D4434D; Thu, 1 Jun 2000 18:51:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from turin.trillium.com (turin.trillium.com [206.216.108.218]) by lists.bell-labs.com (Postfix) with ESMTP id 2C01144337 for ; Thu, 1 Jun 2000 18:51:05 -0400 (EDT) Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 1 Jun 2000 16:12:30 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id QAA09281 for ; Thu, 1 Jun 2000 16:00:23 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 15:59:11 -0700 Message-ID: <8BBD33A986C5D311804000902719FF5D37989B@aega.trillium.com> From: Aseem Agarwal To: "'sip@lists.bell-labs.com'" Date: Thu, 1 Jun 2000 15:59:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Basic 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 All, I have a few basic questions about SIP Registrar functionality. - Can a User Agent also act as a Registrar ? Assuming that a UA can act as a Registrar as well, is it expected to NOT respond to any REGISTER requests ? - Need some clarity on the following para in Section 4.2.6 [2543bis]. "It is recommended that the UA registers via multicast and send a registration to it's home address" Does this mean that registry database is maintained at two places, one at the registrar listening on the well known multicast address and another at the server at the home address ? To my understanding, there should be a local SIP Registrar server for any network. All UA's should register with this server when they come up. However, is it possible for UA's to also cache the registrations and use the cached entries for subsequent calls with out going to the location services or the registrar in the network ? thanks, aseem _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 1 22:58: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 WAA11176 for ; Thu, 1 Jun 2000 22:58: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 A9E074434D; Thu, 1 Jun 2000 22:48:51 -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 986A344337 for ; Thu, 1 Jun 2000 22:48:48 -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 WAA25370; Thu, 1 Jun 2000 22:58:06 -0400 (EDT) Message-ID: <393722DB.2228F578@cs.columbia.edu> Date: Thu, 01 Jun 2000 22:58: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: Hyong Sop Shim Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Could you provide a scenario? References: <3936C2AF.1953A082@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 Easy: Conference initiated by SAP by some entity A, with the SIP invitation issued by anybody who happens to be listening to the announcement. Hyong Sop Shim wrote: > > Hi, > > RFC2543bis provides the following as the definition of "Initiator, > calling party, caller": > "The party initiating a conference invitation. Note that the calling > party does not have to be the same as the one creating the conference." > > Could anyone provide a scenario, in which demonstrates this noted case, > i.e., a UA creates a conference and a different UA initiates a > conference invitation to other UAs? > > Thanks, > > --Hyong Shim > (hyongsop@research.telcordia.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 Jun 2 00:53: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 AAA12488 for ; Fri, 2 Jun 2000 00:53: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 0373844342; Fri, 2 Jun 2000 00:43:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 60EA744337 for ; Fri, 2 Jun 2000 00:43:50 -0400 (EDT) Received: from dynamicsoft.com (1Cust178.tnt1.freehold.nj.da.uu.net [63.17.113.178]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA11170; Fri, 2 Jun 2000 00:54:36 -0400 (EDT) Message-ID: <39373DC1.21502647@dynamicsoft.com> Date: Fri, 02 Jun 2000 00:53:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aseem Agarwal Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Basic Question References: <8BBD33A986C5D311804000902719FF5D37989B@aega.trillium.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 Aseem Agarwal wrote: > > Hi All, > I have a few basic questions about SIP Registrar functionality. > > - Can a User Agent also act as a Registrar ? Assuming that a UA > can act as a Registrar as well, is it expected to NOT respond > to any REGISTER requests ? Being a UA is a logical role, as is a registrar. If an entity accepts REGISTERs and stores location information, its a registrar. So, you can write a piece of code that is both a UA and a registrar if you want. > > - Need some clarity on the following para in Section 4.2.6 [2543bis]. > "It is recommended that the UA registers via multicast and send a > registration to it's home address" > > Does this mean that registry database is maintained at two places, > one at the registrar listening on the well known multicast address > and another at the server at the home address ? Maybe, maybe not. You can have a single server listening to both multicast and unicast. > > To my understanding, there should be a local SIP Registrar server > for any network. All UA's should register with this server when they > come up. However, is it possible for UA's to also cache the registrations > and use the cached entries for subsequent calls with out going to the > location services or the registrar in the network ? Sure, its possible. Seems a bit more work than its worth, since the UA basically needs to be a registrar. Also, this only works for multicast, as that is the only case where other UAs can see the registrations. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 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 Jun 2 01:10: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 BAA13223 for ; Fri, 2 Jun 2000 01:10: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 A5329443A0; Fri, 2 Jun 2000 01:00:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 39D2744337 for ; Fri, 2 Jun 2000 01:00:29 -0400 (EDT) Received: from dynamicsoft.com (1Cust178.tnt1.freehold.nj.da.uu.net [63.17.113.178]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11207; Fri, 2 Jun 2000 01:11:13 -0400 (EDT) Message-ID: <393741A6.ED26ECEA@dynamicsoft.com> Date: Fri, 02 Jun 2000 01:09:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Sean Olson , mshanka@unity.ncsu.edu, sip@lists.bell-labs.com Subject: Re: [SIP] CPL References: <200006011510.KAA06815@b04a45.exu.ericsson.se> <14646.48222.54575.33836@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: > > What I had in mind here is how would a proxy > know what kinds of actions a given user with > a given CPL script is allowed to do? It could > be as simple as a binary decision of if you > allow CPL at all, you allow any arbitrary > script to be executed. The point of CPL is that it can't do too much to begin with. Its a scripting language - there are no variables, no looping constructs, nothing. There are six or so basic primitives defined - decision making primitives that check the caller, callee, time of day, or priority, and action primitives that can forward, reject, redirect. Thats mostly it. As a result, CPL is safe to execute, since it simply can't do any damage to a server. Thus, I believe the binary decision about authorization is perfectly legitimate. That said, you *could* specify that a proxy should not accept CPLs from user Joe that use the time-of-day switch statement, but why? For more info on CPL, check out the framework document which just issued today as RFC2824. It compares CPL to other programming interfaces in which the program executes in a sandbox, such as servlets. -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 Jun 2 01:19: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 BAA14338 for ; Fri, 2 Jun 2000 01:19: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 38AFD443A8; Fri, 2 Jun 2000 01:10:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A5A964439F for ; Fri, 2 Jun 2000 01:10:11 -0400 (EDT) Received: from dynamicsoft.com (1Cust178.tnt1.freehold.nj.da.uu.net [63.17.113.178]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11211; Fri, 2 Jun 2000 01:17:11 -0400 (EDT) Message-ID: <3937430C.FFF6D98B@dynamicsoft.com> Date: Fri, 02 Jun 2000 01:15:56 -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: Scott Hoffpauir , sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server References: <3933EEB2.893C06AB@ubiquity.net> <39343EDC.2B4005FD@dynamicsoft.com> <3934CA2C.F4538AD5@ubiquity.net> <3935E680.B7598DA4@dynamicsoft.com> <39363991.882283F9@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: > > Yes of course a separate SIP network element can talk SIP to a smart proxy/application > server. But the point I was trying to make is that the application server encapsulates a > vanilla proxy server, i.e. the proxy functionality as described by rfc2543, plus service > logic accessed through CPL/SIP-CGI/Servlet API/whatever. My difficulty is in seeing how > this fits with the ISC application working group premise of separating call signalling from > service control via a SIP messaging interface. This seems like an unnecessary IN model of > separation. In the App Server the proxy part does signalling but it is clearly not > separated from controlling service logic by a SIP messaging interface. I think you are over-analyzing the meaning of separation of call-signaling from service control. In reality, all services are delivered eventually through signaling, and are based on information provided by signaling. Thus, service logic is quite connected to call signaling, and embedding a vanilla proxy in an app server is quite a good way to access it. I would argue this is quite contrary to the IN model, in which there is an attempt to use a separate protocol for service control to a separate box. Note however that these protocols carry much the same information as the signaling protocols themselves. -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 Jun 2 01:33: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 BAA16335 for ; Fri, 2 Jun 2000 01:33: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 5B97C44391; Fri, 2 Jun 2000 01:23:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BD5FF44337 for ; Fri, 2 Jun 2000 01:23:48 -0400 (EDT) Received: from dynamicsoft.com (1Cust178.tnt1.freehold.nj.da.uu.net [63.17.113.178]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11220; Fri, 2 Jun 2000 01:34:23 -0400 (EDT) Message-ID: <39374714.7D467537@dynamicsoft.com> Date: Fri, 02 Jun 2000 01:33:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Walker Cc: Linden deCarmo , sip@lists.bell-labs.com Subject: Re: [SIP] Suspend a session?? References: <6C5713970B1FD411ACBE00AA00DCD9A60B3EEB@crash.engineering.netspeak.com> <3936BD56.8D8DEE0D@ss8networks.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 Dave Walker wrote: > > I think that the solution was pointed out earlier in this thread. > The problem seems to be that you want to charge for the existence of > a signalling connection. Actually, the problem is that you are trying to bill for services you are not actually providing. Unless there is either transport level services, or gateway services, billing anything by the minute is going to be a tough proposition. Providing a mechanism that allows the user to stop billing actually makes the job of getting around billing really easy. Now, if you were providing QoS, I would argue that "hold" would not also be accompanied by a release of QoS resources, where perhaps "suspend" would. In this case, releasing of QoS resources would signal to stop billing by the minute. But, thats all within the transport infrastructure, not SIP. > > If billing was based on packets, you would simply put the remote UA > on hold. You want to put the remote UA on hold anyway because that > may lessen the chances of additional billing. > > I feel what you want to do is to issue a re-INVITE to go on hold, > then somehow issue some "STOP BILLING" request to entities in the > signalling path that may be accumulating billing data. That kind of > request would be subject to abuse of course. Exactly. > > But couldn't that billing entity simply look at the successful hold > to decide to suspend billing (or bill at some reduced rate)? Not really; this is also subject to abuse. I'll just put you on hold within SIP, but both near and far end have "updated" SIP terminals which actually ignore the hold message anyway, and continue to send media. Free phone calls. Cool. -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 Jun 2 04:22: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 EAA26293 for ; Fri, 2 Jun 2000 04:22: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 34DB04433F; Fri, 2 Jun 2000 04:12: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 DABAC44337 for ; Fri, 2 Jun 2000 04:12:19 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA11148; Fri, 2 Jun 2000 09:19:41 +0100 (BST) Message-ID: <39376E1C.8EB32817@ubiquity.net> Date: Fri, 02 Jun 2000 09:19:41 +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: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server References: <3933EEB2.893C06AB@ubiquity.net> <39343EDC.2B4005FD@dynamicsoft.com> <3934CA2C.F4538AD5@ubiquity.net> <3935E680.B7598DA4@dynamicsoft.com> <39363991.882283F9@ubiquity.net> <3937430C.FFF6D98B@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: > Neil Deason wrote: > > > > Yes of course a separate SIP network element can talk SIP to a smart proxy/application > > server. But the point I was trying to make is that the application server encapsulates a > > vanilla proxy server, i.e. the proxy functionality as described by rfc2543, plus service > > logic accessed through CPL/SIP-CGI/Servlet API/whatever. My difficulty is in seeing how > > this fits with the ISC application working group premise of separating call signalling from > > service control via a SIP messaging interface. This seems like an unnecessary IN model of > > separation. In the App Server the proxy part does signalling but it is clearly not > > separated from controlling service logic by a SIP messaging interface. > > I think you are over-analyzing the meaning of separation of > call-signaling from service control. In reality, all services are > delivered eventually through signaling, and are based on information > provided by signaling. Thus, service logic is quite connected to call > signaling, and embedding a vanilla proxy in an app server is quite a > good way to access it. I would argue this is quite contrary to the IN > model, in which there is an attempt to use a separate protocol for > service control to a separate box. Note however that these protocols > carry much the same information as the signaling protocols themselves. Agreed. It was not my analysis that SIP should be used to try and separate out service control from call control. However, as was pointed out earlier in this thread this could be achieved if SIP is used to separate a non-SIP signalling protocol from service logic in a 'Softswitch' network. But then it appears that you would have a separate protocol (SIP) for service control to a separate box (App Server). Such separation doesn't really apply in the same way to the SIP part of the network and it sounds a lot like the Softswitch network is a SIP network at the core. There you find SIP conversant App Servers and around them are SIP Proxy Servers, SIP Redirect Servers and SIP User Agents. Some of these UAs may in fact represent interfaces to PSTN or even H.323 gateways. Though how do protocols that don't use SIP for signalling deliver all the rich new services that SIP enables when, for example, a text/html payload gets discarded at the SIP/foo gateway. The point of SIP is surely not to create LNP, 800 translation services in an App Server for protocols such as SS7, H.323 etc Yes, you could recreate the IN this way but why not start out intending to build something better. You achieve this by building Application Servers that empower the simple creation of innovative services not Application Servers that merely recreate old services. Regards, 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 Fri Jun 2 09: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 JAA02148 for ; Fri, 2 Jun 2000 09: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 99E0D4438F; Fri, 2 Jun 2000 09:26:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3D18E4438C for ; Fri, 2 Jun 2000 09:26:03 -0400 (EDT) Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA11806; Fri, 2 Jun 2000 09:36:09 -0400 (EDT) Message-ID: <3937B7FB.BC71F9F7@dynamicsoft.com> Date: Fri, 02 Jun 2000 09:34:51 -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] SIP Application Server References: <3933EEB2.893C06AB@ubiquity.net> <39343EDC.2B4005FD@dynamicsoft.com> <3934CA2C.F4538AD5@ubiquity.net> <3935E680.B7598DA4@dynamicsoft.com> <39363991.882283F9@ubiquity.net> <3937430C.FFF6D98B@dynamicsoft.com> <39376E1C.8EB32817@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: > > > I think you are over-analyzing the meaning of separation of > > call-signaling from service control. In reality, all services are > > delivered eventually through signaling, and are based on information > > provided by signaling. Thus, service logic is quite connected to call > > signaling, and embedding a vanilla proxy in an app server is quite a > > good way to access it. I would argue this is quite contrary to the IN > > model, in which there is an attempt to use a separate protocol for > > service control to a separate box. Note however that these protocols > > carry much the same information as the signaling protocols themselves. > > Agreed. It was not my analysis that SIP should be used to try and separate out service control > from call control. However, as was pointed out earlier in this thread this could be achieved if > SIP is used to separate a non-SIP signalling protocol from service logic in a 'Softswitch' > network. But then it appears that you would have a separate protocol (SIP) for service control to > a separate box (App Server). Such separation doesn't really apply in the same way to the SIP part > of the network and it sounds a lot like the Softswitch network is a SIP network at the core. > There you find SIP conversant App Servers and around them are SIP Proxy Servers, SIP Redirect > Servers and SIP User Agents. Some of these UAs may in fact represent interfaces to PSTN or even > H.323 gateways. Though how do protocols that don't use SIP for signalling deliver all the rich > new services that SIP enables when, for example, a text/html payload gets discarded at the > SIP/foo gateway. The point of SIP is surely not to create LNP, 800 translation services in an App > Server for protocols such as SS7, H.323 etc Yes, you could recreate the IN this way but why not > start out intending to build something better. You achieve this by building Application Servers > that empower the simple creation of innovative services not Application Servers that merely > recreate old services. I couldn't agree more with this sentiment. That said, I have a sneaking suspicion that people will still want to build these older services. Fortunately, most are supported by SIP, and can easily be built ontop of an applications server as well. These services (things like LNP and freephone) will work for H.323 devices, PSTN phones or ISDN phones accessing the SIP network through a gateway or softswitch. Even better, SIPs capabilities for negotiating extensions, content, methods, and so on, will often allow an app server to know if the accessing device can support a more innovative service. In the example you give, where the app server returns HTML to a softswitch, the app server can know apriori that HTML is or isn't supported (Accept: text/html in the INVITE). It could then do something different with the request for non-html access devices, like forward it to a media server running TTS or something, and read out the web page. -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 Jun 2 10:01: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 KAA02650 for ; Fri, 2 Jun 2000 10:01: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 B9C62443A4; Fri, 2 Jun 2000 09:52:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E83DF44397 for ; Fri, 2 Jun 2000 09:52:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA11850; Fri, 2 Jun 2000 10:02:07 -0400 (EDT) Message-ID: <3937BE16.EE3941EB@dynamicsoft.com> Date: Fri, 02 Jun 2000 10:00:54 -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: Sip Mail List Subject: Re: [SIP] Receiver-tagged Via Headers and hidden parameter References: <00053013571100.24017@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: > > hi, > > I'm querying the use of the hidden parameter and received parameter in the same via. > > It is the purpose of the hidden parameter to hide the previous hop from subsequent hopes and this > is done by encrypting the 'sent-by' part of the Via header. > > However, it is possible that the Proxy has added a received parameter to the encrypted via in order > to reply to the correct machine. This received parameter provides open knowledge of the previous > hop's address and compromises the security. Good observation. > > Now there are two possibilities here (as far as i can see): > > 1) The received parameter should not be added to the hidden via but cached by the proxy in a lookup > table whilst it waits for the response. (or the received parameter can be encrypted as well). > > 2) For a received parameter to be inserted, then the message has probably come through a NAT or firewall. > this is sufficent enough for security matters and aslong as the original host is encrypted within the via > i.e. the sent-by remains encrypted, all is OK. There is another possibility, which seems the best choice: 3) Both the sent-by and received parameter are encrypted and placed in to the Via header. I don't like (1), since you lose the property of being able to run statelessly. -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 Jun 2 10:17: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 KAA02861 for ; Fri, 2 Jun 2000 10:17: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 7B5534433F; Fri, 2 Jun 2000 10:08: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 4712044337 for ; Fri, 2 Jun 2000 10:08:02 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA12135; Fri, 2 Jun 2000 15:15:37 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Sip Mail List Subject: Re: [SIP] Receiver-tagged Via Headers and hidden parameter Date: Fri, 2 Jun 2000 15:10:54 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <00053013571100.24017@gethin> <3937BE16.EE3941EB@dynamicsoft.com> In-Reply-To: <3937BE16.EE3941EB@dynamicsoft.com> MIME-Version: 1.0 Message-Id: <00060215141207.02750@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 Fri, 02 Jun 2000, Jonathan Rosenberg wrote: > Gethin Liddell wrote: > > > > However, it is possible that the Proxy has added a received parameter to the encrypted via in order > > to reply to the correct machine. This received parameter provides open knowledge of the previous > > hop's address and compromises the security. > > Good observation. > > > 1) The received parameter should not be added to the hidden via but cached by the proxy in a lookup > > table whilst it waits for the response. (or the received parameter can be encrypted as well). > > There is another possibility, which seems the best choice: > > 3) Both the sent-by and received parameter are encrypted and placed in > to the Via header. actually that's what i meant in the brackets for (1) :) -- 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 Jun 2 10:39: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 KAA03322 for ; Fri, 2 Jun 2000 10:39: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 9F409443B4; Fri, 2 Jun 2000 10:29:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 35DAD44337 for ; Fri, 2 Jun 2000 10:29:30 -0400 (EDT) Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA12071; Fri, 2 Jun 2000 10:40:17 -0400 (EDT) Message-ID: <3937C707.F8188350@dynamicsoft.com> Date: Fri, 02 Jun 2000 10:39:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com, ray.zibman@metatel.com Subject: Re: [SIP] Allowing the user@host form on Via header References: <200005302026.PAA12906@b04a45.exu.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 Sean Olson wrote: > > Comments inline > > > I propose the following changes to draft-ietf-sip-2543bis-00: > > > > Page 59, BNF of sent-by for Via header should read: > > sent-by = ([user@]host[:port])|(concealed-host) > > where user is as defined in Section 2, on page 18. > > > > Also, in section 4.2.6, page 28, description of Request-URI, delete the > > sentence "The user name MUST be empty." > > > > The reason for both changes is that we have a model in which a SIP Server > > is providing proxy services to a large collection of users. It often > > happens that a client belonging to user1 will send a SIP request such as > > an INVITE to this server. The server will receive this request and make > > various decisions according to logic installed on behalf of user1. This > > logic frequently requires stateful interactions. One decision could be to > > proxy the INVITE to the server for the invited party (user2). The proxy > > server for user2 is located on the same host (and same port) as the server > > for user1. The server for user2 may create the response to the INVITE or > > it may proxy it onwards to one or more clients for user2, or perhaps to > > other users that have been designated by user2. This is all according to > > logic installed on behalf of user2. When the response comes back to the > > server we want the server for user2 to see the response (and perhaps > > decide to proxy the request to SIP entities) before the response is seen > > by the server for user1. The addition of the user part in the sent-by of > > the via allows such a routing. If it is ever used in a situation where > > there is no concept of different servers for different users it is > > ignored. > > > > Note that the branch parameter does not meet our needs since there may, in > > fact, be no branching. Also, note that a common port on the SIP Server > > services all user agents, so the port parameter could not be used to > > differentiate servers for different users. And, there may be more users > > serviced on this host than could be separated with a typical 16 bit port > > number. > > > > You would only need to play these games if the proxy you are referring to is > transaction-stateless. If it is NOT transaction-stateless, then it is a trivial > matter to add the user information from the Request-URI to the transaction state > you are already maintaining. No. This problem is addressed directly by the new mechanisms for loop detection and computation of the branch parameter. The spec details these, but is incorrect in its statement that it need only be done for forking proxies. All proxies are going to need compute and insert the first piece of the two described pieces of information. We'll correct this. Let me explain how this will work for Rays case with the following picture: +-------------+ | | V | +-----------+ | | | 2 | | | | | Proxy | ------+ | | | | +-----------+ \ ^ \ // \ 3 / \ / \ // 1 \ / V /-----\ / /-----\ / \ / \ | | | | | U1 | | U2 | \ / \ / \-----/ \-----/ (PS - figure created by email effects, http://www.sigsoftware.com, which generates ascii art - this picture took me one minute to do....) U1 sends message 1 to its proxy, P. The proxy forwards to itself, and inserts into message 2 a via header with a branch parameter containing the hash of the request URI from U1. Also note that because the request URI is different, as is the Via header, when this request is received by the proxy over again, it is viewed as a different request, and thus creates a new transaction. It is also NOT viewed as a loop, since the branch parameters in the Via indicate to the proxy that the previous time this request was received, the request URI was different. Now, in step 3, its forwarded to U2, and again the Via header is inserted, with a different branch paramter again, reflecting the hash of the request URI in message 2. When the response from U2 comes back, its forwarded from the proxy to itself, matched with the correct request because of the branch ID once more. It is then forwared to U1, and we're done. This approach effectively encodes the user part of the request URI into the Via header, as Ray was suggesting. However, by using the branch parameter, we remain backwards compatible and have greater flexibility. > > The suggestion for removing the sentence about the user part in the > > Request-URI of REGISTER requests is similarly motivated. There is no > > reason given in the rfc why the user part MUST be empty in a Request-URI > > for REGISTER. In our model, a client will want to REGISTER itself with > > the server representing it within the SIP Server. In practice, it would > > be sufficient to use the From or To field of the REGISTER to determine > > which server should be used, but in a large system, where the servers > > might be distributed among many hosts (even though they are seen as a > > single SIP server host to the outside world) it is more efficient to use > > the Request-URI for routing purposes so we want the user name to be part > > of the Request-URI. In this case, you should do your routing in a specialized way by looking at the To field, which truly tells you which registrar to go to. This is purely a local policy decision. Adding the user name to the request URI in REGISTER is also not backwards compatible. -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 Jun 2 11: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 LAA04494 for ; Fri, 2 Jun 2000 11:21: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 803B644354; Fri, 2 Jun 2000 11:12:01 -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 A899244337 for ; Fri, 2 Jun 2000 11:11:58 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA06763; Fri, 2 Jun 2000 11:21:22 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id LAA07248; Fri, 2 Jun 2000 11:21:21 -0400 (EDT) Date: Fri, 2 Jun 2000 11:21:21 -0400 (EDT) Message-Id: <200006021521.LAA07248@ind.cs.columbia.edu> From: Jonathan Lennox To: Jonathan Rosenberg Cc: Michael Thomas , Sean Olson , mshanka@unity.ncsu.edu, sip@lists.bell-labs.com Subject: Re: [SIP] CPL In-Reply-To: <393741A6.ED26ECEA@dynamicsoft.com> References: <200006011510.KAA06815@b04a45.exu.ericsson.se> <14646.48222.54575.33836@thomasm-u1.cisco.com> <393741A6.ED26ECEA@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 On Fri, June 2 2000, "Jonathan Rosenberg" wrote to "Michael Thomas, Sean Olson, mshanka@unity.ncsu.edu, sip@lists.bell-labs.com" saying: > Michael Thomas wrote: > > > > What I had in mind here is how would a proxy > > know what kinds of actions a given user with > > a given CPL script is allowed to do? It could > > be as simple as a binary decision of if you > > allow CPL at all, you allow any arbitrary > > script to be executed. > > The point of CPL is that it can't do too much to begin with. Its a > scripting language - there are no variables, no looping constructs, > nothing. There are six or so basic primitives defined - decision making > primitives that check the caller, callee, time of day, or priority, and > action primitives that can forward, reject, redirect. Thats mostly it. > As a result, CPL is safe to execute, since it simply can't do any damage > to a server. Thus, I believe the binary decision about authorization is > perfectly legitimate. > > That said, you *could* specify that a proxy should not accept CPLs from > user Joe that use the time-of-day switch statement, but why? It *is* possible that a CPL server could not support or be willing to support certain services for a partiuclar user. I think the most sensible example of this would be a server which will only redirect, not proxy (either in general or for a particular user). Another example would be a server which can't or won't proxy to certain URI schemes -- h323 (once that's defined), tel, etc. A CPL server needs to validate a script when it is inserted into the server -- for XML well-formedness, absence of dangling sub references, non-looping status, etc. It can (and should) check the script at the same time to make sure all the actions it specifies are allowed for the associated user, and reject it if it isn't. (This rejection mechanism depends on the submission mechanism; in draft-lennox-sip-reg it would be a 4xx response, for example.) That said, how the server *knows* which actions are legal for each user is entirely a local configuration/policy issue for the CPL server. Yes, the administrator needs some way of specifying it, but this isn't any different from all the other policy issues the server administrator needs to be able to control. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 2 13: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 NAA07658 for ; Fri, 2 Jun 2000 13:15: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 DF9634438F; Fri, 2 Jun 2000 13:06:00 -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 1A71F44337 for ; Fri, 2 Jun 2000 13:05:58 -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 KAA21181; Fri, 2 Jun 2000 10:15:35 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAC60683; Fri, 2 Jun 2000 10:12:42 -0700 (PDT) Message-Id: <4.2.0.58.20000602101135.00d2c570@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 02 Jun 2000 10:14:33 -0700 To: Alberto.Conte@ms.alcatel.fr From: Rohan Mahy Subject: Re: [SIP] INVITE with incomplete SDP description Cc: Lars Berggren , Jonathan Rosenberg , Neil Deason , IETF SIP In-Reply-To: <392E78D7.FD1C0F1C@ms.alcatel.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA07658 Alberto, I also agree with Jonathan, et al, that what you want is a minor optimization and is better served with a reINVITE, or INVITE+ACK. However, you may be interested in the discussions of SDPng in the mmusic WG. The goal is for SDPng to have much finer control over the details of capabilities negotiation, etc. thanks, -rohan At 06:15 AM 5/26/00 , Alberto Conte wrote: >Sorry, but I still disagree. > >I don't think that specifying what does it mean a port number = 0 in the >INVITE >message (which is at the moment not defined in the RFC 2543) is a way to >make the >protocol more complex. > >I think it is just a way to ensure implementation compatibility by >specifying how >this kind of message must be handled. That will never prevent to use the >solution >proposed by Jonathan. > >Alberto > >Lars Berggren a écrit : > > > > On Thu, 25 May 2000, Alberto Conte wrote: > > > > > Putting in hold the calle is a solution, but that increases the > number of messages to > > > be exchanged, requiring a re-INVITE transaction! > > > > > > The power of SIP is to reduce the message exchanged in case of no > error. And this is > > > actually a case of no-error. It should be better allowing the caller > to propose its > > > media request delaying only the RTP port information in the ACK. > > > > > > Alberto > > > > > > > I would rather think the power of SIP is its generality, flexibility and > > simplicity. A re-INVITE is a very general and powerful mechanism to > > accomplish many different tasks, including yours, so why not keep it that > > way instead of specifying special cases which tend to make the protocol > > more complex. > > > > /Lars > > > > Lars Berggren > > Intertex Data AB tel: +46-8-6282828 > > Sundbyberg, Sweden fax: +46-8-6286414 > > >_______________________________________________ >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 Jun 2 15: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 PAA10722 for ; Fri, 2 Jun 2000 15:15: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 4018044337; Fri, 2 Jun 2000 15:05:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id 3B45644336 for ; Fri, 2 Jun 2000 15:05:45 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id OAA15534 for ; Fri, 2 Jun 2000 14:17:07 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id OAA18381 for ; Fri, 2 Jun 2000 14:14:38 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 2 Jun 2000 14:14:38 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790E9@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] comments on draft-ietf-sip-100rel-01.txt Date: Fri, 2 Jun 2000 14:14:34 -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 > > Section 5.1, Paragraph 11: "It is not necessary to include the Supported > > header listing the option tag 100rel in the PRACK request." > Given the change that you can't send a reliable provisional response to > PRACK, it seems this text is actually fine - its not needed to include > this Supported header in PRACK. Given the change that you can't send a reliable provisional response to PRACK, perhaps the current text could remain, and an additional sentence prohibiting the use of "Require: 100rel" in a PRACK request should be added. Otherwise, somewhere we'd probably have to clarify what to do if a UAC requires reliable provisional responses, but the UAS is prohibited from sending them reliably. I'm still in the "no reliable provisional responses to a PRACK" camp. If they were allowed, then presumably the UAC would have the right to require them (unlike the proposed change above). This seems like it could lead to trouble in an environment where the UAC and UAS are implemented by different parties, who don't necessarily trust each other. Suppose a UAC requires all provisional responses to be sent reliably for all requests, and habitually includes "Require: 100rel" in its messages. That doesn't seem to be too much of a stretch, or to unequivocally imply a badly written UAC. And suppose a UAS desires to send a provisional response to a PRACK (I can't think of an obvious example here, but if *reliable* provisional responses are useful, certainly provisional responses must be useful to begin with!). This would lead to the never-ending series of PRACKs arriving at the UAS, and the UAS would have to decide not to send provisional responses at all to defend itself; if it sent a response, it'd be required to do so reliably, and that would result in yet another PRACK. Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 2 15:49: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 PAA11696 for ; Fri, 2 Jun 2000 15:49: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 12B8E4438F; Fri, 2 Jun 2000 15:39:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 52A8344336 for ; Fri, 2 Jun 2000 15:39:27 -0400 (EDT) Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA14443 for ; Fri, 2 Jun 2000 15:50:06 -0400 (EDT) Message-ID: <39380F9F.B2A0ADE1@dynamicsoft.com> Date: Fri, 02 Jun 2000 15:48:47 -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] SLP SIP templates now registered Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, At the last IETF, James Kempf presented a draft he and I co-wrote on using SLP to discover SIP servers. At the time, James was unsure of the process for registration of these templates. Later on, we discovered that a standards track RFC does NOT need to be generated. As a result, the templates from that draft were cleaned up, and are now officially registered with IANA. You can look them over at: ftp://ftp.isi.edu/in-notes/iana/assignments/svrloc-templates Please give them a glance and let the authors or the list know if there are any comments or issues. 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 Fri Jun 2 17:22: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 RAA14834 for ; Fri, 2 Jun 2000 17: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 E1B73443BE; Fri, 2 Jun 2000 17:13: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 DFD054438F for ; Fri, 2 Jun 2000 17:13:01 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id RAA14540; Fri, 2 Jun 2000 17:22:30 -0400 (EDT) Message-ID: <39382596.C22C6FF5@cisco.com> Date: Fri, 02 Jun 2000 17:22:30 -0400 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Forking proxy and Expires timer Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 question about the behavior of a forking proxy in a specific scenario. Here is the scenario : Proxy receives an INVITE with an Expires header (say 60 seconds) and forwards the INVITE to 2 locations. One location immediately returns 302 and the other returns 180 ringing (phone keeps ringing). After 60 seconds have elapsed, should the proxy return 408 Request Timedout or 302 Moved temporarily ( assuming that proxy is not recursive forking). Also, I am assuming that user agent will start the "Expires" timer on receipt of the first provisional and the proxy will start the "Expires" timer immediately after receiving the INVITE ( or the client's timer will expire before the proxy's). -- 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 Fri Jun 2 20:43: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 UAA17799 for ; Fri, 2 Jun 2000 20:43: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 B0026443EC; Fri, 2 Jun 2000 20:33:42 -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 345EE443D4 for ; Fri, 2 Jun 2000 20:33:40 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FVJ00F01ZBRQ6@firewall.mcit.com> for sip@lists.bell-labs.com; Sat, 3 Jun 2000 00:43:03 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FVJ00C9DZBR99@firewall.mcit.com>; Sat, 03 Jun 2000 00:43:03 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0FVJ00I01ZCFWI@dgismtp04.wcomnet.com>; Sat, 03 Jun 2000 00:43:27 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FVJ00I01ZCEWE@dgismtp04.wcomnet.com>; Sat, 03 Jun 2000 00:43:27 +0000 (GMT) Received: from C25776A ([166.46.19.120]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FVJ00A5BZCBKS@dgismtp04.wcomnet.com>; Sat, 03 Jun 2000 00:43:25 +0000 (GMT) Date: Fri, 02 Jun 2000 19:42:58 -0500 From: Henry Sinnreich Subject: RE: [SIP] SIP Application Server In-reply-to: <3937B7FB.BC71F9F7@dynamicsoft.com> To: Jonathan Rosenberg , Neil Deason Cc: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 fully agree with Jonathan. The whole point is not just to replicate what can be already done with AIN/PSTN, but for new services that produce new revenue. 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 >Jonathan Rosenberg >Sent: Friday, June 02, 2000 8:35 AM >To: Neil Deason >Cc: sip@lists.bell-labs.com >Subject: Re: [SIP] SIP Application Server > > > > >Neil Deason wrote: >> >> > I think you are over-analyzing the meaning of separation of >> > call-signaling from service control. In reality, >all services are >> > delivered eventually through signaling, and are >based on information >> > provided by signaling. Thus, service logic is >quite connected to call >> > signaling, and embedding a vanilla proxy in an app >server is quite a >> > good way to access it. I would argue this is quite >contrary to the IN >> > model, in which there is an attempt to use a >separate protocol for >> > service control to a separate box. Note however >that these protocols >> > carry much the same information as the signaling >protocols themselves. >> >> Agreed. It was not my analysis that SIP should be >used to try and separate out service control >> from call control. However, as was pointed out >earlier in this thread this could be achieved if >> SIP is used to separate a non-SIP signalling >protocol from service logic in a 'Softswitch' >> network. But then it appears that you would have a >separate protocol (SIP) for service control to >> a separate box (App Server). Such separation doesn't >really apply in the same way to the SIP part >> of the network and it sounds a lot like the >Softswitch network is a SIP network at the core. >> There you find SIP conversant App Servers and around >them are SIP Proxy Servers, SIP Redirect >> Servers and SIP User Agents. Some of these UAs may >in fact represent interfaces to PSTN or even >> H.323 gateways. Though how do protocols that don't >use SIP for signalling deliver all the rich >> new services that SIP enables when, for example, a >text/html payload gets discarded at the >> SIP/foo gateway. The point of SIP is surely not to >create LNP, 800 translation services in an App >> Server for protocols such as SS7, H.323 etc Yes, you >could recreate the IN this way but why not >> start out intending to build something better. You >achieve this by building Application Servers >> that empower the simple creation of innovative >services not Application Servers that merely >> recreate old services. > >I couldn't agree more with this sentiment. > >That said, I have a sneaking suspicion that people >will still want to >build these older services. Fortunately, most are >supported by SIP, and >can easily be built ontop of an applications server as >well. These >services (things like LNP and freephone) will work for >H.323 devices, >PSTN phones or ISDN phones accessing the SIP network >through a gateway >or softswitch. Even better, SIPs capabilities for negotiating >extensions, content, methods, and so on, will often >allow an app server >to know if the accessing device can support a more >innovative service. >In the example you give, where the app server returns HTML to a >softswitch, the app server can know apriori that HTML >is or isn't >supported (Accept: text/html in the INVITE). It could >then do something >different with the request for non-html access >devices, like forward it >to a media server running TTS or something, and read >out the web page. > >-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 Jun 3 00:08: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 AAA21806 for ; Sat, 3 Jun 2000 00: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 737B644413; Fri, 2 Jun 2000 23:58: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 DD84644412 for ; Fri, 2 Jun 2000 23:58:38 -0400 (EDT) Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00465; Sat, 3 Jun 2000 00:09:28 -0400 (EDT) Message-ID: <393884A9.EFB47104@dynamicsoft.com> Date: Sat, 03 Jun 2000 00:08:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Forking proxy and Expires timer References: <39382596.C22C6FF5@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 Shail Bhatnagar wrote: > > I have a question about the behavior of a forking proxy in a specific > scenario. Here is the scenario : > > Proxy receives an INVITE with an Expires header (say 60 seconds) and > forwards > the INVITE to 2 locations. One location immediately returns 302 and the > other > returns 180 ringing (phone keeps ringing). After 60 seconds have > elapsed, > should the proxy return 408 Request Timedout or 302 Moved temporarily ( > assuming that proxy is not recursive forking). 302, as the best response received. Consider timeout is the same as if 408 was actually received. > Also, I am assuming that user agent will start the "Expires" timer on > receipt > of the first provisional and the proxy will start the "Expires" timer > immediately after receiving the INVITE ( or the client's timer will > expire > before the proxy's) If Expires contains an exact date, then everyone has the same time. Even with delta-seconds, I would say its the time of sending the INVITE. If a UA places an Expires in the INVITE, it really doesn't need to *also* CANCEL the request itself when the timer expires. It could just as well do that without having the Expires in the INVITE. You can consider Expires as sort of asking the proxies to do the CANCEL for you. We should probably clarify that. -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 Sat Jun 3 11:26: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 LAA08997 for ; Sat, 3 Jun 2000 11:26: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 D4B464433A; Sat, 3 Jun 2000 11:16:42 -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 18B8A44336 for ; Sat, 3 Jun 2000 11:16:40 -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 KAA05745; Sat, 03 Jun 2000 10:27:58 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Sat, 3 Jun 2000 10:23:05 -0500 Message-ID: From: "Culpepper, Bert" To: Jonathan Rosenberg , Neil Deason Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP Application Server Date: Sat, 3 Jun 2000 10:23:05 -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 I'll confirm the suspicion that (some) people do want to deploy "older" services in a Softswitch/SIP network. As I've seen and heard many times, the IP network provides a very attractive (cost-wise) alternative to the circuit-switched/IN network for carrying telecommunications traffic. I like the ISC's goal hosting applications on a separate server from the Softswitch. And using SIP as the protocol between these two devices makes creating and deploying new services easy compared to doing the same thing in the PSTN. However, the standards work needed to extend SIP to support deploying existing PSTN-like services in an IP network (and to "seamlessly" integrate the PSTN & IP networks) still has a way to go. Specifically, carrying DTMF out-of-band and within SIP. I'm aware of two specific drafts proposing methods but have not seen nor found any discussion or consensus within the SIP WG. Hopefully, interest in this issue will occur at some point. Regards, Bert Bert Culpepper InterVoice-Brite, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, June 02, 2000 9:35 AM > To: Neil Deason > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP Application Server > > > > > Neil Deason wrote: > > > > > I think you are over-analyzing the meaning of separation of > > > call-signaling from service control. In reality, all services are > > > delivered eventually through signaling, and are based on information > > > provided by signaling. Thus, service logic is quite connected to call > > > signaling, and embedding a vanilla proxy in an app server is quite a > > > good way to access it. I would argue this is quite contrary to the IN > > > model, in which there is an attempt to use a separate protocol for > > > service control to a separate box. Note however that these protocols > > > carry much the same information as the signaling protocols themselves. > > > > Agreed. It was not my analysis that SIP should be used to try and > > separate out service control > > from call control. However, as was pointed out earlier in this > > thread this could be achieved if > > SIP is used to separate a non-SIP signalling protocol from service > > logic in a 'Softswitch' > > network. But then it appears that you would have a separate protocol > > (SIP) for service control to > > a separate box (App Server). Such separation doesn't really apply in > > the same way to the SIP part > > of the network and it sounds a lot like the Softswitch network is a > > SIP network at the core. > > There you find SIP conversant App Servers and around them are SIP > > Proxy Servers, SIP Redirect > > Servers and SIP User Agents. Some of these UAs may in fact represent > > interfaces to PSTN or even > > H.323 gateways. Though how do protocols that don't use SIP for > > signalling deliver all the rich > > new services that SIP enables when, for example, a text/html payload > > gets discarded at the > > SIP/foo gateway. The point of SIP is surely not to create LNP, 800 > > translation services in an App > > Server for protocols such as SS7, H.323 etc Yes, you could recreate > > the IN this way but why not > > start out intending to build something better. You achieve this by > > building Application Servers > > that empower the simple creation of innovative services not > > Application Servers that merely > > recreate old services. > > I couldn't agree more with this sentiment. > > That said, I have a sneaking suspicion that people will still want to > build these older services. Fortunately, most are supported by SIP, > and > can easily be built ontop of an applications server as well. These > services (things like LNP and freephone) will work for H.323 devices, > PSTN phones or ISDN phones accessing the SIP network through a gateway > or softswitch. Even better, SIPs capabilities for negotiating > extensions, content, methods, and so on, will often allow an app > server > to know if the accessing device can support a more innovative service. > In the example you give, where the app server returns HTML to a > softswitch, the app server can know apriori that HTML is or isn't > supported (Accept: text/html in the INVITE). It could then do > something > different with the request for non-html access devices, like forward > it > to a media server running TTS or something, and read out the web page. > > -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 Sun Jun 4 02:50: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 CAA28822 for ; Sun, 4 Jun 2000 02:50: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 D8DF144339; Sun, 4 Jun 2000 02:40:23 -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 C4C4044336 for ; Sun, 4 Jun 2000 02:40:20 -0400 (EDT) Received: from dynamicsoft.com (dwillis4.directlink.net [63.64.250.85]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id MAA16970; Sun, 4 Jun 2000 12:52:05 -0500 Message-Id: <200006041752.MAA16970@kevlar.softarmor.com> Date: Sun, 04 Jun 2000 01:41:32 -0500 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Linden deCarmo Cc: "'Glenn Morrow'" , sip@lists.bell-labs.com Subject: Re: [SIP] Suspend a session?? References: <6C5713970B1FD411ACBE00AA00DCD9A60B3EEB@crash.engineering.netspeak.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 suspect I don't like what you're attempting to achieve, but methinks the friendly UA could always submit an appropriate INFO method which the "billing proxy" could use to determine an appropriate action. AS has been pointed out here, it is that UA that is responsible for translating user action into appropriate signaling. One might also ask WHY and end device would choose to use a "time billing proxy" rather than routing around said proxy. There are probably some cases involving proxy-moderated firewalls and QoS sessions, but I still suspect the fundamental approach is somehow flawed. -- Dean Linden deCarmo wrote: > > Here's the problem with the UA doing it: > > User goes on hook (time 0 ). UA starts timer. > Timer expires (time 30 seconds). UA realizes session expires so it issues a > BYE. > > Since the proxy sees the BYE 30 seconds later, thats when it stops billing. > I do not believe your solution addresses how the UA signals to the proxy > that billing should stop at time 0 rather than time 30. > > I realize I can do this with a proprietary method or header, but I'd rather > not. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > > -----Original Message----- > > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] > > Sent: Thursday, June 01, 2000 11:38 AM > > To: sip@lists.bell-labs.com > > Subject: RE: [SIP] Suspend a session?? > > > > It seems to me that this should be handled by the UA itself. Once the UA > > determines the correct functionilty that the real end-device/user wishes > > to achieve, it should signal proxies and far-end stations. For instance a > > legacy device may which to indicate flash and collect more digits for a > > 3-way call by the user using the hook as you say. > > > > This would result in a separate transaction but I believe it doesn't > > require something like a "suspend" method or indication at the SIP level. > > > > > > I suggest that the UA itself should handle this with timers, etc.. based > > upon the physical device and human interface it is trying to achieve. > > > > For the billing issue the UA could simply use a timer started based on > > physical off-hook stimulus to determine when to actually send a BYE or > > not. > > > > If this doesn't address your concerns please let me know. > > > > -----Original Message----- > > From: Linden deCarmo [SMTP:ldeCarmo@netspeak.com] > > Sent: Wednesday, May 31, 2000 1:54 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Suspend a session?? > > > > Right now, SIP smoothly handles one party putting another party on > > hold via > > a re-INVITE with modified SDP. However, we have a scenario where the > > session needs to be suspended (not just placed on hold), and I'm not sure > > how this can be done without using proprietary headers. > > > > Here are ther details. If party A calls party B , party B should be > > able to > > hang up without immediately terminating the session. If party B picks up > > the phone within some prescribed time window, the session continues. > > However, if they don't pick it up within the time window, the session > > terminates (via a BYE). > > > > We're looking for a mechanism for party B to communicate with either > > party A > > or a proxy server, to inform the distant party that the session has been > > suspended, and not just placed on hold. The primary motivator for this > > notification is billing. Without notification of suspension, its > > impossible > > to determine when to safely stop billing. > > > > Thanks. > > > > Linden deCarmo > > Netspeak Corporation > > 902 Clint Moore Road > > Suite 104 > > Boca Raton, FL 33487 > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.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 Jun 4 09:28: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 JAA07532 for ; Sun, 4 Jun 2000 09:28: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 A6CB14433B; Sun, 4 Jun 2000 09:18:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.192.45]) by lists.bell-labs.com (Postfix) with ESMTP id 0962B44336 for ; Sun, 4 Jun 2000 09:18:17 -0400 (EDT) Received: from [193.118.192.41] by cundall.co.uk with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 4 Jun 2000 14:26:54 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Sun, 4 Jun 2000 14:27:53 +0100 To: sip@lists.bell-labs.com From: Lawrence Conroy Cc: pint@lists.research.bell-labs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SIP] Basic 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 * There have been a number of comments that SDP carried with SIP needs at least one RTP session:- To which I reply... Nooooooo.... For VoIP/Games/... usage of SIP I like the delayed media sessions section of the bis draft. Please don't dump it, even though this has no media sessions at all in the SDP. Even for not-transient situations, we MAY have this situation...for example, PINT doesn't use RTP sessions, but it still has SDP. I suspect that the ATM stuff may NOT use RTP either - one may find VoATM distasteful, but there are customers for it; SIP/SDP may be used as a hybrid. Whilst for VoIP sessions, lack of an RTP media session is strange, this is not always true, even when SIP is being used. -- All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd pay me for them" | |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jun 4 09:48: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 JAA07658 for ; Sun, 4 Jun 2000 09:48: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 CF33E44338; Sun, 4 Jun 2000 09:38:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.192.45]) by lists.bell-labs.com (Postfix) with ESMTP id E697B4434F for ; Sun, 4 Jun 2000 09:37:27 -0400 (EDT) Received: from [193.118.192.41] by cundall.co.uk with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 4 Jun 2000 14:46:24 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Sun, 4 Jun 2000 14:47:20 +0100 To: sip@lists.bell-labs.com From: Lawrence Conroy Cc: pint@lists.research.bell-labs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SIP] UDP support changed from SHOULD to MUST Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com * UDP support changed from SHOULD to MUST in SIP 2453 bis draft. It looks like support for UDP is gradually moving from a SHOULD to a MUST in SIP. In PINT we may not have that assumption. We can have a good reason for using TCP only (inline content, security using TLS, ...), so *for PINT* I'd prefer to leave this as a SHOULD. I wonder if the move to a MUST in the core spec will cause grief for any other extension or application. The key point here is ->in the core spec<- I had the same feeling at the Interim meeting in D.C. when the subject of "Busy Line Verification" was raised - there's a lot of focus on VoIP, when I can easily imagine SIP being used for a much wider set of applications even for "straight" conferences; for example, Quake, as Dean suggests. Let's imagine an Operator listening in on the sampled Quake audio track that I'm conferencing. How long before the Police arrive? An over-emphasis on VoIP can lead to bad assumptions, IMHO - SIP is much wider than that. -- lwc@roke.co.uk -- +44 1794 833666 ------------------------------------------------------------- Herewith a pointless waste of a few lines, stating that Roke Manor Research Limited is NOT responsible for my rantings and that they would very much like people to sue me rather than them if this email contains racist or sexist comments, please. Also, I can't do anything; only our lawyers can, so speak to them. Oh, and by the way, if our I.T. department has so mangled our email system that this has been misdirected, beware that having read this far, your eyes are about to fall out from reading this highly sensitive information, unless you immediately forget that this ever darkened your mailbox. Do it now. ------------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jun 4 10:27: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 KAA07881 for ; Sun, 4 Jun 2000 10:27: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 C4ED844344; Sun, 4 Jun 2000 10:17: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 911D844336 for ; Sun, 4 Jun 2000 10:17:17 -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 KAA29555; Sun, 4 Jun 2000 10:27:00 -0400 (EDT) Message-ID: <393A6734.BD9A4A5C@cs.columbia.edu> Date: Sun, 04 Jun 2000 10:27:00 -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: Plong@smithmicro.com, sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions References: <001001bfc9aa$941216e0$6701a8c0@plong> <3933360B.973E87B7@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: > > > > > - "...the H.245 [8] gateway and user address and then use H.225.0 [9] to > > establish the call." - What is meant by an "H.245 gateway address" and an > > "H.245 user address?" There is no such thing. I assume that the author is > > referring to the H.323 call-signaling addresses of a gateway and endpoint. > > There is an H.245 control-protocol address, but if a separate H.245 channel > > is even used, the address is conveyed during call establishment and not > > before. > > You are of course correct; this should be H.323 call signaling address. Actually, this was intentional. In the days of H.323v1, pre-Fast Connect, one could imagine a scenario where you do a normal SIP INVITE and then obtain the address of the peer. H.245 would then be used to negotiate codecs and open logical channels. Clearly, this would not work with any existing H.323 implementation, but I don't see why it couldn't be made to work. However, the example may be too contrived to be useful. (However, the straight combination with H.323 doesn't make a whole lot of sense. Why would you have the mailman ring twice?) > > > > > - The word, "program,: is used throughout the RFC. Is this any functional > > entity regardless of implementation and not exclusively a "software > > program?" > > Of course. It is somewhat unlikely that you would implement SIP as hard-wired logic gates or via air valves (yes, there were air valve logic gates at some point...), so I'm confused as to why program is restricting your choices. > > The role of UAC and UAS is on a request by request basis, NOT a call by > call basis. This is probably confusing from the spec, as much of it was > written considering the initial INVITE request, for which caller and UAC > are the same. I tried to clarify the per-request nature of the UA* notion. -- 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 Jun 4 11:30: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 LAA08265 for ; Sun, 4 Jun 2000 11:30: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 08FCA4434F; Sun, 4 Jun 2000 11:20: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 4EEC444336 for ; Sun, 4 Jun 2000 11:20: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 LAA03034; Sun, 4 Jun 2000 11:30:00 -0400 (EDT) Message-ID: <393A75F8.BFCF24D8@cs.columbia.edu> Date: Sun, 04 Jun 2000 11:30:00 -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: Lars Berggren , sip@lists.bell-labs.com Subject: Re: [SIP] Record-Route (Was: Contact in OPTIONS) References: <39327206.F1E3AD95@cs.columbia.edu> <393324A7.92C23B65@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: > > In addition to this, we can define an explicit "remove me" record-route > entry. Something like: > > Remove-Route: ;remove=true > > Proxies would add this when they want out. A UA not understanding this > will ignore out continue to use the old route, but a new UA would know > that this means to remove it from the Route in the next request. I think > this is also backwards compatible. > > Both of these mechanisms combined (remove-route and adding record-route > for mid-call messages) has the desired result of being backwards > compatible, providing for restarts after crashes, and allowing proxies > to remove themselves during a call. Since this is something that can be added later if there's a real, demonstrated example, my inclination would be to leave it out of the base spec at this point as it does impose non-trivial implementation effort. (In order to stay in the spec for Draft, we have to show two implementations in any event.) Another wrinkle in this Record-Route business is that we could presumably define a hiding mechanism similar to Via hiding mechanism. (The details would have to differ, since it's the upstream proxy that would have to do the encryption). Is this useful? Personally, I'd rather not add this complexity. Via hiding itself doesn't seem to be the most-implemented feature at this stage... Currently, there's a silent (and reasonable) assumption that the UAC issuing the first request inserts a RR. However, would there be a use for the UAS receiving that request doing this? Clearly, this would only make sense if that request isn't routed directly, i.e., typically, if the first INVITE didn't contain a Contact header. Is this useful enough to be described explicitly? Any existing implementations deal with this gracefully? Henning -- 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 Jun 4 22:20: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 WAA12029 for ; Sun, 4 Jun 2000 22:20: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 94EF744355; Sun, 4 Jun 2000 22:10:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from avmail.smithmicro.com (avmail.smithmicro.com [209.218.67.201]) by lists.bell-labs.com (Postfix) with ESMTP id D369C44353 for ; Sun, 4 Jun 2000 22:10:00 -0400 (EDT) Received: by AVMAIL with Internet Mail Service (5.5.2650.21) id ; Sun, 4 Jun 2000 19:20:05 -0700 Received: from plong (adsl-32.statton.austx.uSOLnet.net [63.80.75.161]) by avmail.smithmicro.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MC9Z70TX; Sun, 4 Jun 2000 19:20:03 -0700 From: Paul Long To: "'Henning Schulzrinne'" , "'Jonathan Rosenberg'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Basic questions Date: Sun, 4 Jun 2000 21:19:34 -0500 Message-ID: <000e01bfce94$7fd35060$6701a8c0@plong> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <393A6734.BD9A4A5C@cs.columbia.edu> 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 Henning, Re: H.245 addresses Intentional? I don't understand. There is no such thing, per se, as an H.245 gateway address or an H.245 user address. A gateway and endpoint (I assume this is what is meant by "user") are canonically identified through their respective call-signaling addresses. The address of the H.245 control channel may then be conveyed via call signaling. One cannot first get the H.245 gateway and user address and _then_ use H.225.0 (I assume this refers to call signaling) to establish the call. It's the other way around. Re: "program" Yeah, I was being pedantic. :-) It just gives me the willies to see implementation-specific terminology in a functional specification, even though, yes, it would be very silly to use mechanical relays, air valves, or uh... sticks and stones :-) ... to implement a SIP entity. Re: UAC/UAS I was just reading rfc2543bis-00 and don't remember seeing a clarification of this. It would have been helpful because one usually thinks of clients and servers as types or roles of entities rather than types of transactions. Not a big deal, though. Paul Long Smith Micro Software, Inc. -----Original Message----- From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]On Behalf Of Henning Schulzrinne Sent: Sunday, June 04, 2000 9:27 AM To: Jonathan Rosenberg Cc: Plong@smithmicro.com; sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions Jonathan Rosenberg wrote: > > > > > - "...the H.245 [8] gateway and user address and then use H.225.0 [9] to > > establish the call." - What is meant by an "H.245 gateway address" and an > > "H.245 user address?" There is no such thing. I assume that the author is > > referring to the H.323 call-signaling addresses of a gateway and endpoint. > > There is an H.245 control-protocol address, but if a separate H.245 channel > > is even used, the address is conveyed during call establishment and not > > before. > > You are of course correct; this should be H.323 call signaling address. Actually, this was intentional. In the days of H.323v1, pre-Fast Connect, one could imagine a scenario where you do a normal SIP INVITE and then obtain the address of the peer. H.245 would then be used to negotiate codecs and open logical channels. Clearly, this would not work with any existing H.323 implementation, but I don't see why it couldn't be made to work. However, the example may be too contrived to be useful. (However, the straight combination with H.323 doesn't make a whole lot of sense. Why would you have the mailman ring twice?) > > > > > - The word, "program,: is used throughout the RFC. Is this any functional > > entity regardless of implementation and not exclusively a "software > > program?" > > Of course. It is somewhat unlikely that you would implement SIP as hard-wired logic gates or via air valves (yes, there were air valve logic gates at some point...), so I'm confused as to why program is restricting your choices. > > The role of UAC and UAS is on a request by request basis, NOT a call by > call basis. This is probably confusing from the spec, as much of it was > written considering the initial INVITE request, for which caller and UAC > are the same. I tried to clarify the per-request nature of the UA* notion. -- 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 Jun 4 22: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 WAA12062 for ; Sun, 4 Jun 2000 22:27: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 1E22544372; Sun, 4 Jun 2000 22:17:35 -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 AC06C44371 for ; Sun, 4 Jun 2000 22:17:32 -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 WAA08699; Sun, 4 Jun 2000 22:27:12 -0400 (EDT) Message-ID: <393B1008.5D09065C@cs.columbia.edu> Date: Sun, 04 Jun 2000 22:27:20 -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: Paul Long Cc: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions References: <000e01bfce94$7fd35060$6701a8c0@plong> 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 Paul Long wrote: > > Henning, > > Re: H.245 addresses > Intentional? I don't understand. There is no such thing, per se, as an H.245 > gateway address or an H.245 user address. A gateway and endpoint (I assume > this is what is meant by "user") are canonically identified through their > respective call-signaling addresses. The address of the H.245 control > channel may then be conveyed via call signaling. One cannot first get the > H.245 gateway and user address and _then_ use H.225.0 (I assume this refers > to call signaling) to establish the call. It's the other way around. That's exactly my point. SIP in this fictitious scenario replaces H.225.0. You then use the IP address and port obtained by SIP for the H.245 control channel. Yes, it's contrived. > > Re: "program" > Yeah, I was being pedantic. :-) It just gives me the willies to see > implementation-specific terminology in a functional specification, even > though, yes, it would be very silly to use mechanical relays, air valves, or > uh... sticks and stones :-) ... to implement a SIP entity. I take concreteness over vagueness any day :-) > > Re: UAC/UAS > I was just reading rfc2543bis-00 and don't remember seeing a clarification > of this. It would have been helpful because one usually thinks of clients > and servers as types or roles of entities rather than types of transactions. > Not a big deal, though. It will appear whenever I get a chance to LaTeX the sources again. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jun 4 22:53: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 WAA13068 for ; Sun, 4 Jun 2000 22: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 CD57D44366; Sun, 4 Jun 2000 22:43: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 5406044353 for ; Sun, 4 Jun 2000 22:43:24 -0400 (EDT) Received: from dynamicsoft.com (1Cust107.tnt4.freehold.nj.da.uu.net [63.36.112.107]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00510; Sun, 4 Jun 2000 22:54:21 -0400 (EDT) Message-ID: <393B160F.BFC6C444@dynamicsoft.com> Date: Sun, 04 Jun 2000 22:53:03 -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: Lars Berggren , sip@lists.bell-labs.com Subject: Re: [SIP] Record-Route (Was: Contact in OPTIONS) References: <39327206.F1E3AD95@cs.columbia.edu> <393324A7.92C23B65@dynamicsoft.com> <393A75F8.BFCF24D8@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: > > Jonathan Rosenberg wrote: > > > > > In addition to this, we can define an explicit "remove me" record-route > > entry. Something like: > > > > Remove-Route: ;remove=true > > > > Proxies would add this when they want out. A UA not understanding this > > will ignore out continue to use the old route, but a new UA would know > > that this means to remove it from the Route in the next request. I think > > this is also backwards compatible. > > > > Both of these mechanisms combined (remove-route and adding record-route > > for mid-call messages) has the desired result of being backwards > > compatible, providing for restarts after crashes, and allowing proxies > > to remove themselves during a call. > > Since this is something that can be added later if there's a real, > demonstrated example, my inclination would be to leave it out of the > base spec at this point as it does impose non-trivial implementation > effort. (In order to stay in the spec for Draft, we have to show two > implementations in any event.) I agree. > > Another wrinkle in this Record-Route business is that we could > presumably define a hiding mechanism similar to Via hiding mechanism. > (The details would have to differ, since it's the upstream proxy that > would have to do the encryption). Is this useful? Personally, I'd rather > not add this complexity. Via hiding itself doesn't seem to be the > most-implemented feature at this stage... Via hiding is not stricly needed; only if you want to be stateless AND hide the route. The far easier approach is simply strip off the via list, store it, and insert a fresh Via header with some public address you are not afraid to show to the world, in order to get the response. When the response comes, slap back on the old Via list, and off you go. I'll also note that Via hiding always worried me because it relied on the *next hop* to encrypt for you; what if the trust relationship is such that they might not do this for you? Better off protect yourself than trust the next hop to do so. So, I would agree that adding this for Record-Route is probably not needed. > > Currently, there's a silent (and reasonable) assumption that the UAC > issuing the first request inserts a RR. You mean insert or doesn't insert? UAC doesn't insert an RR.... > However, would there be a use > for the UAS receiving that request doing this? Clearly, this would only > make sense if that request isn't routed directly, i.e., typically, if > the first INVITE didn't contain a Contact header. Is this useful enough > to be described explicitly? Any existing implementations deal with this > gracefully? Assuming you meant "doesn't" above, I see no need to explicitly indicate this, since Contact more or less plays the role of the UA record-route. -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 Jun 4 22:57: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 WAA13088 for ; Sun, 4 Jun 2000 22:57: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 4AC4744378; Sun, 4 Jun 2000 22:47: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 6F7534436E for ; Sun, 4 Jun 2000 22:47:45 -0400 (EDT) Received: from dynamicsoft.com (1Cust107.tnt4.freehold.nj.da.uu.net [63.36.112.107]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00514; Sun, 4 Jun 2000 22:58:55 -0400 (EDT) Message-ID: <393B1720.1A3AC5BC@dynamicsoft.com> Date: Sun, 04 Jun 2000 22:57:36 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Conroy Cc: sip@lists.bell-labs.com, pint@lists.research.bell-labs.com Subject: Re: [SIP] UDP support changed from SHOULD to MUST 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 Lawrence Conroy wrote: > > * UDP support changed from SHOULD to MUST in SIP 2453 bis draft. > It looks like support for UDP is gradually moving from a SHOULD to a > MUST in SIP. It was to solve the sticky situation that without at least a common transport, UA to UA communication would not be possible. It would require proxies that do conversions to record-route, and all kinds of other stuff. Simply stating that everyone needs to use UDP made things much easier, and in any case, I suspect nearly everyone does UDP anyway. However, please shout if this change is not a happy one for you.... In the case of pint, I would simply suggest that all pint implementations MUST support TCP as well, in which case you won't have a problem. Yes, you'll have to do UDP also to be compliant to the baseline spec, but it turns out that supporting both is really not that hard if done properly. > I had the same feeling at the Interim meeting in D.C. when the > subject of "Busy Line Verification" was raised - there's a lot of > focus on VoIP, when I can easily imagine SIP being used for a much > wider set of applications even for "straight" conferences; for > example, Quake, as Dean suggests. This change has exactly zero to do with telephony. Its as simple as UA to UA communication not being always possible without a common baseline transport. -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 Jun 4 23:06: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 XAA13188 for ; Sun, 4 Jun 2000 23:06: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 D7B0C44396; Sun, 4 Jun 2000 22:56:43 -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 70A3E44393 for ; Sun, 4 Jun 2000 22:56:41 -0400 (EDT) Received: from dynamicsoft.com (1Cust107.tnt4.freehold.nj.da.uu.net [63.36.112.107]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00523; Sun, 4 Jun 2000 23:07:42 -0400 (EDT) Message-ID: <393B192F.80F341BC@dynamicsoft.com> Date: Sun, 04 Jun 2000 23:06:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: Linden deCarmo , "'Glenn Morrow'" , sip@lists.bell-labs.com Subject: Re: [SIP] Suspend a session?? References: <6C5713970B1FD411ACBE00AA00DCD9A60B3EEB@crash.engineering.netspeak.com> <200006041752.MAA16970@kevlar.softarmor.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 Dean Willis wrote: > > I suspect I don't like what you're attempting to achieve, but methinks > the friendly UA could always submit an appropriate INFO method which the > "billing proxy" could use to determine an appropriate action. May as well use a new method, and call it FREECALL ;) Seriously, though, developing extensions with known monstorously large security holes doesn't help anyone. If a new method were defined, people will think that it is generally useful and apply it in cases where a trust relationship between the UA and proxy does not exist. Counting on friednly UAs is like counting on people not to send spam or generate viruses.... -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 Jun 4 23:17: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 XAA13253 for ; Sun, 4 Jun 2000 23:17: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 EEB33443B2; Sun, 4 Jun 2000 23:07:44 -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 8FF01443B1 for ; Sun, 4 Jun 2000 23:07:42 -0400 (EDT) Received: from dynamicsoft.com (1Cust107.tnt4.freehold.nj.da.uu.net [63.36.112.107]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00535; Sun, 4 Jun 2000 23:18:23 -0400 (EDT) Message-ID: <393B1BB0.F09B206C@dynamicsoft.com> Date: Sun, 04 Jun 2000 23:17:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Schroeder, Tim" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] comments on draft-ietf-sip-100rel-01.txt References: <4D45BA2A58A7D3119E050008C7E69E290790E9@trimail2.tri.sbc.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 "Schroeder, Tim" wrote: > > > > Section 5.1, Paragraph 11: "It is not necessary to include the Supported > > > header listing the option tag 100rel in the PRACK request." > > > Given the change that you can't send a reliable provisional response to > > PRACK, it seems this text is actually fine - its not needed to include > > this Supported header in PRACK. > > Given the change that you can't send a reliable provisional response to > PRACK, perhaps the current text could remain, and an additional sentence > prohibiting the use of "Require: 100rel" in a PRACK request should be added. > Otherwise, somewhere we'd probably have to clarify what to do if a UAC > requires reliable provisional responses, but the UAS is prohibited from > sending them reliably. I added this wording. > > I'm still in the "no reliable provisional responses to a PRACK" camp. Well, since there were two folks speaking against it, and I spoke for it but was on the fence, consensus seemed to be to remove it, so its gone - issue resolved. -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 Jun 5 06:56: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 GAA28001 for ; Mon, 5 Jun 2000 06:56: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 2449B44348; Mon, 5 Jun 2000 06:46:04 -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 0A85B4433C for ; Mon, 5 Jun 2000 06:46:01 -0400 (EDT) Received: by EXCHANGESVR with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 03:56:27 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@lists.bell-labs.com'" Date: Mon, 5 Jun 2000 03:56:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Via discrepancy in latest 2543bis 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, I believe that the first point in "Appendix G: Changes to be made" is invalid and should be removed. Section 6.45.3 and 6.45.4 [Handling of Via's in requests] are in contradiction to this statement: * Bug: UDP spec not clear on whether responses sent to source port or port in Via. Should use port in Via. I am guessing that this is merely an oversight as Section 10.2.1 had a similar statement which was changed in the last draft version to agree with Section 6.45.3 & 4. Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 5 07:00: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 HAA28371 for ; Mon, 5 Jun 2000 07:00: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 EF7394436E; Mon, 5 Jun 2000 06:50:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by lists.bell-labs.com (Postfix) with SMTP id 66D164436B for ; Mon, 5 Jun 2000 06:50:45 -0400 (EDT) Received: from unknown (HELO archimede) (193.205.242.44) by smtp.mail.yahoo.com with SMTP; 5 Jun 2000 04:00:21 -0700 X-Apparently-From: Message-ID: <005301bfcedc$b9ab4700$2cf2cdc1@coritel.it> From: "raf" To: Date: Mon, 5 Jun 2000 12:56:22 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01BFCEED.7379DB00" 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] Information Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_0050_01BFCEED.7379DB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I need of a clarification about SIP. I don`t know if these addresses = are the right places!!! I am developing a NAT module properly for SIP. I have two scenarios: the = first with a SIP Client behind the NAT router (In a private realm), the second with a SIP Client = and a SIP SERVER behind a NAT router both. My NAT Module is listening on port 5060 UDP and it = works when a UDP packet port=20 5060 flows throgh the NAT router. This module works well when it is = crossed by an Invite directly produced by a SIP Client. Viceversa it doesn`t work when it is crossed by an Invite = produced by a SIP Server. The two Invites are different in the context: In SDP and in some fileds like VIA!!!=20 Are there other differences ????=20 My module works only on the UDP header and in the case of port 5060 processing SDP and change prvate = addresses!!! Thans a lot, Raffaele Pellicciotta ------=_NextPart_000_0050_01BFCEED.7379DB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, I need of a clarification about = SIP. I don`t=20 know if these addresses are the right places!!!
I am developing a NAT module = properly for SIP.=20 I have two scenarios: the first with a SIP Client
behind the NAT router (In a private = realm), the=20 second with a SIP Client and a SIP SERVER behind
a NAT router both. My NAT Module is = listening on=20 port 5060 UDP and it works when a UDP packet port
5060 flows throgh the NAT router. This = module works=20 well when it is crossed by an Invite directly produced by
a SIP Client. Viceversa it doesn`t work = when it is=20 crossed by an Invite produced by a SIP Server. The two Invites are=20 different
in the context: In SDP and in some = fileds like=20 VIA!!!
Are there other differences = ????=20
My module works only on the UDP = header
and in the case of port 5060 processing = SDP and=20 change prvate addresses!!!
Thans a lot,
    Raffaele=20 Pellicciotta
------=_NextPart_000_0050_01BFCEED.7379DB00-- __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.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 Jun 5 07: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 HAA29072 for ; Mon, 5 Jun 2000 07: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 175964434E; Mon, 5 Jun 2000 07:40:46 -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 637834433C for ; Mon, 5 Jun 2000 07:40:43 -0400 (EDT) Received: by EXCHANGESVR with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 04:51:11 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Via discrepancy in latest 2543bis draft. Date: Mon, 5 Jun 2000 04:51:10 -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 Wait up ... quick back pedal ... now I'm not so sure. As written in Section 6.45.4 it does suggest that you would use the source port over the Via port (as the "sent-by" includes the port part) but is this the best thing to do ? We know this Via scheme won't work for a NAPT (without a SIP proxy sitting on the firewall as well) so perhaps we should be using the port in the Via. This at least allows SIP user-agent spawning to function normally across a NAT. Anyway, there is definitely a need for clarification here. Cheers, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 5 09: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 JAA02351 for ; Mon, 5 Jun 2000 09: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 65DFC4433C; Mon, 5 Jun 2000 09:44:55 -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 DF26B44336 for ; Mon, 5 Jun 2000 09:44:32 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA20019; Mon, 5 Jun 2000 14:51:30 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: , Date: Mon, 5 Jun 2000 14:06:46 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: Sip Mail List MIME-Version: 1.0 Message-Id: <00060514494000.05662@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] RFC 2806 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, I have noticed an inconsistency between the rfc you have authored (RFC 2806 URL's for Telephone Calls) and the SIP RFC. In Section 2.2, you reference the SIP RFC within the BNF for future-extension as follows: future-extension = ";" 1*(token-char) ["=" ((1*(token-char) ["?" 1*(token-char)]) / quoted-string )] ; See section 2.5.11 and [RFC2543] My concern is over the quoted-string part of this. We recently had a long discussion on the Sip Mailing list and concluded (among other things :) )that quoted strings should not be a part of the Sip-URL as it contravines the URI syntax outlined in RFC 2396 (See section 2.4.3 of RFC 2396 where it declares the <"> character as excluded). In fact, the new SIP BNF currently stands at: other-param = pname | pname = pvalue pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved | unreserved | escaped param-unreserved = / | : | @ | & | + | $ | , could you please let me know if you agree with this conclusion. thanx for your time 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 Mon Jun 5 10:36: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 KAA03358 for ; Mon, 5 Jun 2000 10:36: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 8364D4434B; Mon, 5 Jun 2000 10:26:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sonusdc3.sonusnet.com (mail.sonusnet.com [63.99.71.102]) by lists.bell-labs.com (Postfix) with ESMTP id C4C3944336 for ; Mon, 5 Jun 2000 10:26:08 -0400 (EDT) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 10:35:59 -0400 Message-ID: <9581851D1FB3D21199190090273A74450143A750@sonusdc3.sonusnet.com> From: "Farahmand, Fardad" To: Henry Sinnreich Cc: sip@lists.bell-labs.com, Jonathan Rosenberg , Neil Deason Subject: RE: [SIP] SIP Application Server Date: Mon, 5 Jun 2000 10:35: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 I agree. There is no question that it will be the potential and ease of creating and deploying new services that will be needed to initiate the mass migration to the next generation network. I find it hard to believe that there would be folks that don't think this way. However, I do believe that for a long time to come, the new network must support integration with existing device, service functionality and network infrastructure. You can think of this as the bridge that will bring about the migration. As Jonathan mentioned, the strategy in application development can be to provide as many features as a particular device is capable of handling. The SoftSwitch with its SIP interface can provide network transparency where it is needed. Fardad Farahmand ffarahmand@sonusnet.com > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com] > Sent: Friday, June 02, 2000 8:43 PM > To: Jonathan Rosenberg; Neil Deason > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP Application Server > > > I fully agree with Jonathan. The whole point is not just to > replicate what can be already done with AIN/PSTN, but for new > services that produce new revenue. > > 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 > >Jonathan Rosenberg > >Sent: Friday, June 02, 2000 8:35 AM > >To: Neil Deason > >Cc: sip@lists.bell-labs.com > >Subject: Re: [SIP] SIP Application Server > > > > > > > > > >Neil Deason wrote: > >> > >> > I think you are over-analyzing the meaning of separation of > >> > call-signaling from service control. In reality, > >all services are > >> > delivered eventually through signaling, and are > >based on information > >> > provided by signaling. Thus, service logic is > >quite connected to call > >> > signaling, and embedding a vanilla proxy in an app > >server is quite a > >> > good way to access it. I would argue this is quite > >contrary to the IN > >> > model, in which there is an attempt to use a > >separate protocol for > >> > service control to a separate box. Note however > >that these protocols > >> > carry much the same information as the signaling > >protocols themselves. > >> > >> Agreed. It was not my analysis that SIP should be > >used to try and separate out service control > >> from call control. However, as was pointed out > >earlier in this thread this could be achieved if > >> SIP is used to separate a non-SIP signalling > >protocol from service logic in a 'Softswitch' > >> network. But then it appears that you would have a > >separate protocol (SIP) for service control to > >> a separate box (App Server). Such separation doesn't > >really apply in the same way to the SIP part > >> of the network and it sounds a lot like the > >Softswitch network is a SIP network at the core. > >> There you find SIP conversant App Servers and around > >them are SIP Proxy Servers, SIP Redirect > >> Servers and SIP User Agents. Some of these UAs may > >in fact represent interfaces to PSTN or even > >> H.323 gateways. Though how do protocols that don't > >use SIP for signalling deliver all the rich > >> new services that SIP enables when, for example, a > >text/html payload gets discarded at the > >> SIP/foo gateway. The point of SIP is surely not to > >create LNP, 800 translation services in an App > >> Server for protocols such as SS7, H.323 etc Yes, you > >could recreate the IN this way but why not > >> start out intending to build something better. You > >achieve this by building Application Servers > >> that empower the simple creation of innovative > >services not Application Servers that merely > >> recreate old services. > > > >I couldn't agree more with this sentiment. > > > >That said, I have a sneaking suspicion that people > >will still want to > >build these older services. Fortunately, most are > >supported by SIP, and > >can easily be built ontop of an applications server as > >well. These > >services (things like LNP and freephone) will work for > >H.323 devices, > >PSTN phones or ISDN phones accessing the SIP network > >through a gateway > >or softswitch. Even better, SIPs capabilities for negotiating > >extensions, content, methods, and so on, will often > >allow an app server > >to know if the accessing device can support a more > >innovative service. > >In the example you give, where the app server returns HTML to a > >softswitch, the app server can know apriori that HTML > >is or isn't > >supported (Accept: text/html in the INVITE). It could > >then do something > >different with the request for non-html access > >devices, like forward it > >to a media server running TTS or something, and read > >out the web page. > > > >-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 Mon Jun 5 11:34: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 LAA04784 for ; Mon, 5 Jun 2000 11:34: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 CD35B4436B; Mon, 5 Jun 2000 11:24:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ns1.comversens.com (ns1.comversens.com [63.64.185.10]) by lists.bell-labs.com (Postfix) with ESMTP id 0C5E544336 for ; Mon, 5 Jun 2000 11:24:07 -0400 (EDT) Received: from mail-bridge.btrd.bostontechnology.com (host.comversens.com [63.64.185.2]) by ns1.comversens.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA26039 for ; Mon, 5 Jun 2000 11:34:26 -0400 (EDT) Received: by mail-bridge.btrd.bostontechnology.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 11:33:48 -0400 Message-ID: <35A7D40B978CD311AF05002048404D3401F2B3E5@wm2.btrd.bostontechnology.com> From: "Oughton, Andre" To: sip@lists.bell-labs.com Subject: [SIP] Overview Text Date: Mon, 5 Jun 2000 11:33:32 -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 I am new to the SIP mailing list. I am looking for a good overview text, one that I might recommend as a reference in a college course on IP based telephony. The text need not be limited SIP but it must describe SIP in the context of general networking. An ideal text would start with fundamental IP concepts and delve into the specifics associated with IP based streaming etc .... Thanks in advance. --------------------------- Andre R. Oughton Principal Engineer Comverse Network Systems Andover MA 01810 http://www.Comversens.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 Jun 5 11: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 LAA05072 for ; Mon, 5 Jun 2000 11: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 74615443A9; Mon, 5 Jun 2000 11:46:13 -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 6267944340 for ; Mon, 5 Jun 2000 11:46:09 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jun 5 11:54:11 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 476C744344; Mon, 5 Jun 2000 11:41:02 -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 F0D7144341 for ; Mon, 5 Jun 2000 11:41:01 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA12892; Mon, 5 Jun 2000 10:40:57 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA12882; Mon, 5 Jun 2000 10:40:55 -0500 Message-ID: <393BCA05.6FBC8DF0@lucent.com> Date: Mon, 05 Jun 2000 10:40:53 -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: "Oughton, Andre" Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Overview Text References: <35A7D40B978CD311AF05002048404D3401F2B3E5@wm2.btrd.bostontechnology.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 "Oughton, Andre" wrote: > > I am new to the SIP mailing list. I am looking for a good > overview text, one that I might recommend as a reference in > a college course on IP based telephony. The text need not > be limited SIP but it must describe SIP in the context of > general networking. An ideal text would start with > fundamental IP concepts and delve into the specifics associated > with IP based streaming etc .... > Thanks in advance. "Internetworking Multimedia" by Jon Crowcroft, Mark Handley, and Ian Wakeman is pretty good. It contains chapters detailing multi- casting, coding, compression, SAP/SDP, conference control and of course, security. It also covers SIP, although the text identifies it as the "Section Initiation Protocol" (most definitely a typo) and in at least one of the call flows I have glanced at, an ACK is sent to a BYE request (this is wrong; the RFC mandates using ACKs for INVITEs only). Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Jun 5 12:34: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 MAA05808 for ; Mon, 5 Jun 2000 12: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 72F4E44340; Mon, 5 Jun 2000 12:24: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 E2AC444336 for ; Mon, 5 Jun 2000 12:24:33 -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 MAA02220; Mon, 5 Jun 2000 12:35:45 -0400 (EDT) Message-ID: <393BD6A3.AD33D2DA@dynamicsoft.com> Date: Mon, 05 Jun 2000 12:34:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: raf Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Information References: <005301bfcedc$b9ab4700$2cf2cdc1@coritel.it> 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 > raf wrote: > > Hi, I need of a clarification about SIP. I don`t know if these > addresses are the right places!!! > I am developing a NAT module properly for SIP. I have two scenarios: > the first with a SIP Client > behind the NAT router (In a private realm), the second with a SIP > Client and a SIP SERVER behind > a NAT router both. My NAT Module is listening on port 5060 UDP and it > works when a UDP packet port > 5060 flows throgh the NAT router. This module works well when it is > crossed by an Invite directly produced by > a SIP Client. Viceversa it doesn`t work when it is crossed by an > Invite produced by a SIP Server. The two Invites are different > in the context: In SDP and in some fileds like VIA!!! The SDP should be the same unless the server has rewritten it for NAT traversal. For info on how to do NAT with SIP, see: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-firewalls-00.txt http://search.ietf.org/internet-drafts/draft-biggs-sip-nat-00.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 Mon Jun 5 12:36: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 MAA05829 for ; Mon, 5 Jun 2000 12:36: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 3CDB14439D; Mon, 5 Jun 2000 12:26:05 -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 6DA3044395 for ; Mon, 5 Jun 2000 12:26: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 MAA02232; Mon, 5 Jun 2000 12:37:08 -0400 (EDT) Message-ID: <393BD6F6.51E77778@dynamicsoft.com> Date: Mon, 05 Jun 2000 12:36:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Oughton, Andre" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Overview Text References: <35A7D40B978CD311AF05002048404D3401F2B3E5@wm2.btrd.bostontechnology.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.cs.columbia.edu/~hgs/sip/papers.html has a listing of books and papers. Also note: IP Telephony Olivier Hersent, David Gurle, Jean-Pierre Petit. Addison-Wesley, 2000. ISBN 0-201-61910-5. which is a book on the subject. -Jonathan R. "Oughton, Andre" wrote: > > I am new to the SIP mailing list. I am looking for a good > overview text, one that I might recommend as a reference in > a college course on IP based telephony. The text need not > be limited SIP but it must describe SIP in the context of > general networking. An ideal text would start with > fundamental IP concepts and delve into the specifics associated > with IP based streaming etc .... > Thanks in advance. > > --------------------------- > Andre R. Oughton > Principal Engineer > Comverse Network Systems > Andover MA > 01810 > http://www.Comversens.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 Mon Jun 5 14: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 OAA07729 for ; Mon, 5 Jun 2000 14: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 7C9114437E; Mon, 5 Jun 2000 13:51:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from fw (unknown [208.0.52.98]) by lists.bell-labs.com (Postfix) with SMTP id AAAA444336 for ; Mon, 5 Jun 2000 13:51:42 -0400 (EDT) Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 14:01:35 -0400 Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A60B3F09@crash.engineering.netspeak.com> From: Linden deCarmo To: "'Dean Willis'" Cc: "'Glenn Morrow'" , sip@lists.bell-labs.com Subject: RE: [SIP] Suspend a session?? Date: Mon, 5 Jun 2000 14:01: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 Ok, you've forced to to evaluate what I'm really requesting. If you throw out my billing/on hook/off hook application, and examine the root functionality I'd like to see added, it boils down to extended transactional roll backs. Basically, for certain methods, it would be convenient if the requesting entity could request the amount of time a CANCEL could roll back the transaction. The recipient of the request would determine if it supported extended roll backs for the method in question. If it supported these extended roll backs, it would send a provisional (18x-type) response to acknowlege the receipt of the request. After the specified time period passed, a final response (2xx) could be issued. Should a CANCEL be received during this intermediate time period, the request would be cancelled. If the UA didn't support extended roll backs, it could immediately return a final response (2xx) so the solution is completely optional and backwards compatible. If you apply this solution to my scenario, here's how it would map out: UA A calls UA B. B goes on hook. UA B issues BYE (with rollback: 30 seconds) to UA A. UA A sends provisional response 18x to UA B. B goes off hook within 30 seconds. UA B sends CANCEL to UA A and session continues. scenario two: UA A calls UA B. B goes on hook. UA B issues BYE (with rollback: 30 seconds) to UA A. UA A sends provisional response 18x to UA B. B remains on hook for 30 seconds. UA A sends final 200 OK response to BYE and session terminates. I don't think this solution is useful (or relevant) for an INVITE, but I believe there are applications for it with OPTIONS, INFO, and BYE. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 > -----Original Message----- > From: Dean Willis [SMTP:dwillis@dynamicsoft.com] > Sent: Sunday, June 04, 2000 2:42 AM > To: Linden deCarmo > Cc: 'Glenn Morrow'; sip@lists.bell-labs.com > Subject: Re: [SIP] Suspend a session?? > > > I suspect I don't like what you're attempting to achieve, but methinks > the friendly UA could always submit an appropriate INFO method which the > "billing proxy" could use to determine an appropriate action. > > AS has been pointed out here, it is that UA that is responsible for > translating user action into appropriate signaling. > > One might also ask WHY and end device would choose to use a "time > billing proxy" rather than routing around said proxy. There are probably > some cases involving proxy-moderated firewalls and QoS sessions, but I > still suspect the fundamental approach is somehow flawed. > > -- > Dean > > Linden deCarmo wrote: > > > > Here's the problem with the UA doing it: > > > > User goes on hook (time 0 ). UA starts timer. > > Timer expires (time 30 seconds). UA realizes session expires so it > issues a > > BYE. > > > > Since the proxy sees the BYE 30 seconds later, thats when it stops > billing. > > I do not believe your solution addresses how the UA signals to the proxy > > that billing should stop at time 0 rather than time 30. > > > > I realize I can do this with a proprietary method or header, but I'd > rather > > not. > > > > Linden deCarmo > > Netspeak Corporation > > 902 Clint Moore Road > > Suite 104 > > Boca Raton, FL 33487 > > > > > -----Original Message----- > > > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] > > > Sent: Thursday, June 01, 2000 11:38 AM > > > To: sip@lists.bell-labs.com > > > Subject: RE: [SIP] Suspend a session?? > > > > > > It seems to me that this should be handled by the UA itself. Once the > UA > > > determines the correct functionilty that the real end-device/user > wishes > > > to achieve, it should signal proxies and far-end stations. For > instance a > > > legacy device may which to indicate flash and collect more digits for > a > > > 3-way call by the user using the hook as you say. > > > > > > This would result in a separate transaction but I believe it doesn't > > > require something like a "suspend" method or indication at the SIP > level. > > > > > > > > > I suggest that the UA itself should handle this with timers, etc.. > based > > > upon the physical device and human interface it is trying to achieve. > > > > > > For the billing issue the UA could simply use a timer started based on > > > physical off-hook stimulus to determine when to actually send a BYE or > > > not. > > > > > > If this doesn't address your concerns please let me know. > > > > > > -----Original Message----- > > > From: Linden deCarmo [SMTP:ldeCarmo@netspeak.com] > > > Sent: Wednesday, May 31, 2000 1:54 PM > > > To: sip@lists.bell-labs.com > > > Subject: [SIP] Suspend a session?? > > > > > > Right now, SIP smoothly handles one party putting another party > on > > > hold via > > > a re-INVITE with modified SDP. However, we have a scenario where the > > > session needs to be suspended (not just placed on hold), and I'm not > sure > > > how this can be done without using proprietary headers. > > > > > > Here are ther details. If party A calls party B , party B > should be > > > able to > > > hang up without immediately terminating the session. If party B picks > up > > > the phone within some prescribed time window, the session continues. > > > However, if they don't pick it up within the time window, the session > > > terminates (via a BYE). > > > > > > We're looking for a mechanism for party B to communicate with > either > > > party A > > > or a proxy server, to inform the distant party that the session has > been > > > suspended, and not just placed on hold. The primary motivator for > this > > > notification is billing. Without notification of suspension, its > > > impossible > > > to determine when to safely stop billing. > > > > > > Thanks. > > > > > > Linden deCarmo > > > Netspeak Corporation > > > 902 Clint Moore Road > > > Suite 104 > > > Boca Raton, FL 33487 > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > Privacy and Confidentiality Notice > The information contained in this transmission is intended for the > above-named > recipient(s) only and contains privileged and confidential information. > If the > reader of this message is not an intended recipient, you are strictly > prohibited > from using, copying, distributing, or taking any action in reliance on > such > information. If you have received this communication in error, please > notify us > immediately. Privacy and Confidentiality Notice The information contained in this transmission is intended for the above-named recipient(s) only and contains privileged and confidential information. If the reader of this message is not an intended recipient, you are strictly prohibited from using, copying, distributing, or taking any action in reliance on such information. If you have received this communication in error, please notify us immediately. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 5 14:53: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 OAA08490 for ; Mon, 5 Jun 2000 14:53: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 D014D4434C; Mon, 5 Jun 2000 14:43:17 -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 55AFE44336 for ; Mon, 5 Jun 2000 14:43:15 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FVP0000134BJO@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 5 Jun 2000 18:52:59 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FVP00N2M34B0R@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 05 Jun 2000 18:52:59 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FVP00H0132J9H@pmismtp03.wcomnet.com> for sip@lists.bell-labs.com; Mon, 05 Jun 2000 18:51:55 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVP00H013267L@pmismtp03.wcomnet.com> for sip@lists.bell-labs.com; Mon, 05 Jun 2000 18:51:55 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FVP008PL323NM@pmismtp03.wcomnet.com> for sip@lists.bell-labs.com; Mon, 05 Jun 2000 18:51:40 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Mon, 05 Jun 2000 18:52:43 +0000 Content-return: allowed Date: Mon, 05 Jun 2000 18:52:39 +0000 From: "McMurry, Kathleen" To: "'sip@lists.bell-labs.com'" Message-id: <75C79E507864D3118AFC00805FEAB7D85B3924@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_jDlYEneD8akt3t9Xj1VDxQ)" Subject: [SIP] Request/Responses from other 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 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. --Boundary_(ID_jDlYEneD8akt3t9Xj1VDxQ) Content-type: text/plain; charset=ISO-8859-1 What is the proper behavior of a Proxy in the following scenarios: Scenario1: OUA-----INVITE----->PS------INVITE----->TUA OUA2-----CANCEL---->PS In other words - the CANCEL comes from a different address than the original INVITE came from. The same question applies to a "retransmitted" INVITE request prior to the final response. Scenario2: OUA---INVITE---->PS-----INVITE---->TUA TUA2--->200--->PS In other words - the final response (or any provisional response) comes from a different address than the one that the INVITE was sent to. I know that AFTER the final response, any request can legitimately come from a different source than the original request, but what is the proper behavior when this situation occurs PRIOR to the final response? Thanks, Kathleen McMurry --Boundary_(ID_jDlYEneD8akt3t9Xj1VDxQ) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Request/Responses from other addresses

What is the proper behavior of a Proxy = in the following scenarios:

Scenario1:

OUA-----INVITE----->PS------INVITE----->TUA
OUA2-----CANCEL---->PS

In other words - the CANCEL comes from = a different address than the original INVITE came from.  The same = question applies to a "retransmitted" INVITE request prior to = the final response.


Scenario2:

OUA---INVITE---->PS-----INVITE---->TUA
TUA2--->200--->PS

In other words - the final response = (or any provisional response) comes from a different address than the = one that the INVITE was sent to.



I know that AFTER the final response, = any request can legitimately come from a different source than the = original request, but what is the proper behavior when this situation = occurs PRIOR to the final response?


Thanks,
Kathleen McMurry


--Boundary_(ID_jDlYEneD8akt3t9Xj1VDxQ)-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 5 14:57: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 OAA08564 for ; Mon, 5 Jun 2000 14:57: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 85926443C1; Mon, 5 Jun 2000 14:47:07 -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 DBC65443C0 for ; Mon, 5 Jun 2000 14:47:04 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id NAA05407; Mon, 5 Jun 2000 13:56:57 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA22863; Mon, 5 Jun 2000 13:56:17 -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 NAA14394; Mon, 5 Jun 2000 13:56:17 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id NAA21994; Mon, 5 Jun 2000 13:56:16 -0500 (CDT) Date: Mon, 5 Jun 2000 13:56:16 -0500 (CDT) Message-Id: <200006051856.NAA21994@b04a45.exu.ericsson.se> To: rfairlie@nuera.com Subject: RE: [SIP] Via discrepancy in latest 2543bis draft. Cc: 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 X-BeenThere: sip@lists.bell-labs.com > > Wait up ... quick back pedal ... now I'm not so sure. As written in Section > 6.45.4 it does suggest that you would use the source port over the Via port > (as the "sent-by" includes the port part) but is this the best thing to do ? > We know this Via scheme won't work for a NAPT (without a SIP proxy sitting > on the firewall as well) so perhaps we should be using the port in the Via. > This at least allows SIP user-agent spawning to function normally across a > NAT. > > Anyway, there is definitely a need for clarification here. > Cheers, > > Robert. > Definitely confusing. Since 6.45.4 references 6.45.2 which describes the receiver-tagged Via:, I would assume that you would use the source IP address, BUT, use the port specified in the sent-by, since this is basically the behaviour specified for proxies that receive a request from a different address than the top-most Via: specifies. sean -- Sean Olson > > _______________________________________________ > 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 Jun 5 15:32: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 PAA09191 for ; Mon, 5 Jun 2000 15:32: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 DFBC1443B9; Mon, 5 Jun 2000 15:22:27 -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 4B09444336 for ; Mon, 5 Jun 2000 15:22:25 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id OAA19535; Mon, 5 Jun 2000 14:32:17 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id OAA09676; Mon, 5 Jun 2000 14:32:17 -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 OAA16104; Mon, 5 Jun 2000 14:32:16 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id OAA22069; Mon, 5 Jun 2000 14:32:16 -0500 (CDT) Date: Mon, 5 Jun 2000 14:32:16 -0500 (CDT) Message-Id: <200006051932.OAA22069@b04a45.exu.ericsson.se> To: sip@lists.bell-labs.com, Kathleen.McMurry@wcom.com Subject: Re: [SIP] Request/Responses from other addresses 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 X-BeenThere: sip@lists.bell-labs.com > What is the proper behavior of a Proxy in the following scenarios: > > Scenario1: > > OUA-----INVITE----->PS------INVITE----->TUA > OUA2-----CANCEL---->PS > > In other words - the CANCEL comes from a different address than the original > INVITE came from. The same question applies to a "retransmitted" INVITE > request prior to the final response. > > > Scenario2: > > OUA---INVITE---->PS-----INVITE---->TUA > TUA2--->200--->PS > > In other words - the final response (or any provisional response) comes from > a different address than the one that the INVITE was sent to. > > I know that AFTER the final response, any request can legitimately come from > a different source than the original request, but what is the proper > behavior when this situation occurs PRIOR to the final response? > > > Thanks, > Kathleen McMurry By different address you mean different source IP address, I'm assuming(?) (A different From: of course would not cause a problem -- the proxy could return a 481) I see no reason to state absolutely that the CANCEL or final response MUST come from the same IP address. There are obvious applications for exactly this scenario. What you want (I assume) is a way to verify/authenticate/authorize the request or the response. If your proxy cares about these things, you can use a variety of schemes to sign the requests/responses, use transport level security, etc. From a SIP point of view, it shouldn't really matter. Consider an analogous situation where the request/response comes from a different source port. Would you outright disallow such a thing? If you are only dealing with very simple UAs, then this might make sense. I have no doubt, however, that you will find some UAs out there that occupy multiple IP address/ports/subnets. This is really, then, a policy decision, and not a protocol issue. sean -- Sean Olson Ericsson Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 5 15:40: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 PAA09269 for ; Mon, 5 Jun 2000 15:40: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 87E47443D3; Mon, 5 Jun 2000 15:30:38 -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 01578443CC for ; Mon, 5 Jun 2000 15:30:33 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Mon, 5 Jun 2000 14:36:58 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 14:39:58 -0500 Message-ID: From: "Glenn Morrow" To: "'Linden deCarmo'" , "'Dean Willis'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Suspend a session?? Date: Mon, 5 Jun 2000 14:39:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCF25.D4D89DAE" 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 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_01BFCF25.D4D89DAE Content-Type: text/plain; charset="ISO-8859-1" From earlier posts it appears that these topics are still a bit too "taboo" for discussion on the list. There are many ways the functionality in question can be accomplished. Perhaps we should leave it at that? > -----Original Message----- > From: Linden deCarmo [SMTP:ldeCarmo@netspeak.com] > Sent: Monday, June 05, 2000 1:02 PM > To: 'Dean Willis' > Cc: Morrow, Glenn [RICH2:C301:EXCH]; sip@lists.bell-labs.com > Subject: RE: [SIP] Suspend a session?? > > Ok, you've forced to to evaluate what I'm really requesting. If you throw > out my billing/on hook/off hook application, and examine the root > functionality I'd like to see added, it boils down to extended > transactional > roll backs. > > Basically, for certain methods, it would be convenient if the requesting > entity could request the amount of time a CANCEL could roll back the > transaction. The recipient of the request would determine if it supported > extended roll backs for the method in question. > > If it supported these extended roll backs, it would send a provisional > (18x-type) response to acknowlege the receipt of the request. After the > specified time period passed, a final response (2xx) could be issued. > Should a CANCEL be received during this intermediate time period, the > request would be cancelled. > > If the UA didn't support extended roll backs, it could immediately return > a > final response (2xx) so the solution is completely optional and backwards > compatible. > > If you apply this solution to my scenario, here's how it would map out: > > UA A calls UA B. > B goes on hook. UA B issues BYE (with rollback: 30 seconds) to UA A. > UA A sends provisional response 18x to UA B. > B goes off hook within 30 seconds. UA B sends CANCEL to UA A and session > continues. > > scenario two: > > UA A calls UA B. > B goes on hook. UA B issues BYE (with rollback: 30 seconds) to UA A. > UA A sends provisional response 18x to UA B. > B remains on hook for 30 seconds. UA A sends final 200 OK response to BYE > and session terminates. > > I don't think this solution is useful (or relevant) for an INVITE, but I > believe there are applications for it with OPTIONS, INFO, and BYE. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > > -----Original Message----- > > From: Dean Willis [SMTP:dwillis@dynamicsoft.com] > > Sent: Sunday, June 04, 2000 2:42 AM > > To: Linden deCarmo > > Cc: 'Glenn Morrow'; sip@lists.bell-labs.com > > Subject: Re: [SIP] Suspend a session?? > > > > > > I suspect I don't like what you're attempting to achieve, but methinks > > the friendly UA could always submit an appropriate INFO method which the > > "billing proxy" could use to determine an appropriate action. > > > > AS has been pointed out here, it is that UA that is responsible for > > translating user action into appropriate signaling. > > > > One might also ask WHY and end device would choose to use a "time > > billing proxy" rather than routing around said proxy. There are probably > > some cases involving proxy-moderated firewalls and QoS sessions, but I > > still suspect the fundamental approach is somehow flawed. > > > > -- > > Dean > > > > Linden deCarmo wrote: > > > > > > Here's the problem with the UA doing it: > > > > > > User goes on hook (time 0 ). UA starts timer. > > > Timer expires (time 30 seconds). UA realizes session expires so it > > issues a > > > BYE. > > > > > > Since the proxy sees the BYE 30 seconds later, thats when it stops > > billing. > > > I do not believe your solution addresses how the UA signals to the > proxy > > > that billing should stop at time 0 rather than time 30. > > > > > > I realize I can do this with a proprietary method or header, but I'd > > rather > > > not. > > > > > > Linden deCarmo > > > Netspeak Corporation > > > 902 Clint Moore Road > > > Suite 104 > > > Boca Raton, FL 33487 > > > > > > > -----Original Message----- > > > > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] > > > > Sent: Thursday, June 01, 2000 11:38 AM > > > > To: sip@lists.bell-labs.com > > > > Subject: RE: [SIP] Suspend a session?? > > > > > > > > It seems to me that this should be handled by the UA itself. Once > the > > UA > > > > determines the correct functionilty that the real end-device/user > > wishes > > > > to achieve, it should signal proxies and far-end stations. For > > instance a > > > > legacy device may which to indicate flash and collect more digits > for > > a > > > > 3-way call by the user using the hook as you say. > > > > > > > > This would result in a separate transaction but I believe it doesn't > > > > require something like a "suspend" method or indication at the SIP > > level. > > > > > > > > > > > > I suggest that the UA itself should handle this with timers, etc.. > > based > > > > upon the physical device and human interface it is trying to > achieve. > > > > > > > > For the billing issue the UA could simply use a timer started based > on > > > > physical off-hook stimulus to determine when to actually send a BYE > or > > > > not. > > > > > > > > If this doesn't address your concerns please let me know. > > > > > > > > -----Original Message----- > > > > From: Linden deCarmo [SMTP:ldeCarmo@netspeak.com] > > > > Sent: Wednesday, May 31, 2000 1:54 PM > > > > To: sip@lists.bell-labs.com > > > > Subject: [SIP] Suspend a session?? > > > > > > > > Right now, SIP smoothly handles one party putting another > party > > on > > > > hold via > > > > a re-INVITE with modified SDP. However, we have a scenario where > the > > > > session needs to be suspended (not just placed on hold), and I'm not > > sure > > > > how this can be done without using proprietary headers. > > > > > > > > Here are ther details. If party A calls party B , party B > > should be > > > > able to > > > > hang up without immediately terminating the session. If party B > picks > > up > > > > the phone within some prescribed time window, the session continues. > > > > However, if they don't pick it up within the time window, the > session > > > > terminates (via a BYE). > > > > > > > > We're looking for a mechanism for party B to communicate with > > either > > > > party A > > > > or a proxy server, to inform the distant party that the session has > > been > > > > suspended, and not just placed on hold. The primary motivator for > > this > > > > notification is billing. Without notification of suspension, its > > > > impossible > > > > to determine when to safely stop billing. > > > > > > > > Thanks. > > > > > > > > Linden deCarmo > > > > Netspeak Corporation > > > > 902 Clint Moore Road > > > > Suite 104 > > > > Boca Raton, FL 33487 > > > > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > Privacy and Confidentiality Notice > > The information contained in this transmission is intended for the > > above-named > > recipient(s) only and contains privileged and confidential information. > > If the > > reader of this message is not an intended recipient, you are strictly > > prohibited > > from using, copying, distributing, or taking any action in reliance on > > such > > information. If you have received this communication in error, please > > notify us > > immediately. > > Privacy and Confidentiality Notice > The information contained in this transmission is intended for the > above-named > recipient(s) only and contains privileged and confidential information. > If the > reader of this message is not an intended recipient, you are strictly > prohibited > from using, copying, distributing, or taking any action in reliance on > such > information. If you have received this communication in error, please > notify us > immediately. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFCF25.D4D89DAE Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Suspend a session??

From earlier posts = it appears that these topics are still a bit too "taboo" for = discussion on the list.  There are many ways the functionality in = question can be accomplished. Perhaps we should leave it at = that?

    -----Original Message-----
    From:   Linden deCarmo = [SMTP:ldeCarmo@netspeak.com]
    Sent:   Monday, June 05, 2000 1:02 PM
    To:     'Dean Willis'
    Cc:     Morrow, Glenn [RICH2:C301:EXCH]; = sip@lists.bell-labs.com
    Subject:       = RE: [SIP] Suspend a session??

    Ok, you've forced to to evaluate what = I'm really requesting.  If you throw
    out my billing/on hook/off hook = application, and examine the root
    functionality I'd like to see added, = it boils down to extended transactional
    roll backs.

    Basically, for certain methods, it = would be convenient if the requesting
    entity could request the amount of = time a CANCEL could roll back the
    transaction.  The recipient of = the request would determine if it supported
    extended roll backs for the method in = question.

    If it supported these extended roll = backs, it would send a provisional
    (18x-type) response to acknowlege the = receipt of the request.  After the
    specified time period passed, a final = response (2xx) could be issued.
    Should a CANCEL be received during = this intermediate time period, the
    request would be cancelled.

    If the UA didn't support extended roll = backs, it could immediately return a
    final response (2xx) so the solution = is completely optional and backwards
    compatible.

    If you apply this solution to my = scenario, here's how it would map out:

    UA A calls UA B.
    B goes on hook. UA B issues BYE (with = rollback: 30 seconds) to UA A.
    UA A sends provisional response 18x = to UA B.
    B goes off hook within 30 = seconds.  UA B sends CANCEL to UA A and session
    continues.

    scenario two:

    UA A calls UA B.
    B goes on hook. UA B issues BYE (with = rollback: 30 seconds) to UA A.
    UA A sends provisional response 18x = to UA B.
    B remains on hook for 30 = seconds.  UA A sends final 200 OK response to BYE
    and session terminates.

    I don't think this solution is useful = (or relevant) for an INVITE, but I
    believe there are applications for it = with OPTIONS, INFO, and BYE.

    Linden deCarmo
    Netspeak Corporation
    902 Clint Moore Road
    Suite 104
    Boca Raton, FL 33487

    > -----Original Message-----
    > From: Dean Willis = [SMTP:dwillis@dynamicsoft.com]
    > Sent: Sunday, June 04, 2000 2:42 = AM
    > To:   Linden = deCarmo
    > Cc:   'Glenn Morrow'; = sip@lists.bell-labs.com
    > = Subject:      Re: [SIP] Suspend a = session??
    >
    >
    > I suspect I don't like what = you're attempting to achieve, but methinks
    > the friendly UA could always = submit an appropriate INFO method which the
    > "billing proxy" could = use to determine an appropriate action.
    >
    > AS has been pointed out here, it = is that UA that is responsible for
    > translating user action into = appropriate signaling.
    >
    > One might also ask WHY and end = device would choose to use a "time
    > billing proxy" rather than = routing around said proxy. There are probably
    > some cases involving = proxy-moderated firewalls and QoS sessions, but I
    > still suspect the fundamental = approach is somehow flawed.
    >
    > --
    > Dean
    >
    > Linden deCarmo wrote:
    > >
    > > Here's the problem with the = UA doing it:
    > >
    > > User goes on hook (time 0 = ).  UA starts timer.
    > > Timer expires (time 30 = seconds). UA realizes session expires so it
    > issues a
    > > BYE.
    > >
    > > Since the proxy sees the = BYE 30 seconds later, thats when it stops
    > billing.
    > > I do not believe your = solution addresses how the UA signals to the proxy
    > > that billing should stop at = time 0 rather than time 30.
    > >
    > > I realize I can do this = with a proprietary method or header, but I'd
    > rather
    > > not.
    > >
    > > Linden deCarmo
    > > Netspeak Corporation
    > > 902 Clint Moore Road
    > > Suite 104
    > > Boca Raton, FL 33487
    > >
    > > > -----Original = Message-----
    > > > From: Glenn Morrow = [SMTP:gmorrow@nortelnetworks.com]
    > > > Sent: Thursday, June = 01, 2000 11:38 AM
    > > > To:   = sip@lists.bell-labs.com
    > > > = Subject:      RE: [SIP] Suspend a = session??
    > > >
    > > > It seems to me that = this should be handled by the UA itself. Once the
    > UA
    > > > determines the correct = functionilty that the real end-device/user
    > wishes
    > > > to achieve, it should = signal proxies and far-end stations. For
    > instance a
    > > > legacy device may = which to indicate flash and collect more digits for
    > a
    > > > 3-way call by the user = using the hook as you say.
    > > >
    > > > This would result in a = separate transaction but I believe it doesn't
    > > > require something like = a  "suspend" method or indication at the SIP
    > level.
    > > >
    > > >
    > > > I suggest that the UA = itself should handle this with timers, etc..
    > based
    > > > upon the physical = device and human interface it is trying to achieve.
    > > >
    > > > For the billing issue = the UA could simply use a timer started based on
    > > > physical off-hook = stimulus to determine when to actually send a BYE or
    > > > not.
    > > >
    > > > If this doesn't = address your concerns please let me know.
    > > >
    > > = >       -----Original = Message-----
    > > > From:   = Linden deCarmo [SMTP:ldeCarmo@netspeak.com]
    > > > Sent:   = Wednesday, May 31, 2000 1:54 PM
    > > > = To:     sip@lists.bell-labs.com
    > > > = Subject:        [SIP] Suspend a = session??
    > > >
    > > = >       Right now, SIP smoothly = handles one party putting another party
    > on
    > > > hold via
    > > > a re-INVITE with = modified SDP.  However, we have a scenario where the
    > > > session needs to be = suspended (not just placed on hold), and I'm not
    > sure
    > > > how this can be done = without using proprietary headers.
    > > >
    > > = >       Here are ther details.  = If party A calls party B , party B
    > should be
    > > > able to
    > > > hang up without = immediately terminating the session.  If party B picks
    > up
    > > > the phone within some = prescribed time window, the session continues.
    > > > However, if they don't = pick it up within the time window, the session
    > > > terminates (via a = BYE).
    > > >
    > > = >       We're looking for a mechanism = for party B to communicate with
    > either
    > > > party A
    > > > or a proxy server, to = inform the distant party that the session has
    > been
    > > > suspended, and not = just placed on hold.  The primary motivator for
    > this
    > > > notification is = billing.  Without notification of suspension, its
    > > > impossible
    > > > to determine when to = safely stop billing.
    > > >
    > > = >       Thanks.
    > > >
    > > = >       Linden deCarmo
    > > > Netspeak = Corporation
    > > > 902 Clint Moore = Road
    > > > Suite 104
    > > > Boca Raton, FL = 33487
    > > >
    > > >
    > > >
    > > = >       = _______________________________________________
    > > > 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
    >
    > Privacy and Confidentiality = Notice
    > The information contained in = this transmission is intended for the
    > above-named
    > recipient(s) only and contains = privileged and confidential information.
    > If the
    > reader of this message is not an = intended recipient, you are strictly
    > prohibited
    > from using, copying, = distributing, or taking any action in reliance on
    > such
    > information. If you have = received this communication in error, please
    > notify us
    > immediately.

    Privacy and Confidentiality Notice =
    The information contained in this = transmission is intended for the above-named
    recipient(s) only and contains = privileged and confidential information.   If the
    reader of this message is not an = intended recipient, you are strictly prohibited
    from using, copying, distributing, or = taking any action in reliance on such
    information. If you have received = this communication in error, please notify us
    immediately.


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

------_=_NextPart_001_01BFCF25.D4D89DAE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 5 17:21: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 RAA10682 for ; Mon, 5 Jun 2000 17:21: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 277AA44346; Mon, 5 Jun 2000 17:11: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 B1F7644336 for ; Mon, 5 Jun 2000 17:11:04 -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 RAA03570; Mon, 5 Jun 2000 17:22:10 -0400 (EDT) Message-ID: <393C19C2.FA3961C@dynamicsoft.com> Date: Mon, 05 Jun 2000 17:21:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Linden deCarmo Cc: "'Dean Willis'" , "'Glenn Morrow'" , sip@lists.bell-labs.com Subject: Re: [SIP] Suspend a session?? References: <6C5713970B1FD411ACBE00AA00DCD9A60B3F09@crash.engineering.netspeak.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 With the more general formulation, I immediately have the question - why? If the application is not for this billing thing, what is this useful for? I don't see why the originating UA could not simply wait the required time and then issue the request. -Jonathan R. Linden deCarmo wrote: > > Ok, you've forced to to evaluate what I'm really requesting. If you throw > out my billing/on hook/off hook application, and examine the root > functionality I'd like to see added, it boils down to extended transactional > roll backs. > > Basically, for certain methods, it would be convenient if the requesting > entity could request the amount of time a CANCEL could roll back the > transaction. The recipient of the request would determine if it supported > extended roll backs for the method in question. > > If it supported these extended roll backs, it would send a provisional > (18x-type) response to acknowlege the receipt of the request. After the > specified time period passed, a final response (2xx) could be issued. > Should a CANCEL be received during this intermediate time period, the > request would be cancelled. > > If the UA didn't support extended roll backs, it could immediately return a > final response (2xx) so the solution is completely optional and backwards > compatible. > > If you apply this solution to my scenario, here's how it would map out: > > UA A calls UA B. > B goes on hook. UA B issues BYE (with rollback: 30 seconds) to UA A. > UA A sends provisional response 18x to UA B. > B goes off hook within 30 seconds. UA B sends CANCEL to UA A and session > continues. > > scenario two: > > UA A calls UA B. > B goes on hook. UA B issues BYE (with rollback: 30 seconds) to UA A. > UA A sends provisional response 18x to UA B. > B remains on hook for 30 seconds. UA A sends final 200 OK response to BYE > and session terminates. > > I don't think this solution is useful (or relevant) for an INVITE, but I > believe there are applications for it with OPTIONS, INFO, and BYE. > -- 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 Jun 5 17:27: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 RAA10754 for ; Mon, 5 Jun 2000 17:27: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 DF5D3443CD; Mon, 5 Jun 2000 17:17: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 54A3F4435B for ; Mon, 5 Jun 2000 17:17:14 -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 RAA03602; Mon, 5 Jun 2000 17:27:17 -0400 (EDT) Message-ID: <393C1AF5.B5E6AF31@dynamicsoft.com> Date: Mon, 05 Jun 2000 17:26:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com, Kathleen.McMurry@wcom.com Subject: Re: [SIP] Request/Responses from other addresses References: <200006051932.OAA22069@b04a45.exu.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 Sean Olson wrote: > > > What is the proper behavior of a Proxy in the following scenarios: > > > > Scenario1: > > > > OUA-----INVITE----->PS------INVITE----->TUA > > OUA2-----CANCEL---->PS > > > > In other words - the CANCEL comes from a different address than the original > > INVITE came from. The same question applies to a "retransmitted" INVITE > > request prior to the final response. > > > > > > Scenario2: > > > > OUA---INVITE---->PS-----INVITE---->TUA > > TUA2--->200--->PS > > > > In other words - the final response (or any provisional response) comes from > > a different address than the one that the INVITE was sent to. > > > > I know that AFTER the final response, any request can legitimately come from > > a different source than the original request, but what is the proper > > behavior when this situation occurs PRIOR to the final response? > > > > > > Thanks, > > Kathleen McMurry > > By different address you mean different source IP address, I'm assuming(?) > (A different From: of course would not cause a problem -- the proxy could return a 481) > > I see no reason to state absolutely that the CANCEL or final response MUST come from > the same IP address. There are obvious applications for exactly this scenario. For security purposes, actually, you really do need to check that the CANCEL came from the same place as the request being cancelled (see the minutes of the security task force on this). CANCELs cannot usefully be authenticated directly, since they may come from proxies. That aside, CANCEL can come from anywhere. As for responses, I'm really not sure. The spec says nothing about this, as we had not considered it. It clearly requires some out-of-band communications between the entity which received the request, and the one which sent the response. I'm not sure what the application of that would be. That aside, there may be problems. For requests sent over TCP, the response is supposed to go over the same connection. Clearly it cannot if the response is generated somewhere else. I suspect some proxies may be upset if the connection to the server is open, and the response comes on a different connection, opened just to send the response. In the case of UDP, this will probably work, but you never know. -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 Jun 5 17:29: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 RAA10778 for ; Mon, 5 Jun 2000 17:29: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 1B9FF443DA; Mon, 5 Jun 2000 17:19: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 0B201443D5 for ; Mon, 5 Jun 2000 17:19:14 -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 RAA03618; Mon, 5 Jun 2000 17:30:13 -0400 (EDT) Message-ID: <393C1BA5.400DC0F@dynamicsoft.com> Date: Mon, 05 Jun 2000 17:29:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: rfairlie@nuera.com, sip@lists.bell-labs.com Subject: Re: [SIP] Via discrepancy in latest 2543bis draft. References: <200006051856.NAA21994@b04a45.exu.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 Sean Olson wrote: > > > > > Wait up ... quick back pedal ... now I'm not so sure. As written in Section > > 6.45.4 it does suggest that you would use the source port over the Via port > > (as the "sent-by" includes the port part) but is this the best thing to do ? > > We know this Via scheme won't work for a NAPT (without a SIP proxy sitting > > on the firewall as well) so perhaps we should be using the port in the Via. > > This at least allows SIP user-agent spawning to function normally across a > > NAT. > > > > Anyway, there is definitely a need for clarification here. > > Cheers, > > > > Robert. > > > > Definitely confusing. Since 6.45.4 references 6.45.2 which describes the receiver-tagged > Via:, I would assume that you would use the source IP address, BUT, use the port > specified in the sent-by, since this is basically the behaviour specified for proxies > that receive a request from a different address than the top-most Via: specifies. Correct. The response is sent to the IP address the request came from, and the port in the Via header. We will clean up to make this consistent. 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 Mon Jun 5 17:35: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 RAA10900 for ; Mon, 5 Jun 2000 17:35: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 7914C44395; Mon, 5 Jun 2000 17:25:32 -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 EFA9F44336 for ; Mon, 5 Jun 2000 17:25:29 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FVP00001AN0X7@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 5 Jun 2000 21:35:24 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FVP00GH2AN0JN@firewall.mcit.com>; Mon, 05 Jun 2000 21:35:24 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FVP00201AL8FJ@pmismtp03.wcomnet.com>; Mon, 05 Jun 2000 21:34:21 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVP00201AKVE3@pmismtp03.wcomnet.com>; Mon, 05 Jun 2000 21:34:20 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FVP000I5AKU4W@pmismtp03.wcomnet.com>; Mon, 05 Jun 2000 21:34:06 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Mon, 05 Jun 2000 21:35:09 +0000 Content-return: allowed Date: Mon, 05 Jun 2000 21:35:06 +0000 From: "McMurry, Kathleen" Subject: RE: [SIP] Request/Responses from other addresses To: "'Jonathan Rosenberg'" , Sean Olson Cc: sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D85B392A@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 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, June 05, 2000 4:26 PM To: Sean Olson Cc: sip@lists.bell-labs.com; McMurry, Kathleen Subject: Re: [SIP] Request/Responses from other addresses Sean Olson wrote: > > > > > What is the proper behavior of a Proxy in the following scenarios: > > > > > > Scenario1: > > > > > > OUA-----INVITE----->PS------INVITE----->TUA > > > OUA2-----CANCEL---->PS > > > > > > In other words - the CANCEL comes from a different address than the original > > > INVITE came from. The same question applies to a "retransmitted" INVITE > > > request prior to the final response. > > > > > > > > > Scenario2: > > > > > > OUA---INVITE---->PS-----INVITE---->TUA > > > TUA2--->200--->PS > > > > > > In other words - the final response (or any provisional response) comes from > > > a different address than the one that the INVITE was sent to. > > > > > > I know that AFTER the final response, any request can legitimately come from > > > a different source than the original request, but what is the proper > > > behavior when this situation occurs PRIOR to the final response? > > > > > > > > > Thanks, > > > Kathleen McMurry > > > > By different address you mean different source IP address, I'm assuming(?) > > (A different From: of course would not cause a problem -- the proxy could return a 481) > > > > I see no reason to state absolutely that the CANCEL or final response MUST come from > > the same IP address. There are obvious applications for exactly this scenario. > > For security purposes, actually, you really do need to check that the > CANCEL came from the same place as the request being cancelled (see the > minutes of the security task force on this). CANCELs cannot usefully be > authenticated directly, since they may come from proxies. That aside, > CANCEL can come from anywhere. > > As for responses, I'm really not sure. The spec says nothing about this, > as we had not considered it. It clearly requires some out-of-band > communications between the entity which received the request, and the > one which sent the response. I'm not sure what the application of that > would be. That aside, there may be problems. For requests sent over TCP, > the response is supposed to go over the same connection. Clearly it > cannot if the response is generated somewhere else. I suspect some > proxies may be upset if the connection to the server is open, and the > response comes on a different connection, opened just to send the > response. In the case of UDP, this will probably work, but you never > know. Wouldn't you have the same security concerns with the response, since it would allow an entity to redirect a call that was not sent to 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 Mon Jun 5 17:59: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 RAA11318 for ; Mon, 5 Jun 2000 17:59: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 4BE284435B; Mon, 5 Jun 2000 17:49:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id B132544336 for ; Mon, 5 Jun 2000 17:49:43 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA25109 for ; Mon, 5 Jun 2000 17:01:35 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id QAA05465 for ; Mon, 5 Jun 2000 16:59:07 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Jun 2000 16:59:06 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790EC@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: "'sip@lists.bell-labs.com'" Date: Mon, 5 Jun 2000 16:59:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] comments on draft-sparks-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 Section 4.3: "A TRANSFER method must not contain a body." I'm wondering about the motivation for this blanket restriction. It seems to me that just like a TRANSFER tells the transferee whom to invite, there are also cases where the transferor would like to indicate some of the parameters of that new call. Using the ATM-enabled SDP being worked in the mmusic group now, for example, the transferor might want to indicate some suggested QoS parameters that the transferee should use for the new call. Or perhaps the transferor (particularly if there has been contact with the target, as in a transfer-with-consultation) wishes to suggest some particular codecs for the new call. At the very least, the transferor might want to indicate whether the transferee should initiate an audio-only call or a multimedia call to the target. Moving away from SDP, one could imagine sending an infamous .jpg file of the target, or perhaps a URL to view while waiting for a transfer to complete. ----- Section 4.5: "If the transferee's agent decides to attempt the transfer, a 200 OK response must be returned by the [sic] if it was able to establish a session with the transferor, otherwise a 603 Decline must be returned." There's a missing word in here, hence the "sic" above. And do you mean "establish a session with the target", not establish a session with the *transferor*? In any case, there are four possible outcomes that I see for a TRANSFER: (1) There's something wrong with the request. I think this is dealt with in that any appropriate 400-600 class response may be returned. (This is specified just before the quote I extracted above.) (2) The transfer is attempted, and succeeds. The section quoted above seems to say that 200 OK should be returned in this case, and I agree. (3) The transfer is attempted, but fails. (4) The transfer is not even attempted. The section quoted above seems to mandate 603 Decline for both cases (3) and (4). I would think that there are cases where the transferor would like to distinguish between the cases. For example, I can try to transfer someone to party A, and if that fails try to transfer them to party B, etc., perhaps even indefinitely. Whereas if the transferor doesn't want to be transferred, there's no point in trying another transfer. In fact, I would think (4) is actually (4a) "this particular transfer will not be attempted" and (4b) "no transfer will be attempted." I'd like to see 603 Decline used only for case (4), and a different "transfer failed" code returned for case (3). And I'd like to see some way to distinguish between cases (4a) and (4b), along the lines of "Busy Here" vs. "Busy Everywhere". Probably 603 Decline should mean Decline All (a la 600 Busy Everywhere), and a new 400-class code would be the simple transfer Decline (a la 486 Busy Here). I thought about the Retry-After header, but it wouldn't be clear whether to retry this transfer, or a different one. ----- Section 4.6: "UA receiving a well-formed TRANSFER request should request approval from the user to proceed. In the absence of that request, or upon receiving approval, the UA must submit an INVITE to the resource ..." I don't think that sending the INVITE is necessarily the correct behavior if the user is not queried. Certainly if the user is queried and replies, the action is obvious. But if the user is not queried, I think there are scenarios where the INVITE should not be done -- in secure environments, with a transfer target outside the security boundary, for example. I think in the absence of a query or response from the user, the behavior should be up to the UA implementer, who will probably make it some sort of configurable option. But I think "MUST" is too strong here for the default behavior. If you do want to mandate some default behavior, I think in the absence of a user query/response or known user configuration, it would be to respond with a Decline All. ----- Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 5 18:10: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 SAA11507 for ; Mon, 5 Jun 2000 18:10: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 56D38443CB; Mon, 5 Jun 2000 18:00: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 BA142443CA for ; Mon, 5 Jun 2000 18:00: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 SAA03808; Mon, 5 Jun 2000 18:11:37 -0400 (EDT) Message-ID: <393C2559.BBFCA0A1@dynamicsoft.com> Date: Mon, 05 Jun 2000 18:10:33 -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: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses References: <75C79E507864D3118AFC00805FEAB7D85B392A@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: > > > > By different address you mean different source IP address, I'm > assuming(?) > > > (A different From: of course would not cause a problem -- the proxy > could return a 481) > > > > > > I see no reason to state absolutely that the CANCEL or final response > MUST come from > > > the same IP address. There are obvious applications for exactly this > scenario. > > > > For security purposes, actually, you really do need to check that the > > CANCEL came from the same place as the request being cancelled (see the > > minutes of the security task force on this). CANCELs cannot usefully be > > authenticated directly, since they may come from proxies. That aside, > > CANCEL can come from anywhere. > > > > As for responses, I'm really not sure. The spec says nothing about this, > > as we had not considered it. It clearly requires some out-of-band > > communications between the entity which received the request, and the > > one which sent the response. I'm not sure what the application of that > > would be. That aside, there may be problems. For requests sent over TCP, > > the response is supposed to go over the same connection. Clearly it > > cannot if the response is generated somewhere else. I suspect some > > proxies may be upset if the connection to the server is open, and the > > response comes on a different connection, opened just to send the > > response. In the case of UDP, this will probably work, but you never > > know. > > Wouldn't you have the same security concerns with the response, since it > would allow an entity to redirect a call that was not sent to it? Yes, actually. Like CANCEL, a redirect response can be generated by a proxy and also by a user agent. So, doing source address checks there is probably 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 Mon Jun 5 23:13: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 XAA15782 for ; Mon, 5 Jun 2000 23:13: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 ECA7D443CE; Mon, 5 Jun 2000 23:03:04 -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 38A97443CC for ; Mon, 5 Jun 2000 23:03:02 -0400 (EDT) Received: by EXCHANGESVR with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 20:13:36 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "McMurry, Kathleen" Cc: Sean Olson , sip@lists.bell-labs.com Subject: RE: [SIP] Request/Responses from other addresses Date: Mon, 5 Jun 2000 20:13:35 -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 > > For security purposes, actually, you really do need to check that the > > CANCEL came from the same place as the request being cancelled (see the > > minutes of the security task force on this). CANCELs cannot usefully be > > authenticated directly, since they may come from proxies. That aside, > > CANCEL can come from anywhere. > > I take it then that this doesn't apply to BYE requests because they can be authenticated directly? Is there a weaker source address check you could apply in the absence of authentication? I can't think of any infallible ones. Requests will not always come from the original source address and the Contact address doesn't necessarily infer that the source of future requests will be from that address... although it would help if we could assume that! So I guess that without authentication, SIP is very vulnerable to someone sniffing packets and then generating their own requests to re-INVITE the call to themselves. Am I missing something? Robert. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, June 06, 2000 6:11 AM To: McMurry, Kathleen Cc: Sean Olson; sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses "McMurry, Kathleen" wrote: > > > > By different address you mean different source IP address, I'm > assuming(?) > > > (A different From: of course would not cause a problem -- the proxy > could return a 481) > > > > > > I see no reason to state absolutely that the CANCEL or final response > MUST come from > > > the same IP address. There are obvious applications for exactly this > scenario. > > > > As for responses, I'm really not sure. The spec says nothing about this, > > as we had not considered it. It clearly requires some out-of-band > > communications between the entity which received the request, and the > > one which sent the response. I'm not sure what the application of that > > would be. That aside, there may be problems. For requests sent over TCP, > > the response is supposed to go over the same connection. Clearly it > > cannot if the response is generated somewhere else. I suspect some > > proxies may be upset if the connection to the server is open, and the > > response comes on a different connection, opened just to send the > > response. In the case of UDP, this will probably work, but you never > > know. > > Wouldn't you have the same security concerns with the response, since it > would allow an entity to redirect a call that was not sent to it? Yes, actually. Like CANCEL, a redirect response can be generated by a proxy and also by a user agent. So, doing source address checks there is probably 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 6 00:20: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 AAA16565 for ; Tue, 6 Jun 2000 00:20: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 ECFA24433F; Tue, 6 Jun 2000 00:10: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 8C56E44336 for ; Tue, 6 Jun 2000 00:10:53 -0400 (EDT) Received: from dynamicsoft.com (1Cust116.tnt1.freehold.nj.da.uu.net [63.17.113.116]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA04133; Tue, 6 Jun 2000 00:21:52 -0400 (EDT) Message-ID: <393C7C25.1CF593D0@dynamicsoft.com> Date: Tue, 06 Jun 2000 00:20:53 -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: "McMurry, Kathleen" , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses 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: > > > > For security purposes, actually, you really do need to check that the > > > CANCEL came from the same place as the request being cancelled (see the > > > minutes of the security task force on this). CANCELs cannot usefully be > > > authenticated directly, since they may come from proxies. That aside, > > > CANCEL can come from anywhere. > > > > I take it then that this doesn't apply to BYE requests because they can be > authenticated directly? Yes. > Is there a weaker source address check you could > apply in the absence of authentication? I can't think of any infallible > ones. THere is no such thing as infallible security anyway. > Requests will not always come from the original source address and the > Contact address doesn't necessarily infer that the source of future requests > will be from that address... although it would help if we could assume that! In the case of mobility, the address definitely won't be the same. > > So I guess that without authentication, SIP is very vulnerable to someone > sniffing packets and then generating their own requests to re-INVITE the > call to themselves. Yes; but thats why we have 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 Tue Jun 6 00: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 AAA16901 for ; Tue, 6 Jun 2000 00: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 9E7064434A; Tue, 6 Jun 2000 00:45:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by lists.bell-labs.com (Postfix) with ESMTP id 2B7BF44336 for ; Tue, 6 Jun 2000 00:44:57 -0400 (EDT) Received: from scesie13.sie.siemens.at (forix-hme0 [10.1.140.2]) by eins.siemens.at with ESMTP id GAA28909 for ; Tue, 6 Jun 2000 06:47:33 +0200 (MET DST) Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id GAA06372 for ; Tue, 6 Jun 2000 06:54:52 +0200 (MET DST) Received: from vies194a.sie.siemens.at(195.1.196.94) by scesie13 via smap (V2.0beta) id xma006304; Tue, 6 Jun 00 06:54:39 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 06:54:38 +0200 Message-ID: From: Postmann Erwin To: sip@lists.bell-labs.com Subject: AW: [SIP] SIP Application Server Date: Tue, 6 Jun 2000 06:54:38 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA16901 I have followed the discussion on the SIP application server with big interest. My understanding of the application server is that it is a more complex SIP proxy, redirect server or user agent which provides applications and services to the users. Is my understanding right? I have the following questions for my clarification: How can I ensure that the application server is always in the route of my SIP requests?, Have to registered at the application server or is it enough to use the route header in my requests (e.g. INVITE)? If I want to use more then one application server (with different services) in parallel how can I instruct the proxy/client to select the appropriate one (e.g. based, called party, the time, day, location, etc.)? Has this selection to be done at the client or could I have some intelligence stored in the network? Best regards Erwin Postmann SIEMENS AG Austria Program and System Engineering Mobile Networks Solutions - Product Marketing Autokaderstrasse 29 A-1210 Vienna Tel: +43.5.1707.21398 Fax: +43.5.1707.51924 GSM: +43.664.1010034 email: erwin.postmann@siemens.at -----Ursprüngliche Nachricht----- Von: Neil Deason [mailto:ndeason@ubiquity.net] Gesendet am: Freitag, 02. Juni 2000 10:20 An: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Betreff: Re: [SIP] SIP Application Server Jonathan Rosenberg wrote: > Neil Deason wrote: > > > > Yes of course a separate SIP network element can talk SIP to a smart proxy/application > > server. But the point I was trying to make is that the application server encapsulates a > > vanilla proxy server, i.e. the proxy functionality as described by rfc2543, plus service > > logic accessed through CPL/SIP-CGI/Servlet API/whatever. My difficulty is in seeing how > > this fits with the ISC application working group premise of separating call signalling from > > service control via a SIP messaging interface. This seems like an unnecessary IN model of > > separation. In the App Server the proxy part does signalling but it is clearly not > > separated from controlling service logic by a SIP messaging interface. > > I think you are over-analyzing the meaning of separation of > call-signaling from service control. In reality, all services are > delivered eventually through signaling, and are based on information > provided by signaling. Thus, service logic is quite connected to call > signaling, and embedding a vanilla proxy in an app server is quite a > good way to access it. I would argue this is quite contrary to the IN > model, in which there is an attempt to use a separate protocol for > service control to a separate box. Note however that these protocols > carry much the same information as the signaling protocols themselves. Agreed. It was not my analysis that SIP should be used to try and separate out service control from call control. However, as was pointed out earlier in this thread this could be achieved if SIP is used to separate a non-SIP signalling protocol from service logic in a 'Softswitch' network. But then it appears that you would have a separate protocol (SIP) for service control to a separate box (App Server). Such separation doesn't really apply in the same way to the SIP part of the network and it sounds a lot like the Softswitch network is a SIP network at the core. There you find SIP conversant App Servers and around them are SIP Proxy Servers, SIP Redirect Servers and SIP User Agents. Some of these UAs may in fact represent interfaces to PSTN or even H.323 gateways. Though how do protocols that don't use SIP for signalling deliver all the rich new services that SIP enables when, for example, a text/html payload gets discarded at the SIP/foo gateway. The point of SIP is surely not to create LNP, 800 translation services in an App Server for protocols such as SS7, H.323 etc Yes, you could recreate the IN this way but why not start out intending to build something better. You achieve this by building Application Servers that empower the simple creation of innovative services not Application Servers that merely recreate old services. Regards, 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 6 01:21: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 BAA18851 for ; Tue, 6 Jun 2000 01:21: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 10C4544373; Tue, 6 Jun 2000 01:10:49 -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 95F9E44345 for ; Tue, 6 Jun 2000 01:10:44 -0400 (EDT) Received: from dynamicsoft.com (1Cust116.tnt1.freehold.nj.da.uu.net [63.17.113.116]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA04231; Tue, 6 Jun 2000 01:22:02 -0400 (EDT) Message-ID: <393C8A3F.1657FE78@dynamicsoft.com> Date: Tue, 06 Jun 2000 01:21:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Postmann Erwin Cc: sip@lists.bell-labs.com Subject: Re: AW: [SIP] SIP Application Server 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 Postmann Erwin wrote: > > I have followed the discussion on the SIP application server with big > interest. My understanding of the application server is that it is a more > complex SIP proxy, redirect server or user agent which provides applications > and services to the users. > Is my understanding right? Yes. > > I have the following questions for my clarification: > > How can I ensure that the application server is always in the route of my > SIP requests?, > Have to registered at the application server or is it enough to use the > route header in my requests (e.g. INVITE)? Excellent question. There is no easy answer. The problem is that "service triggers" can be fairly complex. It is not as simple as checking the request URI of a request, and sending it to an application server if that user has some services enabled. Some services are provisioned for any user (such as administrator services). Some services are triggered based on the From or To field. Some services are triggered based on domain names in the request URI rather than on the complete URI. Even more complicated is the fact that service triggers can be extremely dynamic; a particular service may require installation of triggers for a wide range of different requests. So, how does one do this? One way is to simply route everything to your applications server, and let it decide what to do. Another way is to assume that this information exists in some database, and use a query protocol to fetch it, or use a replication protocol to distribute it. Taking a step back, you can argue that this is just a more complex form of routing (remember I made the statement that the beauty of using SIP for service invocation is that feature selection looks like a routing problem). So, what we are talking about is distribution of very complex routing tables between proxies. So, how does one do route distribution in SIP? Many ways, but a colleague suggested to me once that the closest thing may well be TRIP. One can envision extending TRIP to cover a wider range of information for describing the routes. Now, TRIP isn't ideal, since its really engineered for inter-domain operation, and supporting distribution of multidimensional routing criteria will destroy any hope of aggregation, which TRIP spends a lot of time on. But, we have realized the value of TRIP for intra-domain exchange of routes between a gateway and a TRIP speaker (http://search.ietf.org/internet-drafts/draft-rs-trip-gw-00.txt), and I think much of the arguments about why it makes sense there, may also apply here. I'm not proposing this, but I think its worth further consideration. -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 Jun 6 05: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 FAA00358 for ; Tue, 6 Jun 2000 05:56: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 9875544361; Tue, 6 Jun 2000 05:46:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.idc1.level3.com (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 4CAC744336; Tue, 6 Jun 2000 05:46:41 -0400 (EDT) Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140]) by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id JAA13167; Tue, 6 Jun 2000 09:56:40 GMT Received: from l3londmail01.l3.com (localhost [127.0.0.1]) by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id DAA29038; Tue, 6 Jun 2000 03:56:39 -0600 (MDT) Received: by l3londmail01.eu.l3.com with Internet Mail Service (5.5.2650.10) id ; Tue, 6 Jun 2000 10:53:58 +0100 Message-ID: <6FA15EC018C1D211AA4C0008C70D033006A5B130@l3londmail02.eu.l3.com> From: "Quan, Michael" To: "'sip-request@lists.bell-labs.com'" , "'sip@lists.bell-labs.com'" Date: Tue, 6 Jun 2000 10:55:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] subscribe SIP Michael Quan Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Dear Sir/Madam, Please could put me in your distribution list for the SIP working group. Thanks, Michael Quan International Voice Engineering Level (3) Communications 66 Prescot St London, E1 8HG Tel: +44 (0)20 7864 4444 Direct Line: +44 (0)20 7864 0941 Mobile: +44 (0)788 0506108 Fax: +44 (0)20 7864 4488 Email: michael.quan@level3.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 Jun 6 09: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 JAA00721 for ; Tue, 6 Jun 2000 09:37: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 5938B44370; Tue, 6 Jun 2000 09:26:04 -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 AC62F4436C for ; Tue, 6 Jun 2000 09:26:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue Jun 6 09:34:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 429E844344; Tue, 6 Jun 2000 09:21:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 11DEC44341 for ; Tue, 6 Jun 2000 09:21:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 836D452C4; Tue, 6 Jun 2000 09:21:23 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 99E8952B6 for ; Tue, 6 Jun 2000 09:21:20 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jun 6 09:19:34 EDT 2000 Received: from mail.huawei.com.cn ([202.96.135.132]) by dusty; Mon Jun 5 09:08:47 EDT 2000 Received: from y13638 ([10.105.28.151]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA19787 for ; Mon, 5 Jun 2000 21:09:33 +0800 Message-ID: <001801bfceef$4a096ae0$971c690a@y13638.huawei.com.cn> Reply-To: "yinshaohua" From: "yinshaohua" To: Date: Mon, 5 Jun 2000 21:09:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] About Security Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 problem regarding Security considerations in RFC2543. Now IETF have many working groups in security area which consider the security in lower layer. so is the security considerations in RFC2543 redundant? In other words, if having the security in Transport and Network layer, we do not need the Security consideration of SIP. Am I correct? ShaoHua Yin 2000/6/4 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 6 09:46: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 JAA02071 for ; Tue, 6 Jun 2000 09:46: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 8EF374436C; Tue, 6 Jun 2000 09:35: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 C46A444359 for ; Tue, 6 Jun 2000 09:35: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 JAA16633; Tue, 6 Jun 2000 09:24:14 -0400 (EDT) Message-ID: <393CFB7E.B7A901BF@cs.columbia.edu> Date: Tue, 06 Jun 2000 09:24: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: "McMurry, Kathleen" Cc: "'Jonathan Rosenberg'" , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses References: <75C79E507864D3118AFC00805FEAB7D85B392B@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 While verifying CANCEL source address is somewhat useful, I wouldn't put too much faith in it (or feel too bad about not implementing it). In the realistic cases where somebody can intercept the original INVITE (and, thus, know the To, From, CSeq and Call-ID needed to spoof the CANCEL), the same person can probably also fake the source address. Intercept is a likely possibility in old-style shared-medium (hubbed) LANs, either at the source or destination. A rogue proxy server could obviously also do intercept messages, but there are far easier and less conspicuous ways to prevent a call from happening for such a server. An ISP could intercept INVITEs, but once you are in the "middle" of the network, source address filtering is rather difficult, so I doubt that relying on source addresses in that environment helps much. While CANCELs cannot be verified in the same way that INVITEs can, I don't see why proxies couldn't sign them. At least, that would give you some way to call in the Feds for illegal interference with telecommunications services when all your calls are being cancelled. (I suppose rogue CANCELs offer new ways for ILECs to convince their departing customers that maybe the CLEC wasn't trustworthy to begin with...) Also, if you have a signed CANCEL, you could, if sufficiently paranoid, verify that it comes from a domain in the Via list of the original INVITE. -- 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 Jun 6 10:30: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 KAA07960 for ; Tue, 6 Jun 2000 10:30: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 DA8E544343; Tue, 6 Jun 2000 10:20: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 AD37644336 for ; Tue, 6 Jun 2000 10:20:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jun 6 10:28:23 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A5FEE44344; Tue, 6 Jun 2000 10:15:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7B35B44341 for ; Tue, 6 Jun 2000 10:15:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4613A52C4; Tue, 6 Jun 2000 10:15:26 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5D2BB52B6 for ; Tue, 6 Jun 2000 10:15:21 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jun 6 10:13:42 EDT 2000 Received: from smtprch1.nortel.com ([192.135.215.14]) by dusty; Tue Jun 6 10:13:41 EDT 2000 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Tue, 6 Jun 2000 09:11:53 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 09:11:53 -0500 Message-ID: From: "Glenn Morrow" To: "'yinshaohua'" , sip Subject: RE: [SIP] About Security Date: Tue, 6 Jun 2000 09:11:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCFC1.29CBD448" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_01BFCFC1.29CBD448 Content-Type: text/plain Most applications that were invisaged by the pure end to end security mecanisms did not have chains of proxies, firewalls and NATs as a consideration. Certain applications that can be built using the SIP protocol will require routing intelligence at the application level and a secure mechanism for hop by hop traversal through application entities based upon more complex trust relationships than simply end to end which is the basis for the transport and network level security mechanisms. So these SIP security mechanisms are not redudant. I would like to mention that: You do not have to use them if you do not wish to in your applications. You can use the end to end transport/network security mechanisms with SIP. > -----Original Message----- > From: yinshaohua [SMTP:yin@huawei.com.cn] > Sent: Monday, June 05, 2000 8:10 AM > To: sip > Subject: [SIP] About Security > > Hi: > I have a problem regarding Security considerations in RFC2543. Now > IETF > have many working groups in security area which consider the security in > lower layer. so is the security considerations in RFC2543 redundant? In > other words, if having the security in Transport and Network layer, we do > not need the Security consideration of SIP. Am I correct? > > ShaoHua Yin > > 2000/6/4 > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFCFC1.29CBD448 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [SIP] About Security

Most applications = that were invisaged by the pure end to end security mecanisms did not = have chains of proxies, firewalls and NATs as a consideration. =

Certain applications = that can be built using the SIP protocol will require routing = intelligence at the application level and a secure mechanism for hop by = hop traversal through application entities based upon more complex = trust relationships than simply end to end which is the basis for the = transport and network level security mechanisms.

So these SIP = security mechanisms are not redudant.

I would like to = mention that:

You do not have to = use them if you do not wish to in your applications.
You can use the end = to end transport/network security mechanisms with SIP.



    -----Original Message-----
    From:   yinshaohua [SMTP:yin@huawei.com.cn]
    Sent:   Monday, June 05, 2000 8:10 AM
    To:     sip
    Subject:       = [SIP] About Security

    Hi:
        I have a problem = regarding Security considerations in RFC2543. Now IETF
    have many working groups in = security area which consider the security in
    lower layer.  so is the = security considerations in RFC2543 redundant? In
    other words, if having the security = in Transport and Network layer, we do
    not need the Security consideration = of SIP. Am I correct?

    ShaoHua Yin

    2000/6/4




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

------_=_NextPart_001_01BFCFC1.29CBD448-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 6 10:40: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 KAA08527 for ; Tue, 6 Jun 2000 10:40: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 5174A44388; Tue, 6 Jun 2000 10:30:04 -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 BEAA24437A for ; Tue, 6 Jun 2000 10:30:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jun 6 10:38:52 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8F2BE44345; Tue, 6 Jun 2000 10:25:42 -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 475F244341 for ; Tue, 6 Jun 2000 10:25:42 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA14176; Tue, 6 Jun 2000 09:25:38 -0500 Cc: Postmann Erwin , sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA14129; Tue, 6 Jun 2000 09:25:32 -0500 Message-ID: <393D09D8.E3F99485@lucent.com> Date: Tue, 06 Jun 2000 09:25:28 -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: Jonathan Rosenberg Original-CC: Postmann Erwin , sip@lists.bell-labs.com Subject: Re: AW: [SIP] SIP Application Server References: <393C8A3F.1657FE78@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: > > Postmann Erwin wrote: > > > > I have followed the discussion on the SIP application server with > > big interest. My understanding of the application server is that it > > is a more complex SIP proxy, redirect server or user agent which > > provides applications and services to the users. > > Is my understanding right? > > Yes. I have followed this thread with some interest as well. However, IMHO, we need to delineate an application server from a proxy server clearly. There are functions an application server can do that a proxy MUST not. One case I can think of is that of third party call control where some network entity, based on some application logic, asynchronously creates both legs of a call. Clearly, a proxy MUST not do this since a proxy MUST not create INVITE requests on its own. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Tue Jun 6 11:30: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 LAA10111 for ; Tue, 6 Jun 2000 11:30: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 85B164435E; Tue, 6 Jun 2000 09:00:58 -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 3651544359 for ; Tue, 6 Jun 2000 09:00:56 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FVQ00J01HWL2K@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 6 Jun 2000 13:09:57 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FVQ00G7PHWLN4@firewall.mcit.com>; Tue, 06 Jun 2000 13:09:57 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FVQ00D01HUSYT@pmismtp03.wcomnet.com>; Tue, 06 Jun 2000 13:08:52 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVQ00D01HUMX3@pmismtp03.wcomnet.com>; Tue, 06 Jun 2000 13:08:52 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FVQ009BKHUIEZ@pmismtp03.wcomnet.com>; Tue, 06 Jun 2000 13:08:42 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Tue, 06 Jun 2000 13:09:46 +0000 Content-return: allowed Date: Tue, 06 Jun 2000 13:09:43 +0000 From: "McMurry, Kathleen" Subject: RE: [SIP] Request/Responses from other addresses To: "'Jonathan Rosenberg'" Cc: Sean Olson , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D85B392B@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 So I am assuming that after performing the source address checks, the correct behavior is to ignore the message that came from a bad source? --Kathleen McMurry -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, June 05, 2000 5:11 PM To: McMurry, Kathleen Cc: Sean Olson; sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses "McMurry, Kathleen" wrote: > > > > By different address you mean different source IP address, I'm > assuming(?) > > > (A different From: of course would not cause a problem -- the proxy > could return a 481) > > > > > > I see no reason to state absolutely that the CANCEL or final response > MUST come from > > > the same IP address. There are obvious applications for exactly this > scenario. > > > > For security purposes, actually, you really do need to check that the > > CANCEL came from the same place as the request being cancelled (see the > > minutes of the security task force on this). CANCELs cannot usefully be > > authenticated directly, since they may come from proxies. That aside, > > CANCEL can come from anywhere. > > > > As for responses, I'm really not sure. The spec says nothing about this, > > as we had not considered it. It clearly requires some out-of-band > > communications between the entity which received the request, and the > > one which sent the response. I'm not sure what the application of that > > would be. That aside, there may be problems. For requests sent over TCP, > > the response is supposed to go over the same connection. Clearly it > > cannot if the response is generated somewhere else. I suspect some > > proxies may be upset if the connection to the server is open, and the > > response comes on a different connection, opened just to send the > > response. In the case of UDP, this will probably work, but you never > > know. > > Wouldn't you have the same security concerns with the response, since it > would allow an entity to redirect a call that was not sent to it? Yes, actually. Like CANCEL, a redirect response can be generated by a proxy and also by a user agent. So, doing source address checks there is probably 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 Jun 6 12:00: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 MAA10950 for ; Tue, 6 Jun 2000 12:00: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 40B2544354; Tue, 6 Jun 2000 11:49: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 AF34944336 for ; Tue, 6 Jun 2000 11:49:54 -0400 (EDT) Received: from CINQUECENTO (dwillis1.directlink.net [63.64.250.82]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA05600; Tue, 6 Jun 2000 12:00:47 -0400 (EDT) From: "Robert Sparks" To: "Schroeder, Tim" , Subject: RE: [SIP] comments on draft-sparks-sip-cc-transfer-00.txt Date: Tue, 6 Jun 2000 10:58:58 -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: <4D45BA2A58A7D3119E050008C7E69E290790EC@trimail2.tri.sbc.com> 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 > Section 4.3: "A TRANSFER method must not contain a body." > > I'm wondering about the motivation for this blanket restriction. There was list discussion on that matter near the end of March (look to the archives for my original motivation) and discussion at the Adelaide meeting. The decision reached was to remove the restriction. > ----- > > Section 4.5: "If the transferee's agent decides to attempt the transfer, a > 200 OK response must be returned by the [sic] if it was able to > establish a > session with the transferor, otherwise a 603 Decline must be returned." > > There's a missing word in here, hence the "sic" above. Actually, there was an extra "the" > And do you mean > "establish a session with the target", not establish a session with the > *transferor*? Definitely! > In any case, there are four possible outcomes that I see for a TRANSFER: More on that section later. > > Section 4.6: "UA receiving a well-formed TRANSFER request should request > approval from the user to proceed. In the absence of that > request, or upon > receiving approval, the UA must submit an INVITE to the resource ..." > > I don't think that sending the INVITE is necessarily the correct > behavior if > the user is not queried. Certainly if the user is queried and > replies, the > action is obvious. But if the user is not queried, I think there are > scenarios where the INVITE should not be done -- in secure environments, > with a transfer target outside the security boundary, for > example. I think > in the absence of a query or response from the user, the behavior > should be > up to the UA implementer, who will probably make it some sort of > configurable option. But I think "MUST" is too strong here for > the default > behavior. If you do want to mandate some default behavior, I think in the > absence of a user query/response or known user configuration, it > would be to > respond with a Decline All. I will reword this so that it is obvious that local configuration can affect the behavior. For the last statement - if an implementation doesn't (or can't) query a user, and is by policy not going to accept transfers, why not have it return a Method Not Allowed? Robert Sparks _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 6 14:57: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 OAA17118 for ; Tue, 6 Jun 2000 14:57: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 638FF44351; Tue, 6 Jun 2000 14:47:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sonusdc3.sonusnet.com (mail.sonusnet.com [63.99.71.102]) by lists.bell-labs.com (Postfix) with ESMTP id A1EB244336 for ; Tue, 6 Jun 2000 14:47:13 -0400 (EDT) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 14:57:15 -0400 Message-ID: <9581851D1FB3D21199190090273A7445014A35BA@sonusdc3.sonusnet.com> From: "Farahmand, Fardad" To: vkg@lucent.com, Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: AW: [SIP] SIP Application Server Date: Tue, 6 Jun 2000 14:57: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 Good question. The best example can be found in draft-rosenberg-sip-3pcc-00. The draft proposes a scenario in which a "controller" initiates both legs of a call in a third party call control model. The controller can be an Application Server initiating both legs of a call (either directly as in the 3pcc draft or through the SoftSwitch as in the ISC model). This brings up another question. Jonathan, It seems that the 3pcc draft uses a mechanism which does not require any extensions to rfc 2543. So is the "controller" in this draft a special case of one (or more) of the existing clients and servers? Or is the controller a form of a server that needs to be specifically identified in the rfc? Thanks, Fardad Farahmand ffarahmand@sonusnet.com > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Tuesday, June 06, 2000 10:25 AM > To: Jonathan Rosenberg > Cc: Postmann Erwin; sip@lists.bell-labs.com > Subject: Re: AW: [SIP] SIP Application Server > > > Jonathan Rosenberg wrote: > > > > Postmann Erwin wrote: > > > > > > I have followed the discussion on the SIP application server with > > > big interest. My understanding of the application server > is that it > > > is a more complex SIP proxy, redirect server or user agent which > > > provides applications and services to the users. > > > Is my understanding right? > > > > Yes. > > I have followed this thread with some interest as well. > However, IMHO, > we need to delineate an application server from a proxy > server clearly. > There are functions an application server can do that a proxy > MUST not. > One case I can think of is that of third party call control > where some > network entity, based on some application logic, > asynchronously creates > both legs of a call. Clearly, a proxy MUST not do this since a proxy > MUST not create INVITE requests on its own. > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com > vkg@acm.org > IN Architecture and Internet Software Group > 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 6 16:14: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 QAA18501 for ; Tue, 6 Jun 2000 16:14: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 43F5E44363; Tue, 6 Jun 2000 16:03:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 868EB44336 for ; Tue, 6 Jun 2000 16:03:44 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA4781 for ; Tue, 6 Jun 2000 16:13:58 -0400 From: "Dave Oran" To: "IETF SIP WG" Date: Tue, 6 Jun 2000 16:13:45 -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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [SIP] Porposal for providing additional error information to UACs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 PC-like devices and big-hunking PSTN gateways, there are going to be a gaggle of apppliance-like SIP UACs: phones, cable modems, bricks, and other real "line-side" user devices out there. Some of these have limited flash and essentially no user programmability. It also is pretty important to keep the amount of provisioning and configuration stuff on such devices to a minimum. One area I've been playing around with is the issue of how to report SIP error responses to the user of such a device. The basic philosophy of SIP, of course, is to return the error response, with possibly some ascii text, and let the UAC figure out what to do. Letting the UAC control this is great - just what we want - so I've been considering the options for "what to do". One thing I don't want to do is have some fixed mapping table of error codes to tones and announcmeents in the UA iteself. This is hard to provision (national variants, multiple languages, etc.), takes lots of memory, etc. etc. and while tractable for, say a SIP phone with a display, what about: - black phone attached to a SIP brick, or - a SIP phone with no display, or - a blind user. One idea I find rather appealing is to allow a Contact header on any response (not just redirects) and use that to point the UAC via a URL to some kind of server which can give more feedback about the error. Servers might include an RTSP server, a fancy speech synthesizer with computed content, or just an ftp: url to an audio file. So, for example, you could do: SIP/2.0 480 No Response Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-ID: 12345600@here.com CSeq: 1 INVITE Contact: rtsp://annoucements.here.com/english/you-lose.mp3?UserB@there.com Content-Length: 0 and the SIP UA would then use the URL to get to the rtsp server, which would play the announcement "sorry, but the number you have reached, UserB@there.com, is out of service, if you need assistance, tough luck - you think this is AT&T? (just kidding)". I thought of some alternative mechanisms, but rejected them as follows: a) putting the url in the text area of the response header: not good because we don't want to pre-empt that fallback, and because there might be parsing difficulties in deciding whether to treat the text as a url. b) use a URL pointer body part: how do you indicate that the semantics of this body part is something to contact? The contact just seems more natural for this. c) invent a new header field: then we get into debates whether that other thing belongs to 200/300 responses d) use a new redirect code, something like "387 More Information": this takes the control out of the hands of the UAC, since now the policy for whether to just return the "original" error response or remap it for this particular UAC now has to be made by a proxy, or worse, by the UAS that rejected the call. If people think this is a good idea, we could add this to some existing ongoing SIP WG item, or alternatively I could write a brief I.D. describing this. A whole Internet-draft for something so minimal seems overkill, but whatever works for folks... Thanks to Jonathan and Henning for screening an earlier version of this and providing some initial feedback (don't blame them!). Comment? Bricks? "380 Go to Jail, go directly to jail, do not pass go, do not collect $200"? Dave Oran. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 6 16: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 QAA18842 for ; Tue, 6 Jun 2000 16: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 2CF874436F; Tue, 6 Jun 2000 16:27: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 5ECD444358 for ; Tue, 6 Jun 2000 16:27: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 QAA23644; Tue, 6 Jun 2000 16:37:05 -0400 (EDT) Message-ID: <393D60F1.80CCA219@cs.columbia.edu> Date: Tue, 06 Jun 2000 16:37: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: Dave Oran Cc: IETF SIP WG Subject: Re: [SIP] Porposal for providing additional error information to UACs 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 Tentative wording is in the current (June 5) 2543bis-00 draft: \begin{changebar} \item[4xx, 5xx and 6xx responses:] The \header{Contact} response-header field can be used with a 4xx, 5xx or 6xx response to indicate the location where additional information about the error can be found. \end{changebar} -- 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 Jun 6 16:50: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 QAA18994 for ; Tue, 6 Jun 2000 16:50: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 46E0B44358; Tue, 6 Jun 2000 16:40:01 -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 CCEFF44336 for ; Tue, 6 Jun 2000 16:39:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jun 6 16:49:49 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 621A044344; Tue, 6 Jun 2000 16:36:39 -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 1B24044341 for ; Tue, 6 Jun 2000 16:36:39 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA08458; Tue, 6 Jun 2000 15:36:34 -0500 Cc: IETF SIP WG Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA08449; Tue, 6 Jun 2000 15:36:31 -0500 Message-ID: <393D60CC.AB7E61E4@lucent.com> Date: Tue, 06 Jun 2000 15:36:28 -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 Oran Original-CC: IETF SIP WG Subject: Re: [SIP] Porposal for providing additional error information to UACs 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 Oran wrote: [...] > One idea I find rather appealing is to allow a Contact header on any > response (not just redirects) and use that to point the UAC via a URL > to some kind of server which can give more feedback about the error. > Servers might include an RTSP server, a fancy speech synthesizer with > computed content, or just an ftp: url to an audio file. So, for > example, you could do: > > SIP/2.0 480 No Response > Via: SIP/2.0/UDP here.com:5060 > From: BigGuy > To: LittleGuy > Call-ID: 12345600@here.com > CSeq: 1 INVITE > Contact: > rtsp://annoucements.here.com/english/you-lose.mp3?UserB@there.com > Content-Length: 0 > > and the SIP UA would then use the URL to get to the rtsp server, which > would play the announcement [...] Cool. That is similar to storing AVP in LDAP directories, where the value of the attribute is a generalized URL from where the actual information can be retrieved. Been lucky enough to use such frameworks with great success... - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Tue Jun 6 16:54: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 QAA19028 for ; Tue, 6 Jun 2000 16:54: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 0C8454437B; Tue, 6 Jun 2000 16:44:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 5E85444336 for ; Tue, 6 Jun 2000 16:44:46 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA4E47; Tue, 6 Jun 2000 16:55:00 -0400 From: "Dave Oran" To: "Henning Schulzrinne" Cc: "IETF SIP WG" Subject: RE: [SIP] Proposal for providing additional error information to UACs Date: Tue, 6 Jun 2000 16:54:47 -0400 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.2911.0) In-Reply-To: <393D60F1.80CCA219@cs.columbia.edu> 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 Works for me!!!! > -----Original Message----- > From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]On Behalf Of > Henning Schulzrinne > Sent: Tuesday, June 06, 2000 4:37 PM > To: Dave Oran > Cc: IETF SIP WG > Subject: Re: [SIP] Porposal for providing additional error information > to UACs > > > Tentative wording is in the current (June 5) 2543bis-00 draft: > > \begin{changebar} > \item[4xx, 5xx and 6xx responses:] The \header{Contact} response-header > field can be used with a 4xx, 5xx or 6xx response to indicate the > location where additional information about the error can be found. > \end{changebar} > > -- > 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 Jun 6 17:05: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 RAA19163 for ; Tue, 6 Jun 2000 17:05: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 2020A4436D; Tue, 6 Jun 2000 16:55:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nuplanet.bitscout.com (gnatplanet.bitscout.com [198.137.170.30]) by lists.bell-labs.com (Postfix) with ESMTP id 70DB544336 for ; Tue, 6 Jun 2000 16:55:31 -0400 (EDT) Received: from wrkplanet ([10.173.17.30]) by nuplanet.bitscout.com (2.0 Build 2119 (Berkeley 8.8.4)/8.8.4) with ESMTP id RAA00680; Tue, 06 Jun 2000 17:00:18 -0400 Message-Id: <4.2.0.58.20000606165848.04967af0@10.173.17.1> X-Sender: jsteer@10.173.17.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 06 Jun 2000 17:05:29 -0400 To: "Dave Oran" , "IETF SIP WG" From: Jon Steer Subject: Re: [SIP] Porposal for providing additional error information to UACs 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 04:13 PM 6/6/00 -0400, Dave Oran wrote: Why isn't a redirect to a regular announcement server by the destination the preference here? Isn't there a problem with redirecting a UA device? Wouldn't it be simpler to instead define an announcement server that could use the error message as an address which is more likely in the UA's domain? So in my scenario, UA1 -> calls UA2 gets an error message UA1 then calls Announcement server A using the error message/error number as a destination and gets a media stream returned in the language of choice. This way, the announcement server shows up in the normal SLP/DNS directory service and the UA can use it if it wants to. regards, jon >Besides PC-like devices and big-hunking PSTN gateways, there are going to be >a gaggle of apppliance-like SIP UACs: phones, cable modems, bricks, and >other real "line-side" user devices out there. > >Some of these have limited flash and essentially no user programmability. It >also is pretty important to keep the amount of provisioning and >configuration stuff on such devices to a minimum. > >One area I've been playing around with is the issue of how to report SIP >error responses to the user of such a device. The basic philosophy of SIP, >of course, is to return the error >response, with possibly some ascii text, and let the UAC figure out what to >do. Letting the UAC control this is great - just what we want - so I've been >considering the options for "what to do". > >One thing I don't want to do is have some fixed mapping table of error codes >to tones and announcmeents in the UA iteself. This is hard to provision >(national variants, multiple languages, etc.), takes lots of memory, etc. >etc. and while tractable for, say a SIP phone with a display, what about: > - black phone attached to a SIP brick, or > - a SIP phone with no display, or > - a blind user. > >One idea I find rather appealing is to allow a Contact header on any >response (not just redirects) and use that to point the UAC via a URL to >some kind of server which can give more feedback about the error. Servers >might include an RTSP server, a fancy speech synthesizer with computed >content, or just an ftp: url to an audio file. So, for example, you could >do: > > SIP/2.0 480 No Response > Via: SIP/2.0/UDP here.com:5060 > From: BigGuy > To: LittleGuy > Call-ID: 12345600@here.com > CSeq: 1 INVITE > Contact: >rtsp://annoucements.here.com/english/you-lose.mp3?UserB@there.com > Content-Length: 0 > >and the SIP UA would then use the URL to get to the rtsp server, which would >play the announcement "sorry, but the number you have reached, >UserB@there.com, is out of service, if you need assistance, tough luck - you >think this is AT&T? (just kidding)". > >I thought of some alternative mechanisms, but rejected them as follows: > >a) putting the url in the text area of the response header: not good because >we don't want to pre-empt that fallback, and because there might be parsing >difficulties in deciding whether to treat the text as a url. >b) use a URL pointer body part: how do you indicate that the semantics of >this body part is something to contact? The contact just seems more natural >for this. >c) invent a new header field: then we get into debates whether that other >thing belongs to 200/300 responses >d) use a new redirect code, something like "387 More Information": this >takes the control out of the hands of the UAC, since now the policy for >whether to just return the "original" error response or remap it for this >particular UAC now has to be made by a proxy, or worse, by the UAS that >rejected the call. > >If people think this is a good idea, we could add this to some existing >ongoing SIP WG item, or alternatively I could write a brief I.D. describing >this. A whole Internet-draft for something so minimal seems overkill, but >whatever works for folks... > >Thanks to Jonathan and Henning for screening an earlier version of this and >providing some initial feedback (don't blame them!). > >Comment? Bricks? "380 Go to Jail, go directly to jail, do not pass go, do >not collect $200"? > >Dave Oran. > > > >_______________________________________________ >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 Jun 6 17:11: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 RAA19250 for ; Tue, 6 Jun 2000 17: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 0A04F44383; Tue, 6 Jun 2000 17:01:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lists.bell-labs.com (Postfix) with SMTP id 64DE044392 for ; Tue, 6 Jun 2000 17:01:39 -0400 (EDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jun 2000 14:07:17 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Tue, 6 Jun 2000 14:07:17 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01FF56B0@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Dave Oran'" Cc: IETF SIP WG Subject: RE: [SIP] Porposal for providing additional error information to UACs Date: Tue, 6 Jun 2000 14:07: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 Dave, I understand the intent, but find a few design problems with your solution. First, I would rather not overload the "contact" header with this kind of information. There are error cases in which it is legitimate to use Contact for its intended purpose, e.g. a suggestion of an alternative target for the call. If you want to point to some explanatory text, or voice message, you can always use another header, e.g. "Comment." Then, we have to think a little more about the actual intent of the comment. It seems to me that you want to use SIP in a semi autonomous appliance, that cannot really function well without the help of a big brother in the net. I would rather use MGCP for such apliances, but that is another story. In any case, you are looking at some form of distributed system. So, you could just as well use a non-SIP channel to get the information. For example, get the voice message for error code 107 by looking for the URL: http://my.big.brother.in.the.net/explain/?code=107. If you insist in making that part of SIP, you have to analyze who should insert the "comment" line. Is the comment a direct function of the error code, or does it provide additional information? Is this an end-to-end field, or a field inserted by the last proxy? Is it covered by the authentication checksums? Who decides in which language to put the explanation? Christian Huitema > -----Original Message----- > From: Dave Oran [mailto:oran@cisco.com] > Sent: Tuesday, June 06, 2000 1:14 PM > To: IETF SIP WG > Subject: [SIP] Porposal for providing additional error information to > UACs > > > Besides PC-like devices and big-hunking PSTN gateways, there > are going to be > a gaggle of apppliance-like SIP UACs: phones, cable modems, > bricks, and > other real "line-side" user devices out there. > > Some of these have limited flash and essentially no user > programmability. It > also is pretty important to keep the amount of provisioning and > configuration stuff on such devices to a minimum. > > One area I've been playing around with is the issue of how to > report SIP > error responses to the user of such a device. The basic > philosophy of SIP, > of course, is to return the error > response, with possibly some ascii text, and let the UAC > figure out what to > do. Letting the UAC control this is great - just what we want > - so I've been > considering the options for "what to do". > > One thing I don't want to do is have some fixed mapping table > of error codes > to tones and announcmeents in the UA iteself. This is hard to > provision > (national variants, multiple languages, etc.), takes lots of > memory, etc. > etc. and while tractable for, say a SIP phone with a display, > what about: > - black phone attached to a SIP brick, or > - a SIP phone with no display, or > - a blind user. > > One idea I find rather appealing is to allow a Contact header on any > response (not just redirects) and use that to point the UAC > via a URL to > some kind of server which can give more feedback about the > error. Servers > might include an RTSP server, a fancy speech synthesizer with computed > content, or just an ftp: url to an audio file. So, for > example, you could > do: > > SIP/2.0 480 No Response > Via: SIP/2.0/UDP here.com:5060 > From: BigGuy > To: LittleGuy > Call-ID: 12345600@here.com > CSeq: 1 INVITE > Contact: > rtsp://annoucements.here.com/english/you-lose.mp3?UserB@there.com > Content-Length: 0 > > and the SIP UA would then use the URL to get to the rtsp > server, which would > play the announcement "sorry, but the number you have reached, > UserB@there.com, is out of service, if you need assistance, > tough luck - you > think this is AT&T? (just kidding)". > > I thought of some alternative mechanisms, but rejected them > as follows: > > a) putting the url in the text area of the response header: > not good because > we don't want to pre-empt that fallback, and because there > might be parsing > difficulties in deciding whether to treat the text as a url. > b) use a URL pointer body part: how do you indicate that the > semantics of > this body part is something to contact? The contact just > seems more natural > for this. > c) invent a new header field: then we get into debates > whether that other > thing belongs to 200/300 responses > d) use a new redirect code, something like "387 More > Information": this > takes the control out of the hands of the UAC, since now the > policy for > whether to just return the "original" error response or remap > it for this > particular UAC now has to be made by a proxy, or worse, by > the UAS that > rejected the call. > > If people think this is a good idea, we could add this to > some existing > ongoing SIP WG item, or alternatively I could write a brief > I.D. describing > this. A whole Internet-draft for something so minimal seems > overkill, but > whatever works for folks... > > Thanks to Jonathan and Henning for screening an earlier > version of this and > providing some initial feedback (don't blame them!). > > Comment? Bricks? "380 Go to Jail, go directly to jail, do not > pass go, do > not collect $200"? > > Dave Oran. > > > > _______________________________________________ > 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 Jun 6 17: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 RAA19576 for ; Tue, 6 Jun 2000 17: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 27C3844365; Tue, 6 Jun 2000 17:32:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 631C144352 for ; Tue, 6 Jun 2000 17:32:09 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA554A; Tue, 6 Jun 2000 17:42:24 -0400 From: "Dave Oran" To: "Jon Steer" , "IETF SIP WG" Subject: RE: [SIP] Porposal for providing additional error information to UACs Date: Tue, 6 Jun 2000 17:42:11 -0400 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.2911.0) In-Reply-To: <4.2.0.58.20000606165848.04967af0@10.173.17.1> 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 > -----Original Message----- > From: Jon Steer [mailto:jsteer@tsemantics.com] > Sent: Tuesday, June 06, 2000 5:05 PM > To: Dave Oran; IETF SIP WG > Subject: Re: [SIP] Porposal for providing additional error information > to UACs > > > At 04:13 PM 6/6/00 -0400, Dave Oran wrote: > > Why isn't a redirect to a regular announcement server by > the destination the preference here? > Because that moves the policy for what to do from the UAC to a proxy or UAS. I want the UAC to decide what to do based on what it finds most convenient without other elements in the network trying to second guess it's capabilities or the preferences of the user using it at the moment. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 6 17:46: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 RAA19617 for ; Tue, 6 Jun 2000 17:46: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 4C33344386; Tue, 6 Jun 2000 17:36: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 B2CCA44352 for ; Tue, 6 Jun 2000 17:36:03 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FVR00G015SJ60@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 6 Jun 2000 21:45:55 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FVR00EE05SJGE@firewall.mcit.com>; Tue, 06 Jun 2000 21:45:55 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FVR000015QQ0V@pmismtp03.wcomnet.com>; Tue, 06 Jun 2000 21:44:50 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVR00N015QM50@pmismtp03.wcomnet.com>; Tue, 06 Jun 2000 21:44:50 +0000 (GMT) Received: from C25776A ([166.44.57.150]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVR00LA85Q56T@pmismtp03.wcomnet.com>; Tue, 06 Jun 2000 21:44:33 +0000 (GMT) Date: Tue, 06 Jun 2000 16:45:35 -0500 From: Henry Sinnreich Subject: RE: [SIP] Porposal for providing additional error information to UACs In-reply-to: To: Dave Oran , IETF SIP WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 Oran wrote: > or alternatively I could write a >brief I.D. describing >this. A whole Internet-draft for something so minimal >seems overkill, but >whatever works for folks... The lenght of an I-D says nothing about its value. Go for it! Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dave Oran >Sent: Tuesday, June 06, 2000 3:14 PM >To: IETF SIP WG >Subject: [SIP] Porposal for providing additional error >information to >UACs > > >Besides PC-like devices and big-hunking PSTN gateways, >there are going to be >a gaggle of apppliance-like SIP UACs: phones, cable >modems, bricks, and >other real "line-side" user devices out there. > >Some of these have limited flash and essentially no >user programmability. It >also is pretty important to keep the amount of provisioning and >configuration stuff on such devices to a minimum. > >One area I've been playing around with is the issue of >how to report SIP >error responses to the user of such a device. The >basic philosophy of SIP, >of course, is to return the error >response, with possibly some ascii text, and let the >UAC figure out what to >do. Letting the UAC control this is great - just what >we want - so I've been >considering the options for "what to do". > >One thing I don't want to do is have some fixed >mapping table of error codes >to tones and announcmeents in the UA iteself. This is >hard to provision >(national variants, multiple languages, etc.), takes >lots of memory, etc. >etc. and while tractable for, say a SIP phone with a >display, what about: > - black phone attached to a SIP brick, or > - a SIP phone with no display, or > - a blind user. > >One idea I find rather appealing is to allow a Contact >header on any >response (not just redirects) and use that to point >the UAC via a URL to >some kind of server which can give more feedback about >the error. Servers >might include an RTSP server, a fancy speech >synthesizer with computed >content, or just an ftp: url to an audio file. So, for >example, you could >do: > > SIP/2.0 480 No Response > Via: SIP/2.0/UDP here.com:5060 > From: BigGuy > To: LittleGuy > Call-ID: 12345600@here.com > CSeq: 1 INVITE > Contact: >rtsp://annoucements.here.com/english/you-lose.mp3?UserB >@there.com > Content-Length: 0 > >and the SIP UA would then use the URL to get to the >rtsp server, which would >play the announcement "sorry, but the number you have reached, >UserB@there.com, is out of service, if you need >assistance, tough luck - you >think this is AT&T? (just kidding)". > >I thought of some alternative mechanisms, but rejected >them as follows: > >a) putting the url in the text area of the response >header: not good because >we don't want to pre-empt that fallback, and because >there might be parsing >difficulties in deciding whether to treat the text as a url. >b) use a URL pointer body part: how do you indicate >that the semantics of >this body part is something to contact? The contact >just seems more natural >for this. >c) invent a new header field: then we get into debates >whether that other >thing belongs to 200/300 responses >d) use a new redirect code, something like "387 More >Information": this >takes the control out of the hands of the UAC, since >now the policy for >whether to just return the "original" error response >or remap it for this >particular UAC now has to be made by a proxy, or >worse, by the UAS that >rejected the call. > >If people think this is a good idea, we could add this >to some existing >ongoing SIP WG item, or alternatively I could write a >brief I.D. describing >this. A whole Internet-draft for something so minimal >seems overkill, but >whatever works for folks... > >Thanks to Jonathan and Henning for screening an >earlier version of this and >providing some initial feedback (don't blame them!). > >Comment? Bricks? "380 Go to Jail, go directly to jail, >do not pass go, do >not collect $200"? > >Dave Oran. > > > >_______________________________________________ >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 Jun 6 17:52: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 RAA19725 for ; Tue, 6 Jun 2000 17:52: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 56BEA44393; Tue, 6 Jun 2000 17:42: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 DA9AC44352 for ; Tue, 6 Jun 2000 17:42:19 -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 RAA07057; Tue, 6 Jun 2000 17:53:07 -0400 (EDT) From: "Robert Sparks" To: "Schroeder, Tim" , Subject: RE: [SIP] comments on draft-sparks-sip-cc-transfer-00.txt Date: Tue, 6 Jun 2000 16:51:20 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4D45BA2A58A7D3119E050008C7E69E290790EC@trimail2.tri.sbc.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 > In any case, there are four possible outcomes that I see for a TRANSFER: > > (1) There's something wrong with the request. I think this is > dealt with in > that any appropriate 400-600 class response may be returned. (This is > specified just before the quote I extracted above.) > (2) The transfer is attempted, and succeeds. The section quoted > above seems > to say that 200 OK should be returned in this case, and I agree. > (3) The transfer is attempted, but fails. > (4) The transfer is not even attempted. > > The section quoted above seems to mandate 603 Decline for both > cases (3) and > (4). I would think that there are cases where the transferor > would like to > distinguish between the cases. For example, I can try to transfer someone > to party A, and if that fails try to transfer them to party B, > etc., perhaps > even indefinitely. Whereas if the transferor doesn't want to be > transferred, there's no point in trying another transfer. In > fact, I would > think (4) is actually (4a) "this particular transfer will not be > attempted" > and (4b) "no transfer will be attempted." > > I'd like to see 603 Decline used only for case (4), and a different > "transfer failed" code returned for case (3). And I'd like to > see some way > to distinguish between cases (4a) and (4b), along the lines of "Busy Here" > vs. "Busy Everywhere". Probably 603 Decline should mean Decline All (a la > 600 Busy Everywhere), and a new 400-class code would be the > simple transfer > Decline (a la 486 Busy Here). I thought about the Retry-After header, but > it wouldn't be clear whether to retry this transfer, or a different one. > Addressing 4b) first : if the transferee has instructed his UA to accept no transfers, then the UA could return a 405 Method not Allowed. Can you sketch an example where it would make a difference to the transferor's UA if a 603 response was due to 3) or 4a)? From its perspective, should it care if the response came from the transferee deciding "I don't want to talk to _that_ person" or "I tried, but nobody answered". 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 Jun 6 19:19: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 TAA20513 for ; Tue, 6 Jun 2000 19:19: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 CDFA44438A; Tue, 6 Jun 2000 19:09: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 2354444336 for ; Tue, 6 Jun 2000 19:09: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 TAA07276; Tue, 6 Jun 2000 19:20:43 -0400 (EDT) Message-ID: <393D8711.BB7AAF09@dynamicsoft.com> Date: Tue, 06 Jun 2000 19:19:45 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Farahmand, Fardad" Cc: vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: AW: [SIP] SIP Application Server References: <9581851D1FB3D21199190090273A7445014A35BA@sonusdc3.sonusnet.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 "Farahmand, Fardad" wrote: > > It seems that the 3pcc draft uses a mechanism which does not require any > extensions to rfc 2543. So is the "controller" in this draft a special case > of one (or more) of the existing clients and servers? Or is the controller > a form of a server that needs to be specifically identified in the rfc? The controller is a UAC, actually. It requires no extensions at all. People seem to get caught up in whether a box is a proxy or a redirect or a UA or whatever. These are logical roles. If a box does something which defines it as a proxy, then its a proxy. If it does something which is characteristic of a UA (like initiating its own requests), its a UA. -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 Jun 6 19:31: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 TAA20655 for ; Tue, 6 Jun 2000 19:31: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 D03274437C; Tue, 6 Jun 2000 19:21:28 -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 123C044336 for ; Tue, 6 Jun 2000 19:21:26 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 16:31:29 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE7F3459@sd_exchange.nuera.com> From: "Fox, Mike" To: Robert Sparks Cc: SIP@lists.bell-labs.com Subject: RE: [SIP] comments on draft-sparks-sip-cc-transfer-00.txt Date: Tue, 6 Jun 2000 16:31:28 -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 read the draft, and I am left wondering exactly what aspects (or features) of call control the Transfer method adds which can not be accomplished using existing SIP methods. The draft cites that: "...these changes facilitate recovery of failed transfers and clarify state management in the participating entities" Looking back over the SIP email there are additional points the author and others make in favor of the Transfer method, but I am (as I'm sure others are) unsure if these alone justify implementation of a new method. I believe the draft, discussions, and group thinking would all benefit from a thorough comparison of call control models and features made possible using the Transfer method vs. existing SIP methods (such as BYE Also). Many thanks, 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 Tue Jun 6 19:40: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 TAA20692 for ; Tue, 6 Jun 2000 19:40: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 01BAB4438D; Tue, 6 Jun 2000 19:29: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 2FD5244336 for ; Tue, 6 Jun 2000 19:29:52 -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 TAA07309; Tue, 6 Jun 2000 19:41:06 -0400 (EDT) Message-ID: <393D8BD8.DDEC1A04@dynamicsoft.com> Date: Tue, 06 Jun 2000 19:40:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net, sip , "iptel, list" , megaco@standards.nortelnetworks.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Availability of RTP library source code in C Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, I am pleased to finally announce the availability of source code for RTPlib, and RTP library in C developed jointly by myself, Daniel Rubenstein from U.Mass Amherst, and Henning Schulzrinne and Jonathan Lennox from Columbia University. The library is fairly complete, implementing some of the harder things, such as SSRC collision, mixers, and RTCP timer reconsideration, in a transparent manner. It comes with HTML documentation and example applications. The library is free for non-commercial and research usage. It has been run and tested primarily on Solaris, but has also been used on NT. You can obtain the software at: http://www.bell-labs.com/topic/swdist/ 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 Jun 6 20: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 UAA21093 for ; Tue, 6 Jun 2000 20: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 85F244435C; Tue, 6 Jun 2000 20:16:01 -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 1BBCA44336 for ; Tue, 6 Jun 2000 20:15: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 UAA09701; Tue, 6 Jun 2000 20:26:01 -0400 (EDT) Message-ID: <393D9699.12E49BD6@cs.columbia.edu> Date: Tue, 06 Jun 2000 20:26:01 -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: Lars Berggren , sip@lists.bell-labs.com Subject: Re: [SIP] Record-Route (Was: Contact in OPTIONS) References: <39327206.F1E3AD95@cs.columbia.edu> <393324A7.92C23B65@dynamicsoft.com> <393A75F8.BFCF24D8@cs.columbia.edu> <393B160F.BFC6C444@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: > > Via hiding is not stricly needed; only if you want to be stateless AND > hide the route. The far easier approach is simply strip off the via > list, store it, and insert a fresh Via header with some public address > you are not afraid to show to the world, in order to get the response. > When the response comes, slap back on the old Via list, and off you go. > > I'll also note that Via hiding always worried me because it relied on > the *next hop* to encrypt for you; what if the trust relationship is > such that they might not do this for you? Better off protect yourself > than trust the next hop to do so. Actually, that's pretty similar in either case. One could think of the "public address that you are not afraid to show" as the one doing the Via hiding. The SIP server at the public address would have to be trusted in either case. -- 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 Jun 6 22:01: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 WAA22604 for ; Tue, 6 Jun 2000 22:01: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 C159C44382; Tue, 6 Jun 2000 21:50:53 -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 DD6D644336 for ; Tue, 6 Jun 2000 21:50:50 -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 TAA03886; Tue, 6 Jun 2000 19:00:54 -0700 (PDT) Received: from 8x8.com ([207.82.37.120]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id TAA14962; Tue, 6 Jun 2000 19:00:53 -0700 (PDT) Message-ID: <393DAC1A.9E4692F9@8x8.com> Date: Tue, 06 Jun 2000 18:57:46 -0700 From: Marc Petit-Huguenin Organization: Netergy Networks - Advanced Telephony Solutions X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Farahmand, Fardad" , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: AW: [SIP] SIP Application Server References: <9581851D1FB3D21199190090273A7445014A35BA@sonusdc3.sonusnet.com> <393D8711.BB7AAF09@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: > > "Farahmand, Fardad" wrote: > > > > It seems that the 3pcc draft uses a mechanism which does not require any > > extensions to rfc 2543. So is the "controller" in this draft a special case > > of one (or more) of the existing clients and servers? Or is the controller > > a form of a server that needs to be specifically identified in the rfc? > > The controller is a UAC, actually. It requires no extensions at all. > > People seem to get caught up in whether a box is a proxy or a redirect > or a UA or whatever. These are logical roles. If a box does something > which defines it as a proxy, then its a proxy. If it does something > which is characteristic of a UA (like initiating its own requests), its > a UA. > > -Jonathan R. > It seems that I am not the only one that have to explain that a SIP proxy is not necessary a box to add on the network but some simple rules that can be added to an implementation to gain this logical role. Perhaps it will be a good thing to add some explanations about this in the SIP draft? Regards, -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@8x8.com "Everything I love is either immoral, illegal or makes you fat" _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 7 00: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 AAA24968 for ; Wed, 7 Jun 2000 00:49: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 0D3264434D; Wed, 7 Jun 2000 00:38:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by lists.bell-labs.com (Postfix) with ESMTP id 2CC9244336 for ; Wed, 7 Jun 2000 00:38:53 -0400 (EDT) Received: from adsl-151-203-17-31.bellatlantic.net (adsl-151-203-17-31.bellatlantic.net [151.203.17.31]) by valiant.cnchost.com id AAA27932; Wed, 7 Jun 2000 00:48:56 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Date: Wed, 7 Jun 2000 00:55:19 -0400 (EDT) From: Scott Petrack X-Sender: scott.petrack@localhost To: Dave Oran Cc: IETF SIP WG Subject: Re: [SIP] Porposal for providing additional error information to UACs 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 Sorry that I've not been following this too closely, so apologies if the following makes no sense or has already been rejected: but this is really what I wanted a Warning: header to do. I agree with you that the extra indirection can be very useful, but if all you want is some minimal extra information, then a single line of text inserted by the last SIP proxy before the SIP appliance can be very useful. Remember, the text in this Warning: header can be tagged for what language it's in, etc, so that the appliance can be configured to show on the screen only messages in swahili, whatever. If you are going to put a URL to allow the appliance to retrieve the error, I suggest a new header, rather than the Contact: header. Something like Warning-URL: or Error-URL: or even just Display-URL: (the appliance doesn't really need to know if the stuff to be retrieved and displayed is a warning or some extra info. The same mechanism could be used for "extra lookups" sort of as if there were an end-to-end calling-party identification service). Scott On Tue, 6 Jun 2000, Dave Oran wrote: > Besides PC-like devices and big-hunking PSTN gateways, there are going to be > a gaggle of apppliance-like SIP UACs: phones, cable modems, bricks, and > other real "line-side" user devices out there. > > Some of these have limited flash and essentially no user programmability. It > also is pretty important to keep the amount of provisioning and > configuration stuff on such devices to a minimum. > > One area I've been playing around with is the issue of how to report SIP > error responses to the user of such a device. The basic philosophy of SIP, > of course, is to return the error > response, with possibly some ascii text, and let the UAC figure out what to > do. Letting the UAC control this is great - just what we want - so I've been > considering the options for "what to do". > > One thing I don't want to do is have some fixed mapping table of error codes > to tones and announcmeents in the UA iteself. This is hard to provision > (national variants, multiple languages, etc.), takes lots of memory, etc. > etc. and while tractable for, say a SIP phone with a display, what about: > - black phone attached to a SIP brick, or > - a SIP phone with no display, or > - a blind user. > > One idea I find rather appealing is to allow a Contact header on any > response (not just redirects) and use that to point the UAC via a URL to > some kind of server which can give more feedback about the error. Servers > might include an RTSP server, a fancy speech synthesizer with computed > content, or just an ftp: url to an audio file. So, for example, you could > do: > > SIP/2.0 480 No Response > Via: SIP/2.0/UDP here.com:5060 > From: BigGuy > To: LittleGuy > Call-ID: 12345600@here.com > CSeq: 1 INVITE > Contact: > rtsp://annoucements.here.com/english/you-lose.mp3?UserB@there.com > Content-Length: 0 > > and the SIP UA would then use the URL to get to the rtsp server, which would > play the announcement "sorry, but the number you have reached, > UserB@there.com, is out of service, if you need assistance, tough luck - you > think this is AT&T? (just kidding)". > > I thought of some alternative mechanisms, but rejected them as follows: > > a) putting the url in the text area of the response header: not good because > we don't want to pre-empt that fallback, and because there might be parsing > difficulties in deciding whether to treat the text as a url. > b) use a URL pointer body part: how do you indicate that the semantics of > this body part is something to contact? The contact just seems more natural > for this. > c) invent a new header field: then we get into debates whether that other > thing belongs to 200/300 responses > d) use a new redirect code, something like "387 More Information": this > takes the control out of the hands of the UAC, since now the policy for > whether to just return the "original" error response or remap it for this > particular UAC now has to be made by a proxy, or worse, by the UAS that > rejected the call. > > If people think this is a good idea, we could add this to some existing > ongoing SIP WG item, or alternatively I could write a brief I.D. describing > this. A whole Internet-draft for something so minimal seems overkill, but > whatever works for folks... > > Thanks to Jonathan and Henning for screening an earlier version of this and > providing some initial feedback (don't blame them!). > > Comment? Bricks? "380 Go to Jail, go directly to jail, do not pass go, do > not collect $200"? > > Dave Oran. > > > > _______________________________________________ > 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 Jun 7 01:40: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 BAA29701 for ; Wed, 7 Jun 2000 01:40: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 5E5FF44342; Wed, 7 Jun 2000 01:30:43 -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 BFA0644336 for ; Wed, 7 Jun 2000 01:30:40 -0400 (EDT) Received: from dynamicsoft.com (1Cust222.tnt2.freehold.nj.da.uu.net [63.17.114.222]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA07654; Wed, 7 Jun 2000 01:42:06 -0400 (EDT) Message-ID: <393DE076.7B78085B@dynamicsoft.com> Date: Wed, 07 Jun 2000 01:41:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Petrack Cc: Dave Oran , IETF SIP WG Subject: Re: [SIP] Porposal for providing additional error information toUACs 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 Scott Petrack wrote: > > If you are going to put a URL to allow the appliance to retrieve the > error, I suggest a new header, rather than the Contact: header. Something > like Warning-URL: or Error-URL: > or even just Display-URL: (the appliance doesn't really need to know if > the stuff to be retrieved and displayed is a warning or some extra info. > The same mechanism could be used for "extra lookups" sort of as if there > were an end-to-end calling-party identification service). Whether to use Contact or a new header depends a lot on how you want to define the precise semantics of the header. If you use the loosest definition, which is "go here", then Contact will suffice. In fact, using Contact has the advantage of being able to also use the caller preferences capabilities. The UA can, in the INVITE, indicate that it only knows about sip URL schemes. This way, your redirecting device would not try to send the UA to an rtsp URL, rather it might redirect the UA to an app server which contacts the RTSP server and streams the content to the UA. However, if your definition of Contact is "try this address to reach the desired party", probably Contact is not the right thing. As Dave has pointed out, proxies can recurse on 3xx and attempt to reach the addresses in a Contact header because the meaning is precisely "try this address to reach the desired party", and thus its fine for the proxy to try that address. But, Dave doesn't want proxies to go to these addresses - they should only be used by the UA upon receipt of the reject response. So, I'm a bit on the fence, but probably inclined to define a new header in order to avoid further overload of exactly what Contact means. -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 Jun 7 01:55: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 BAA00525 for ; Wed, 7 Jun 2000 01:55: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 4AC4A4438B; Wed, 7 Jun 2000 01:44: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 81D2144336 for ; Wed, 7 Jun 2000 01:44:42 -0400 (EDT) Received: from dynamicsoft.com (1Cust222.tnt2.freehold.nj.da.uu.net [63.17.114.222]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA07663; Wed, 7 Jun 2000 01:56:00 -0400 (EDT) Message-ID: <393DE3B8.2C65762F@dynamicsoft.com> Date: Wed, 07 Jun 2000 01:55:04 -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: "McMurry, Kathleen" , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses References: <75C79E507864D3118AFC00805FEAB7D85B392B@ripexch001.mcit.com> <393CFB7E.B7A901BF@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: > > While CANCELs cannot be verified in the same way that INVITEs can, I > don't see why proxies couldn't sign them. At least, that would give you > some way to call in the Feds for illegal interference with > telecommunications services when all your calls are being cancelled. Right; cancel signatures wouldn't give you any online protection since you can't easily verify that the entity in the signature is, in fact, the proxy which sent you the original request. > Also, if you have a signed CANCEL, you could, if sufficiently > paranoid, verify that it comes from a domain in the Via list of the > original INVITE. This gets confusing if IP addresses are used in the Via header instead.... -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 Jun 7 07:13: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 HAA08955 for ; Wed, 7 Jun 2000 07:13: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 AB5114437F; Wed, 7 Jun 2000 07:03:02 -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 6E77844336 for ; Wed, 7 Jun 2000 07:02:59 -0400 (EDT) Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id OAA16707 for ; Wed, 7 Jun 2000 14:13:02 +0300 (EETDST) From: petri.koskelainen@nokia.com Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id OAA18807 for ; Wed, 7 Jun 2000 14:12:59 +0300 (EETDST) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Wed, 7 Jun 2000 14:07:48 +0300 Message-ID: <25B79E9476BAD211811B0008C7894CDC02F7936C@treis04nok> To: sip@lists.bell-labs.com Date: Wed, 7 Jun 2000 14:07:12 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Proxy-Supported header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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, It seems that currently there is no mechanism to inform other parties (e.g. other proxies) about the supported proxy capabilities. This is needed especially in REGISTER messages but useful also in INVITEs as well. Currently there exists (proposed) Supported header in SIP, but I suppose it is meant for terminal capabilities only. It is impossible to advertize both terminal and proxy capabilities at the same time in one INVITE/REGISTER message. Therefore, I'd like to propose "Proxy-Supported" header to be included into RFC2543bis draft. The syntax is identical to Supported header. Comments? -- Petri Koskelainen Nokia Research Center _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 7 08:15: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 IAA09573 for ; Wed, 7 Jun 2000 08:15: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 8AD97443A3; Wed, 7 Jun 2000 08:05:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.gte.com (unknown [132.197.8.26]) by lists.bell-labs.com (Postfix) with ESMTP id A9B3744336 for ; Wed, 7 Jun 2000 08:05:00 -0400 (EDT) Received: from sigmail.gte.com (sigmail.gte.com [132.197.120.75]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id IAA01261; Wed, 7 Jun 2000 08:14:43 -0400 (EDT) Received: by sigmail.gte.com with Internet Mail Service (5.5.2232.9) id ; Wed, 7 Jun 2000 08:13:59 -0400 Message-ID: From: "Gardell, Steve" To: "'Jonathan Rosenberg'" , Postmann Erwin Cc: sip@lists.bell-labs.com Subject: RE: AW: [SIP] SIP Application Server Date: Wed, 7 Jun 2000 08:13:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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 An alternative model is that all proxy/redirect servers in a network are "application" servers in the sense that they have an application programming interface. Some of these, say stage 1, application servers are specialized for providing "no application needed" services and for routing to the application servers that house applications. The stage 1 & stage 2 "applications" might then access a common (possibly dynamic) data store via mechanisms outside the scope of IETF protocol discussions. This works if the stage 1 & 2 servers are operated by the same service provider (and provided by the same vendor?). Probably simpler and more efficient than involving another protocol in those common cases, but is it a generally enough solution? Steven Gardell GTE Laboratories Voice: 781-466-2681, Fax: 781-466-3375 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, June 06, 2000 1:21 AM > To: Postmann Erwin > Cc: sip@lists.bell-labs.com > Subject: Re: AW: [SIP] SIP Application Server > > > > > Postmann Erwin wrote: > > > > I have followed the discussion on the SIP application > server with big > > interest. My understanding of the application server is > that it is a more > > complex SIP proxy, redirect server or user agent which > provides applications > > and services to the users. > > Is my understanding right? > > Yes. > > > > > I have the following questions for my clarification: > > > > How can I ensure that the application server is always in > the route of my > > SIP requests?, > > Have to registered at the application server or is it > enough to use the > > route header in my requests (e.g. INVITE)? > > Excellent question. > > There is no easy answer. The problem is that "service triggers" can be > fairly complex. It is not as simple as checking the request URI of a > request, and sending it to an application server if that user has some > services enabled. Some services are provisioned for any user (such as > administrator services). Some services are triggered based on the From > or To field. Some services are triggered based on domain names in the > request URI rather than on the complete URI. Even more complicated is > the fact that service triggers can be extremely dynamic; a particular > service may require installation of triggers for a wide range of > different requests. > > So, how does one do this? One way is to simply route > everything to your > applications server, and let it decide what to do. Another way is to > assume that this information exists in some database, and use a query > protocol to fetch it, or use a replication protocol to distribute it. > Taking a step back, you can argue that this is just a more > complex form > of routing (remember I made the statement that the beauty of using SIP > for service invocation is that feature selection looks like a routing > problem). So, what we are talking about is distribution of > very complex > routing tables between proxies. So, how does one do route distribution > in SIP? Many ways, but a colleague suggested to me once that > the closest > thing may well be TRIP. One can envision extending TRIP to > cover a wider > range of information for describing the routes. Now, TRIP isn't ideal, > since its really engineered for inter-domain operation, and supporting > distribution of multidimensional routing criteria will > destroy any hope > of aggregation, which TRIP spends a lot of time on. But, we have > realized the value of TRIP for intra-domain exchange of > routes between a > gateway and a TRIP speaker > (http://search.ietf.org/internet-drafts/draft-rs-trip-gw-00.tx t), and I think much of the arguments about why it makes sense there, may also apply here. I'm not proposing this, but I think its worth further consideration. -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 Wed Jun 7 08:26: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 IAA09642 for ; Wed, 7 Jun 2000 08:26: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 09770443A1; Wed, 7 Jun 2000 08:16:27 -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 480FD44336 for ; Wed, 7 Jun 2000 08:16: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 IAA21605; Wed, 7 Jun 2000 08:26:31 -0400 (EDT) Message-ID: <393E3F77.AD4D3DF4@cs.columbia.edu> Date: Wed, 07 Jun 2000 08:26:31 -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: Marc Petit-Huguenin Cc: sip@lists.bell-labs.com Subject: Re: AW: [SIP] SIP Application Server References: <9581851D1FB3D21199190090273A7445014A35BA@sonusdc3.sonusnet.com> <393D8711.BB7AAF09@dynamicsoft.com> <393DAC1A.9E4692F9@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 Marc Petit-Huguenin wrote: > > Jonathan Rosenberg wrote: > > > > "Farahmand, Fardad" wrote: > > > > > > It seems that the 3pcc draft uses a mechanism which does not require any > > > extensions to rfc 2543. So is the "controller" in this draft a special case > > > of one (or more) of the existing clients and servers? Or is the controller > > > a form of a server that needs to be specifically identified in the rfc? > > > > The controller is a UAC, actually. It requires no extensions at all. > > > > People seem to get caught up in whether a box is a proxy or a redirect > > or a UA or whatever. These are logical roles. If a box does something > > which defines it as a proxy, then its a proxy. If it does something > > which is characteristic of a UA (like initiating its own requests), its > > a UA. > > > > -Jonathan R. > > > > It seems that I am not the only one that have to explain that a SIP > proxy is not necessary a box to add on the network but some simple rules > that can be added to an implementation to gain this logical role. > Perhaps it will be a good thing to add some explanations about this in > the SIP draft? If you look at the June 5th edition of the 2543bis draft, you'll see that the definition now includes wording about per-request behavior. This is also explained in the SIP FAQ. -- 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 Jun 7 08:32: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 IAA09745 for ; Wed, 7 Jun 2000 08:32: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 470E7443CA; Wed, 7 Jun 2000 08:22: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 BCD2F443C9 for ; Wed, 7 Jun 2000 08:22:36 -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 IAA22044; Wed, 7 Jun 2000 08:32:37 -0400 (EDT) Message-ID: <393E40E5.FD445C0B@cs.columbia.edu> Date: Wed, 07 Jun 2000 08:32:37 -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: "McMurry, Kathleen" , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses References: <75C79E507864D3118AFC00805FEAB7D85B392B@ripexch001.mcit.com> <393CFB7E.B7A901BF@cs.columbia.edu> <393DE3B8.2C65762F@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: > > Henning Schulzrinne wrote: > > > > While CANCELs cannot be verified in the same way that INVITEs can, I > > don't see why proxies couldn't sign them. At least, that would give you > > some way to call in the Feds for illegal interference with > > telecommunications services when all your calls are being cancelled. > > Right; cancel signatures wouldn't give you any online protection since > you can't easily verify that the entity in the signature is, in fact, > the proxy which sent you the original request. > > > Also, if you have a signed CANCEL, you could, if sufficiently > > paranoid, verify that it comes from a domain in the Via list of the > > original INVITE. > > This gets confusing if IP addresses are used in the Via header > instead.... > But probably still manageable, with somewhat more work (you'd have to translate the domain of the signer to see if it matches the IP address). Isn't perfect, but given that the attack requires a fair amount of sophistication to begin with, I suspect that this will be an issue only in very limited (high-assurance) situations. A paranoid implementation could simply say "acme.com (signed) wants to cancel your call from aol.com". Unless you (or the original destination) are in either the acme or aol domain, it's very likely that this is a fake, regardless of the precise IP address. -- 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 Jun 7 08:48: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 IAA09819 for ; Wed, 7 Jun 2000 08:48: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 80AB3443C9; Wed, 7 Jun 2000 08:35:43 -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 E94B844391 for ; Wed, 7 Jun 2000 08:35: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 IAA22889; Wed, 7 Jun 2000 08:45:45 -0400 (EDT) Message-ID: <393E43F9.199ED37@cs.columbia.edu> Date: Wed, 07 Jun 2000 08:45:45 -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, Juha Heinanen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SRV records Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 you have a SIP SRV record, please let me know so that I can update http://www.cs.columbia.edu/~hgs/sip/assignments.html. Note in particular the paragraph about the transition from sip.udp.foo.com to _sip._udp.foo.com. (There is no harm in maintaining both "old" and "new" RR for now.) It is quite useful to have these for testing purposes. -- 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 Jun 7 09:01: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 JAA09968 for ; Wed, 7 Jun 2000 09:01: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 07B58443E0; Wed, 7 Jun 2000 08:49:50 -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 927C9443A6 for ; Wed, 7 Jun 2000 08:49:45 -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 IAA23775; Wed, 7 Jun 2000 08:59:33 -0400 (EDT) Message-ID: <393E4735.3C173C3A@cs.columbia.edu> Date: Wed, 07 Jun 2000 08:59:33 -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: Scott Petrack , Dave Oran , IETF SIP WG Subject: Re: [SIP] Porposal for providing additional error information toUACs References: <393DE076.7B78085B@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: > > Scott Petrack wrote: > > > > If you are going to put a URL to allow the appliance to retrieve the > > error, I suggest a new header, rather than the Contact: header. Something > > like Warning-URL: or Error-URL: > > or even just Display-URL: (the appliance doesn't really need to know if > > the stuff to be retrieved and displayed is a warning or some extra info. > > The same mechanism could be used for "extra lookups" sort of as if there > > were an end-to-end calling-party identification service). > > Whether to use Contact or a new header depends a lot on how you want to > define the precise semantics of the header. If you use the loosest > definition, which is "go here", then Contact will suffice. In fact, > using Contact has the advantage of being able to also use the caller > preferences capabilities. The UA can, in the INVITE, indicate that it > only knows about sip URL schemes. This way, your redirecting device > would not try to send the UA to an rtsp URL, rather it might redirect > the UA to an app server which contacts the RTSP server and streams the > content to the UA. > > However, if your definition of Contact is "try this address to reach the > desired party", probably Contact is not the right thing. As Dave has > pointed out, proxies can recurse on 3xx and attempt to reach the > addresses in a Contact header because the meaning is precisely "try this > address to reach the desired party", and thus its fine for the proxy to > try that address. But, Dave doesn't want proxies to go to these > addresses - they should only be used by the UA upon receipt of the > reject response. I'm not sure this is different from "this address is only to be used in case the original address isn't reachable" (3xx). > > So, I'm a bit on the fence, but probably inclined to define a new header > in order to avoid further overload of exactly what Contact means. > Since there is no ambiguity in the action to be taken, I'm not in favor of defining a new header. Defining a new header then means worrying about whether *it* has meaning for 3xx or 2xx responses. Thus, in terms of economy of definition, this one-paragraph version seems to be the lowest-cost way of achieving additional error explanation capability. Any new header also increases the chances for misunderstandings, with various combinations of the new and Contact header. -- 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 Jun 7 09:46: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 JAA10446 for ; Wed, 7 Jun 2000 09:46: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 D5A3D443BE; Wed, 7 Jun 2000 09:35:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 1CC9944336 for ; Wed, 7 Jun 2000 09:35:41 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA230C for ; Wed, 7 Jun 2000 09:45:59 -0400 From: "Dave Oran" To: "IETF SIP WG" Subject: RE: [SIP] Proposal for providing additional error information to UACs Date: Wed, 7 Jun 2000 09:45:46 -0400 Keywords: IETF Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <393E4735.3C173C3A@cs.columbia.edu> 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 This has been a good discussion. Sonce I'm basically interested in getting the functionality, I'm not strongly wedded to whether we define a separate header, or use Contact. Contact certainly seems the course of least resistance, as Henning and Jonathan point out, and I agree. To respond to Christian Heuitema's message, if all I was trying to do was get access to an announcement server that played error-response-dependent audio or did something fixed, then I agree that there's no need for enahncing SIP itself. However, I want to factor out the UAC policy about what it does when it gets an error reponse from how the alternatives for what it could do are presented. It seems for flexibility it makes sense to allow the protocol to carry the alternatives. Getting back to thge issue of Contact vs. new header, I did, however, think of one reason why a separate header provides more flexibility, which may also alleviate Henning's (and my) concern about what such a header would mean on a 2xx or 3xx. Let's suppose you do get a 3xx-style redirect. If we had a separate header, like Scott's proposed "Error-URL:" the UAC could *both* act on the URL, *and* retry the invite to the parties listed in the Contact: header. For example, let's suppose I'm on vacation, and I set my UAS (or my local proxy) to reject the Invite with a 302 Moved Temporarily, with the contact field set to, say, my voicemail server, and the new header set a URL which points to an audio file that says "Sorry I'm away, you'll have to talk to my voicemail". The UAC could then access the message either before retrying, or in parallel with retrying to the voicemail. Don't know if people find this example useful, but it might stimulate further discussion and hopefully consensus. Dave. > -----Original Message----- > From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]On Behalf Of > Henning Schulzrinne > Sent: Wednesday, June 07, 2000 9:00 AM > To: Jonathan Rosenberg > Cc: Scott Petrack; Dave Oran; IETF SIP WG > Subject: Re: [SIP] Porposal for providing additional error information > toUACs > > > Jonathan Rosenberg wrote: > > > > Scott Petrack wrote: > > > > > > If you are going to put a URL to allow the appliance to retrieve the > > > error, I suggest a new header, rather than the Contact: > header. Something > > > like Warning-URL: or Error-URL: > > > or even just Display-URL: (the appliance doesn't really need > to know if > > > the stuff to be retrieved and displayed is a warning or some > extra info. > > > The same mechanism could be used for "extra lookups" sort of > as if there > > > were an end-to-end calling-party identification service). > > > > Whether to use Contact or a new header depends a lot on how you want to > > define the precise semantics of the header. If you use the loosest > > definition, which is "go here", then Contact will suffice. In fact, > > using Contact has the advantage of being able to also use the caller > > preferences capabilities. The UA can, in the INVITE, indicate that it > > only knows about sip URL schemes. This way, your redirecting device > > would not try to send the UA to an rtsp URL, rather it might redirect > > the UA to an app server which contacts the RTSP server and streams the > > content to the UA. > > > > However, if your definition of Contact is "try this address to reach the > > desired party", probably Contact is not the right thing. As Dave has > > pointed out, proxies can recurse on 3xx and attempt to reach the > > addresses in a Contact header because the meaning is precisely "try this > > address to reach the desired party", and thus its fine for the proxy to > > try that address. But, Dave doesn't want proxies to go to these > > addresses - they should only be used by the UA upon receipt of the > > reject response. > > I'm not sure this is different from "this address is only to be used in > case the original address isn't reachable" (3xx). > > > > > So, I'm a bit on the fence, but probably inclined to define a new header > > in order to avoid further overload of exactly what Contact means. > > > > Since there is no ambiguity in the action to be taken, I'm not in favor > of defining a new header. Defining a new header then means worrying > about whether *it* has meaning for 3xx or 2xx responses. Thus, in terms > of economy of definition, this one-paragraph version seems to be the > lowest-cost way of achieving additional error explanation capability. > Any new header also increases the chances for misunderstandings, with > various combinations of the new and Contact header. > > > -- > 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 Jun 7 09:51: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 JAA10525 for ; Wed, 7 Jun 2000 09:51: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 19288443E5; Wed, 7 Jun 2000 09:41:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 0C8A0443DE for ; Wed, 7 Jun 2000 09:40:52 -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.9) with ESMTP id e57Dojr28775; Wed, 7 Jun 2000 15:50:45 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA08076; Wed, 7 Jun 2000 16:50:44 +0300 (EET DST) Message-ID: <393E52F9.1B82544E@lmf.ericsson.se> Date: Wed, 07 Jun 2000 16:49:45 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: jdrosen@dynamicsoft.com Cc: Henry.Sinnreich@WCOM.Com, sip@lists.bell-labs.com Subject: Re: [SIP] SIP Rules! References: <75C79E507864D3118AFC00805FEAB7D85B2736@ripexch001.mcit.com> <392D4311.FDF27E1C@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, Are we receiving the "Computer Telephony Magazine"?? Does any of you have a copy? Thanks, Gonzalo jdrosen@dynamicsoft.com wrote: > > Let me add that that story was the cover article of the May Computer > Telephony Magazine. The cover itself is very amusing.... I encourage > people to pick up a copy. > > -Jonathan R. > > "Sinnreich, Henry" wrote: > > > > You may have seen it, but here is the URL: > > http://commweb.com/features/comptel/2k0522.sip.html > > > > Henry > > > > >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: (732) 741-4778 > 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 -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 7 11:33: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 LAA13337 for ; Wed, 7 Jun 2000 11: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 4D1CD4433D; Wed, 7 Jun 2000 11:23:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mushroom.icoe.net (icoe-gate.icoe.att.nl [194.242.71.50]) by lists.bell-labs.com (Postfix) with ESMTP id 09F4344336 for ; Wed, 7 Jun 2000 11:23:33 -0400 (EDT) Received: by mushroom.icoe.net; id RAA24353; Wed, 7 Jun 2000 17:34:00 +0200 (CEST) Received: from unknown(135.76.170.11) by mushroom.icoe.net via smap (4.0a) id xma024348; Wed, 7 Jun 00 17:33:31 +0200 Received: from blackberry (mikan.icoe.att.com [135.76.170.4]) by watermelon.icoe.att.com (Postfix) with ESMTP id 66D4111581; Wed, 7 Jun 2000 17:33:02 +0200 (MET DST) Message-Id: <4.2.0.58.20000607134558.00a21db0@watermelon.icoe.att.com> X-Sender: romeo@watermelon.icoe.att.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 07 Jun 2000 17:32:30 +0200 To: petri.koskelainen@nokia.com From: Romeo Zwart Subject: Re: [SIP] Proxy-Supported header Cc: sip@lists.bell-labs.com In-Reply-To: <25B79E9476BAD211811B0008C7894CDC02F7936C@treis04nok> 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 Petri, At 02:07 PM 07-06-00 +0300, petri.koskelainen@nokia.com wrote: > It seems that currently there is no mechanism to inform other parties (e.g. > other proxies) about the supported proxy capabilities. > This is needed especially in REGISTER messages but useful also in INVITEs > as well. I agree with you that there is a need for a mechanism to exchange capability info between proxies, in addition to capabilities exchange between UA (C and S). > Currently there exists (proposed) Supported header in SIP, but I suppose > it is meant for terminal capabilities only. > It is impossible to advertize both terminal and proxy capabilities at the > same time in one INVITE/REGISTER message. According to 2543bis: "The Supported general header field enumerates all the capabilities of the client or server". This text ("server") does not seem to exclude using Supported by proxies, however, you are right that you run into problems with expressing both UA and server capabilities in the same (forwarded) message. Therefore Proxy-Supported seems to make sense. > Therefore, I'd like to propose "Proxy-Supported" header to be included > into RFC2543bis draft. > The syntax is identical to Supported header. > > Comments? The same argumentation applies to a Proxy-Unsupported header as well. If we need Proxy-Supported, do we also need Proxy-Unsupported? Romeo > -- > Petri Koskelainen > Nokia Research Center _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 7 13:02: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 NAA16107 for ; Wed, 7 Jun 2000 13:02: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 5FC084438E; Wed, 7 Jun 2000 12:51: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 1100544336 for ; Wed, 7 Jun 2000 12:51:50 -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 NAA09121; Wed, 7 Jun 2000 13:03:15 -0400 (EDT) Message-ID: <393E801E.D88C8FC1@dynamicsoft.com> Date: Wed, 07 Jun 2000 13:02:22 -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: "McMurry, Kathleen" , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses References: <75C79E507864D3118AFC00805FEAB7D85B392B@ripexch001.mcit.com> <393CFB7E.B7A901BF@cs.columbia.edu> <393DE3B8.2C65762F@dynamicsoft.com> <393E40E5.FD445C0B@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: > > > This gets confusing if IP addresses are used in the Via header > > instead.... > > > But probably still manageable, with somewhat more work (you'd have to > translate the domain of the signer to see if it matches the IP address). > Isn't perfect, but given that the attack requires a fair amount of > sophistication to begin with, I suspect that this will be an issue only > in very limited (high-assurance) situations. A paranoid implementation > could simply say "acme.com (signed) wants to cancel your call from > aol.com". Unless you (or the original destination) are in either the > acme or aol domain, it's very likely that this is a fake, regardless of > the precise IP address. True. So, sounds like we have two solutions for CANCEL security: 1. source address validation, marginally useful 2. only accept CANCEL on an SA, and that CANCEL must be for a request received over the SA 3. proxies sign CANCEL Like any other security mechanism, there are pros and cons. Probably the spec should mention all three. -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 Jun 7 13:30: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 NAA16633 for ; Wed, 7 Jun 2000 13:30: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 4B288443B8; Wed, 7 Jun 2000 13:19: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 E756244336 for ; Wed, 7 Jun 2000 13:19:38 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA21547 for ; Wed, 7 Jun 2000 13:29:49 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id NAA00509; Wed, 7 Jun 2000 13:29:48 -0400 (EDT) Date: Wed, 7 Jun 2000 13:29:48 -0400 (EDT) Message-Id: <200006071729.NAA00509@ind.cs.columbia.edu> From: Jonathan Lennox To: sip@lists.bell-labs.com Subject: Re: [SIP] CANCEL security (was: Request/Responses from other addresses) In-Reply-To: <393E801E.D88C8FC1@dynamicsoft.com> References: <75C79E507864D3118AFC00805FEAB7D85B392B@ripexch001.mcit.com> <393CFB7E.B7A901BF@cs.columbia.edu> <393DE3B8.2C65762F@dynamicsoft.com> <393E40E5.FD445C0B@cs.columbia.edu> <393E801E.D88C8FC1@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 On Wed, June 7 2000, "Jonathan Rosenberg" wrote to "Henning Schulzrinne, McMurry, Kathleen, Sean Olson, sip@lists.bell-labs.com" saying: > True. So, sounds like we have two solutions for CANCEL security: > > 1. source address validation, marginally useful > 2. only accept CANCEL on an SA, and that CANCEL must be for a request > received over the SA > 3. proxies sign CANCEL > > Like any other security mechanism, there are pros and cons. Probably the > spec should mention all three. There's another way to do CANCEL authentication; it's much lighter weight, and more robust, but it requires some spec extensions. When a proxy server proxies a request, it adds a hop-by-hop header "Cancel-Lock:" identifying its domain and containing a secure hash (MD5 or SHA/1) of some random string. If that proxy server subsequently wants to cancel the request, it inserts a "Cancel-Key:" containing the original string. A downstream server wanting to validate the CANCEL message simply verifies that the Cancel-Key does indeed hash to the Cancel-Lock that was in the original request. As an example, if a UAS receives the following request: INVITE sip:lennox@cs.columbia.edu SIP/2.0 .... Cancel-Lock: example.com md5 d1a6fb27aa2a3c6ff4a181001dba4a20 .... Then the following CANCEL request should be accepted for this transaction: CANCEL sip:lennox@cs.columbia.edu SIP/2.0 .... Cancel-Key: example.com md5 This-is-my-cancel-key-129781234701924701234 .... This has, I believe, the correct properties for CANCEL: any device which has been on the proxy chain for the initial request (including the initial UAC) can cancel it, but no one else can. No one has to have any security associations or relationships outside of this particular transaction. The main problem with this proposal is backward compatibility; it's not clear what the right thing to do is if some devices on the proxy chain support Cancel-Locks and others don't. (The idea for this scheme is taken from a similar proposal for securing the NNTP cancel cmsg.) -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 7 13:57: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 NAA17228 for ; Wed, 7 Jun 2000 13:57: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 7DFD8443AD; Wed, 7 Jun 2000 13:47: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 D1A5A44336 for ; Wed, 7 Jun 2000 13:47: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 NAA23392; Wed, 7 Jun 2000 13:57:48 -0400 (EDT) Message-ID: <393E8D1C.2D526C29@cs.columbia.edu> Date: Wed, 07 Jun 2000 13:57:48 -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 Lennox Cc: sip@lists.bell-labs.com Subject: Re: [SIP] CANCEL security (was: Request/Responses from other addresses) References: <75C79E507864D3118AFC00805FEAB7D85B392B@ripexch001.mcit.com> <393CFB7E.B7A901BF@cs.columbia.edu> <393DE3B8.2C65762F@dynamicsoft.com> <393E40E5.FD445C0B@cs.columbia.edu> <393E801E.D88C8FC1@dynamicsoft.com> <200006071729.NAA00509@ind.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 Jonathan Lennox wrote: > > On Wed, June 7 2000, "Jonathan Rosenberg" wrote to "Henning Schulzrinne, McMurry, Kathleen, Sean Olson, sip@lists.bell-labs.com" saying: > > > True. So, sounds like we have two solutions for CANCEL security: > > > > 1. source address validation, marginally useful > > 2. only accept CANCEL on an SA, and that CANCEL must be for a request > > received over the SA > > 3. proxies sign CANCEL > > > > Like any other security mechanism, there are pros and cons. Probably the > > spec should mention all three. > > There's another way to do CANCEL authentication; it's much lighter weight, > and more robust, but it requires some spec extensions. > > When a proxy server proxies a request, it adds a hop-by-hop header > "Cancel-Lock:" identifying its domain and containing a secure hash (MD5 or > SHA/1) of some random string. If that proxy server subsequently wants to > cancel the request, it inserts a "Cancel-Key:" containing the original > string. A downstream server wanting to validate the CANCEL message simply > verifies that the Cancel-Key does indeed hash to the Cancel-Lock that was in > the original request. > > As an example, if a UAS receives the following request: > > INVITE sip:lennox@cs.columbia.edu SIP/2.0 > .... > Cancel-Lock: example.com md5 d1a6fb27aa2a3c6ff4a181001dba4a20 > .... > > Then the following CANCEL request should be accepted for this transaction: > > CANCEL sip:lennox@cs.columbia.edu SIP/2.0 > .... > Cancel-Key: example.com md5 This-is-my-cancel-key-129781234701924701234 > .... > > This has, I believe, the correct properties for CANCEL: any device which has > been on the proxy chain for the initial request (including the initial UAC) > can cancel it, but no one else can. No one has to have any security > associations or relationships outside of this particular transaction. > > The main problem with this proposal is backward compatibility; it's not > clear what the right thing to do is if some devices on the proxy chain > support Cancel-Locks and others don't. > > (The idea for this scheme is taken from a similar proposal for securing the > NNTP cancel cmsg.) Assuming somebody can modify the INVITE request (or create a copy that outraces the original to the UAS), this doesn't help much. Presumably, you'd have to do the same thing with the BYE (assuming you don't do end system authentication, i.e., you are only concerned about an uninterrupted call once you've decided to speak to a person). It would be nice if this worked for re-INVITE, too... Frankly, given that there are for more "interesting" denial-of-service attacks that require far less snooping effort, I wonder if this a first-order problem. News is a bit different since anybody has all of the information required to cancel anybody else's article, unless you apply this proof-of-possession mechanism. > > -- > Jonathan Lennox > lennox@cs.columbia.edu > > _______________________________________________ > 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 Wed Jun 7 15:26: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 PAA18756 for ; Wed, 7 Jun 2000 15:26: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 3DDD7443A6; Wed, 7 Jun 2000 15:16:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id CA7E344336 for ; Wed, 7 Jun 2000 15:16:31 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id OAA13291 for ; Wed, 7 Jun 2000 14:28:38 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id OAA19330 for ; Wed, 7 Jun 2000 14:26:10 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Jun 2000 14:26:10 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790F0@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: sip@lists.bell-labs.com Subject: RE: [SIP] comments on draft-sparks-sip-cc-transfer-00.txt Date: Wed, 7 Jun 2000 14:26:01 -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 Sorry about missing the decision to remove the blanket restriction against bodies in TRANSFER messages. > > Section 4.5: "If the transferee's agent decides to attempt the transfer, a > > 200 OK response must be returned by the [sic] if it was able to establish a > > session with the transferor, otherwise a 603 Decline must be returned." > > > > There's a missing word in here, hence the "sic" above. > > Actually, there was an extra "the". My copy still doesn't read right after taking out "the", but I trust you will make the final copy make sense. :-) > > I think in the absence of a user query/response or known user configuration, it > > would be to respond with a Decline All. > > For the last statement - if an implementation doesn't (or can't) query > a user, and is by policy not going to accept transfers, why not have > it return a Method Not Allowed? That sounds good. I suppose you could even use it if the transferee was queried and the response was "for this session, I am unwilling to consider being transferred". As far as the particular session was concerned, the TRANSFER method would no longer be allowed. The transferee could even try a few proposed transfers that turned out to fail (or decline them one-by-one, or a mixture of both) and eventually give up in disgust and send back a Method Not Allowed. There is a difference between TRANSFER being unsupported by the software and TRANFERs being declined wholesale by the user, but I'm not sure it's important to relay that information to the transferor. It might even be considered a privacy issue to convey it. Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 7 15:30: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 PAA18797 for ; Wed, 7 Jun 2000 15:30: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 F36AF443C4; Wed, 7 Jun 2000 15:19:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id E35F144336 for ; Wed, 7 Jun 2000 15:19:50 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id OAA13398 for ; Wed, 7 Jun 2000 14:31:58 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id OAA19423 for ; Wed, 7 Jun 2000 14:29:30 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Jun 2000 14:29:30 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790F1@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: "'sip@lists.bell-labs.com'" Subject: FW: [SIP] Proposal for providing additional error information to UACs Date: Wed, 7 Jun 2000 14:29:26 -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 > Comment? Bricks? "380 Go to Jail, go directly to jail, do not > pass go, do not collect $200"? Should that be "do not collect 200 OK"? :-} Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 7 16:19: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 QAA19930 for ; Wed, 7 Jun 2000 16:19: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 27A5B44337; Wed, 7 Jun 2000 16:09:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id 4BFE544336 for ; Wed, 7 Jun 2000 16:09:03 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id PAA14725 for ; Wed, 7 Jun 2000 15:21:11 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id PAA20609 for ; Wed, 7 Jun 2000 15:18:42 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Jun 2000 15:18:42 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790F2@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: sip@lists.bell-labs.com Subject: RE: [SIP] comments on draft-sparks-sip-cc-transfer-00.txt Date: Wed, 7 Jun 2000 15:18: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 X-BeenThere: sip@lists.bell-labs.com > > In any case, there are four possible outcomes that I see for a TRANSFER: > > > > (1) There's something wrong with the request. I think this is dealt with in > > that any appropriate 400-600 class response may be returned. > > (2) The transfer is attempted, and succeeds. The section quoted above seems > > to say that 200 OK should be returned in this case, and I agree. > > (3) The transfer is attempted, but fails. > > (4) The transfer is not even attempted. > > > > The section quoted above seems to mandate 603 Decline for both cases (3) and (4). > > > > (4) is actually (4a) "this particular transfer will not be attempted" > > and (4b) "no transfer will be attempted." > Addressing 4b) first : if the transferee has instructed his UA to accept > no transfers, then the UA could return a 405 Method not Allowed. Agreed. > Can you sketch an example where it would make a difference to the > transferor's UA if a 603 response was due to 3) or 4a)? From its > perspective, should it care if the response came from the transferee > deciding "I don't want to talk to _that_ person" or "I tried, but > nobody answered". Maybe. :-) One example might be if the transferor might consider retrying the TRANSFER, perhaps after some time had passed, perhaps after doing some out-of-band thing to make it more likely that the transfer would succeed. Maybe the Bonds Department tries to TRANSFER the call to the IRA Department, and it fails because everyone is busy. But when a busy response is generated, a page goes out to have all the loiterers get back to the phones, so a little later the call might succeed. That TRANSFER failure would be different than a Decline (meaning "don't you dare transfer me to the IRA Department -- they transferred me to you!"). The difference might also be useful in planning one's call handling scenarios. If a high proportion of transfers from "General Support" to "OS Support" are not succeeding, it's different if they are failing because "OS Support" is understaffed and the calls are failing, vs. callers are declining to be transferred to "OS Support" (because "General Support" is cavalierly transferring callers there when the callers are sure it's an application problem, or because they've had bad experiences with OS Support in the past, or ...). I could maybe contrive some more examples, but these are the two that come to mind first. I guess if the transferor and the target are un-related, it doesn't make much difference if the transfer fails because it was tried and failed, or because it was declined. But in the cases where the transferor and the target are more tightly coupled (in the same umbrella organization, perhaps), it does seems to make a difference. The user-to-user session can proceed differently if the TRANSFER failed because the transferee declined/balked, or whether the TRANSFER failed despite the agreeableness of the transferee. So, using my numbering scheme, I still like (1) 400-600-class failure [problem with the TRANSFER request] (2) 200 OK [transfer attempted and succeeded] (3) ??? [some response that specifically means transfer attempted but failed] (4a) 603 Decline [this particular transfer will not be attempted] (4b) 405 Method Not Allowed [no transfer method will be attempted] (If the transfer was actually attempted, even knowing *why* the transfer failed could be useful in some cases. If Boss transfers calls to Peon, Boss may be interested in knowing whether the failure was because Peon is responding with 603 Decline or because of 500 Internal Server Error. I suppose in case (3), the transferee's UA could optionally include a reason phrase conveying any desired information about the transfer failure, while still using the status code that means only "transfer actually attempted but failed".) Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 7 17:13: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 RAA20847 for ; Wed, 7 Jun 2000 17:13: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 60836443B5; Wed, 7 Jun 2000 17:03:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id A12AC44336 for ; Wed, 7 Jun 2000 17:03:01 -0400 (EDT) Received: by mail with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 14:22:19 -0700 Message-ID: From: Sekhar Banerjee To: "'SIP@lists.bell-labs.com'" Date: Wed, 7 Jun 2000 14:22:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Distinctive ringing feature Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 would like to know if it would be possible to use SIP to instruct the endpoints/UA's to provide different ringing sequences. If someone has implemented this feature I would love to know more about it. I am talking about the distinctive ringing feature as it is present in the PSTN network today. Thanks Sekhar _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 7 19:32: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 TAA22601 for ; Wed, 7 Jun 2000 19:32: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 6DDB644364; Wed, 7 Jun 2000 19:21:35 -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 09C9944336 for ; Wed, 7 Jun 2000 19:21:32 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id SAA13265; Wed, 7 Jun 2000 18:31:40 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id SAA11220; Wed, 7 Jun 2000 18:31:40 -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 SAA23353; Wed, 7 Jun 2000 18:31:39 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id SAA07126; Wed, 7 Jun 2000 18:31:39 -0500 (CDT) Date: Wed, 7 Jun 2000 18:31:39 -0500 (CDT) Message-Id: <200006072331.SAA07126@b04a45.exu.ericsson.se> To: sip@lists.bell-labs.com, oran@cisco.com Subject: RE: [SIP] Proposal for providing additional error information to UACs 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 X-BeenThere: sip@lists.bell-labs.com > Let's suppose you do get a 3xx-style redirect. If we had a separate header, > like Scott's proposed "Error-URL:" the UAC could *both* act on the URL, > *and* retry the invite to the parties listed in the Contact: header. > > For example, let's suppose I'm on vacation, and I set my UAS (or my local > proxy) to reject the Invite with a 302 Moved Temporarily, with the contact > field set to, say, my voicemail server, and the new header set a URL which > points to an audio file that says "Sorry I'm away, you'll have to talk to my > voicemail". The UAC could then access the message either before retrying, or > in parallel with retrying to the voicemail. > > Don't know if people find this example useful, but it might stimulate > further discussion and hopefully consensus. > > Dave. This is a perfect example why Contact: should not be used. I personally think a URI in the body is the best solution provided enough implementations support multipart MIME bodies. The allows you to easily specify additional details about the nature of the content of the URI such as language. This is also in line with specifying additional information as a text/html body in a 4xx/6xx response. Consider this as analagous to the SDP payload of a 183 Session Progress response: you are specifying additional information or an alternate form of that information. sean -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 00:35: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 AAA27015 for ; Thu, 8 Jun 2000 00:35: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 92661443C6; Thu, 8 Jun 2000 00:24:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id 048D544336 for ; Thu, 8 Jun 2000 00:23:15 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA27753; Thu, 8 Jun 2000 10:49:16 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568F8.00193C18 ; Thu, 8 Jun 2000 10:05:37 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Sekhar Banerjee Cc: "'SIP@lists.bell-labs.com'" Message-ID: <652568F8.00193A95.00@sampark.hss.hns.com> Date: Thu, 8 Jun 2000 10:05:33 +0530 Subject: Re: [SIP] Distinctive ringing feature 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, you can definetely implement distinctive ringing from a SIP endpoint. The distinctive ring implementation is purely an endpoint side feature (see SIP FAQ on Henning's site) and does not need any special SIP signalling. For example, if say your phone has two alloted phone numbers - and you want a different ringing tone depending on the number the caller dialed - your implementation would simply see the phone number from the SIP headers and generate the appropriate ring for that phone. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Sekhar Banerjee on 06/08/2000 02:52:13 AM To: "'SIP@lists.bell-labs.com'" cc: Subject: [SIP] Distinctive ringing feature Hi, I would like to know if it would be possible to use SIP to instruct the endpoints/UA's to provide different ringing sequences. If someone has implemented this feature I would love to know more about it. I am talking about the distinctive ringing feature as it is present in the PSTN network today. Thanks Sekhar _______________________________________________ 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 Jun 8 00:39: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 AAA27040 for ; Thu, 8 Jun 2000 00:39: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 B8500443D6; Thu, 8 Jun 2000 00:28: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 F38B244336 for ; Thu, 8 Jun 2000 00:28:05 -0400 (EDT) Received: from dynamicsoft.com (1Cust207.tnt1.freehold.nj.da.uu.net [63.17.113.207]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA10908; Thu, 8 Jun 2000 00:35:53 -0400 (EDT) Message-ID: <393F2276.8A982CD4@dynamicsoft.com> Date: Thu, 08 Jun 2000 00:35:02 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sekhar Banerjee Cc: "'SIP@lists.bell-labs.com'" Subject: Re: [SIP] Distinctive ringing feature 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 Sekhar Banerjee wrote: > > Hi, > I would like to know if it would be possible to use SIP to instruct > the endpoints/UA's to provide different ringing sequences. Distinctive ringing is generally implemented locally (and I know of at least one implementation which does it locally). Conveying it in SIP doesn't make a whole lot of sense, since SIP is a peer to peer protocol. There is no notion of "the network" telling the phone how to ring. -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 Jun 8 00:42: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 AAA27077 for ; Thu, 8 Jun 2000 00:42: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 9DFC6443EE; Thu, 8 Jun 2000 00:29:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from agni.wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by lists.bell-labs.com (Postfix) with ESMTP id 63307443E6 for ; Thu, 8 Jun 2000 00:28:58 -0400 (EDT) Received: from vayu.wipinfo.soft.net (vayu [192.168.200.170]) by agni.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id KAA13153 for ; Thu, 8 Jun 2000 10:05:43 +0500 (GMT) Received: from sarovar.mail.wipro.com ([192.168.2.18]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id KAA27568 for ; Thu, 8 Jun 2000 10:07:52 +0500 (GMT) Received: from hiren ([192.168.243.67]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA55B3 for ; Thu, 8 Jun 2000 10:09:27 +0530 Message-ID: <003401bfd103$7b4d3df0$43f3a8c0@wipinfo.soft.net> From: "Hiren Shah" To: Date: Thu, 8 Jun 2000 10:09:06 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0031_01BFD131.94B78100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [SIP] Please unsubscribe me Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_0031_01BFD131.94B78100 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Please unsubscribe me ------=_NextPart_000_0031_01BFD131.94B78100 Content-Type: text/x-vcard; name="Hiren Shah.vcf" Content-Disposition: attachment; filename="Hiren Shah.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Shah;Hiren FN:Hiren Shah ORG:Wipro (Global R&D);ESBU TITLE:Engineer-Software TEL;WORK;VOICE:5722296 (extn : 5109) TEL;HOME;VOICE:5533736 ADR;WORK:;Madivala-II;26 Main,Hosur Road;Bangalore;Karnataka;;India LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Madivala-II=3D0D=3D0A26 = Main,Hosur Road=3D0D=3D0ABangalore, Karnataka=3D0D=3D0AIndia REV:20000608T043906Z END:VCARD ------=_NextPart_000_0031_01BFD131.94B78100-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 00:48: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 AAA27111 for ; Thu, 8 Jun 2000 00:48: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 D9D85443F6; Thu, 8 Jun 2000 00:33: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 A230C443E7 for ; Thu, 8 Jun 2000 00:33:36 -0400 (EDT) Received: from dynamicsoft.com (1Cust207.tnt1.freehold.nj.da.uu.net [63.17.113.207]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA10916 for ; Thu, 8 Jun 2000 00:45:14 -0400 (EDT) Message-ID: <393F24A8.2321106C@dynamicsoft.com> Date: Thu, 08 Jun 2000 00:44:24 -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] missing extension placeholders Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, Unfortunately, rfc2543 has a few places where we really need extension placeholders in the grammar, but they are not there. We would like to add these in to the revised draft; please shout if you have a problem with this. Some of the places: 1. transport parameter of SIP URL (we need sctp and tls plus who knows what else..) 2. user parameter in SIP URL 3. Hide header 4. Content-Disposition 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 Thu Jun 8 06:48: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 GAA10677 for ; Thu, 8 Jun 2000 06:48: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 A1A75443B6; Thu, 8 Jun 2000 06:37:57 -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 9C30844336 for ; Thu, 8 Jun 2000 06:37:53 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA28477; Thu, 8 Jun 2000 11:45:55 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: , Jonathan Rosenberg Date: Thu, 8 Jun 2000 10:41:12 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: Sip Mail List MIME-Version: 1.0 Message-Id: <00060811434200.20037@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] RE: Lessons Learned Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 Jonathan Rosenberg wrote: >"Adam B. Roach" wrote: *snip* >> >> 3) This is actually a disagreement I have with RFC2543, and >> one that I raised some time ago; however, no one seemed >> interested at the time. Since it actively prevented us from >>running one of the test cases we wanted to run at this bakeoff, >> I'm going to raise the issue again. Take discussion on this >> topic to the SIP working group mailing list, please. >> >> According to section 6.37, an implementation should reject >> messages containing unknown URIs in the "To:" field with >> a 400 response. Many implementations actually did this. >> The test case we were attempting was as follows: >> >> UAC1 ----> tel: mapping proxy -----> UAC2 >> *snip* >> UAC2 definitely has quite enough information to service the >> call. In fact, if not for this clause in 2543, the call would >> be set up perfectly. I contend that clients shouldn't >> care if they understand the URI in the To: field, as long >> as they can process the call, and I encourage implementations >> to exhibit this behavior. >> >> This also follows naturally from what I suggested above: don't >> validate fields unless you intend to use the information >> contained in them. > >Hmm. This is a good point. Given the increasing use of tel URLs, its >probably worth changing this in rfc2543bis. This doesn't introduce >backwards compatibility problems; it just means that calls to UAs >compliant to the bis version will get set up successfully, when they >won't with rfc2543. > >In general, the *request URI* is what is important in processing a >request. The To field is used only for (1) call leg identification >(along with From and Call-ID), and (2) FYI to the called party. The >request URI represents the desired user at the server being contacted. >The To field may contain a URI which is meaningless within the namespace >served by the server. I agree with the sentiments here but I have a question. How is it possible to correctly equate two separate unknown URI's in a transaction ID? For example lets say the server (UA or Proxy etc..) receives a To: header that contains an Unknown URI as follows: To: A URI allows escaping, may be case sensitive, may be case insensitive or may be both. So how is it possible to equate the URI above to: To: they may or may not be equal. it all depends on the URI specification itself. So if two INVITE's are received, identical apart from the To headers shown above, what is the server to do. If it does byte by byte comparison, then it will consider them two separate messages. If it is really one message then a UA may provide two alertings for the one call or may accept one and send a BUSY back on the other. Whatever, both are wrong. Conversely, if it unescapes the chars and does a case-insensitive comparison then it will consider the two messages identical. If however, the difference in case is important to the URI spec then they are in fact two different messages and again the action taken will be wrong. This has been added to the bis draft (Section F, top of page 117, although i can't find where it refers to) but it only considers the To header. This does in fact have broader implications and is an issue for every element that uses URI's (From, Via, Request-uri), and subsequently every transaction id, Call-Leg and thus message. As i see it, the original action (RFC 2543) of sending an error back on Unknown URI's was the correct one. It would be nice to handle unknown URI's properly but i don't see how this is possible. BTW sorry for bringing up a problem with a thread that is over a month old. Big up the massive ;) -- Gethin Liddell Team Geffin 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 Jun 8 09:01: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 JAA02020 for ; Thu, 8 Jun 2000 09:01: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 0F487443E1; Thu, 8 Jun 2000 08:49:51 -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 46D9A44336 for ; Thu, 8 Jun 2000 08:49:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 8 08:58:21 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6E02344344; Thu, 8 Jun 2000 08:45:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3CB0B44341 for ; Thu, 8 Jun 2000 08:45:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E97B252D0; Thu, 8 Jun 2000 08:45:23 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8307B52AB for ; Thu, 8 Jun 2000 08:45:19 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 8 08:44:21 EDT 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Thu Jun 8 08:44:19 EDT 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA03369; Thu, 8 Jun 2000 18:59:35 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568F8.0046801F ; Thu, 8 Jun 2000 18:20:03 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Taji Rachid Cc: sip@lists.research.bell-labs.com Message-ID: <652568F8.00467F49.00@sampark.hss.hns.com> Date: Thu, 8 Jun 2000 18:20:00 +0530 Subject: Re: [SIP] how to retransmit final response ? 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 Its very much a part of the bis draft See section 1.5.1 Quote: "A server which transmits a provisional response should retransmit it upon reception of a duplicate re-quest. A server which transmits a final response should retransmit it with an interval that starts at T1 seconds, and doubles for each subsequent packet until it reaches T2 seconds. Response retransmissions cease when any one of the following occurs: 1. An ACK request for the same transaction is received; 2. a BYE request for the same call leg is received; 3. a CANCEL request for the same call leg is received and the final response status was equal or greater to 300; 4. the response has been transmitted 7 times." Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Technical Leader, VOIP Solutions Off: Prestige Opal,146 Infantry Road,Blore - 560001 Ph:+91-080-2286390/1/2 Res: 68/G 2nd Narayanappa Block, RT Nagar,Blore - 560032 Ph:3430565 http://arjun.cjb.net Taji Rachid on 06/08/2000 05:44:10 PM To: sip@lists.research.bell-labs.com cc: Subject: [SIP] how to retransmit final response ? Hi All; What is the policy for reliability of final responses in UDP ? I didn't find anywhere in the SIP RFC the way to retransmit final responses. Can anyone of you help me ? Thanks Rachid _______________________________________________ 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 Jun 8 09: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 JAA02578 for ; Thu, 8 Jun 2000 09: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 9983C443EF; Thu, 8 Jun 2000 08:49:54 -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 9225744387 for ; Thu, 8 Jun 2000 08:49:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 8 08:58:23 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0D5DB44346; Thu, 8 Jun 2000 08:45:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9A58944345 for ; Thu, 8 Jun 2000 08:45:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 665AC52AB; Thu, 8 Jun 2000 08:45:23 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E1D6552C4 for ; Thu, 8 Jun 2000 08:45:21 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 8 08:44:52 EDT 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Thu Jun 8 08:44:51 EDT 2000 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.9) with ESMTP id e58Cijr10385; Thu, 8 Jun 2000 14:44:45 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA11360; Thu, 8 Jun 2000 15:44:44 +0300 (EET DST) Message-ID: <393F94FC.DF74C745@lmf.ericsson.se> Date: Thu, 08 Jun 2000 15:43:40 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Taji Rachid Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] how to retransmit final response ? References: <679076A067F2D211A8F70090274481B8440687@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 Hi, Final responses (UDP) for BYE, REGISTER, CANCEL & OPTIONS: RFC 2543, section 10.4.1 Final responses (UDP) for INVITE: RFC 2543, section 10.5.1 Gonzalo Taji Rachid wrote: > > Hi All; > > What is the policy for reliability of final responses in UDP ? > > I didn't find anywhere in the SIP RFC the way to retransmit final responses. > > Can anyone of you help me ? > > Thanks > > Rachid > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 09:14: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 JAA04004 for ; Thu, 8 Jun 2000 09:14: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 8AF53443BF; Thu, 8 Jun 2000 09:01:49 -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 D6D5444336 for ; Thu, 8 Jun 2000 09:01:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 8 09:11:31 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1F4A844347; Thu, 8 Jun 2000 08:45:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id BF64444341 for ; Thu, 8 Jun 2000 08:45:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CAC2852C4; Thu, 8 Jun 2000 08:45:23 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6C98552C8 for ; Thu, 8 Jun 2000 08:45:22 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 8 08:44:51 EDT 2000 Received: from sasi.com ([164.164.56.2]) by dusty; Thu Jun 8 08:44:49 EDT 2000 Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id SAA25820; Thu, 8 Jun 2000 18:12:43 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 08 Jun 2000 18:12:42 +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 SAA20894; Thu, 8 Jun 2000 18:12:42 +0530 (IST) Message-ID: <07fa01bfd145$e4fd0900$8c40000a@sasi.com> From: "rafi" To: "Taji Rachid" , References: <679076A067F2D211A8F70090274481B8440687@LNN201E> Subject: Re: [SIP] how to retransmit final response ? Date: Thu, 8 Jun 2000 18:04: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 Rachid, Please refer to section 10.4.1 in the SIP RFC. Regards Rafi Assadi H.M. ----- Original Message ----- From: Taji Rachid To: Sent: Thursday, June 08, 2000 5:44 PM Subject: [SIP] how to retransmit final response ? > Hi All; > > What is the policy for reliability of final responses in UDP ? > > I didn't find anywhere in the SIP RFC the way to retransmit final responses. > > Can anyone of you help me ? > > Thanks > > Rachid > > > > _______________________________________________ > 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 Jun 8 09:31: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 JAA06868 for ; Thu, 8 Jun 2000 09:31: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 39153443D9; Thu, 8 Jun 2000 09:21:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.192.45]) by lists.bell-labs.com (Postfix) with ESMTP id 0E7FF44336 for ; Thu, 8 Jun 2000 09:21:04 -0400 (EDT) Received: from [193.118.192.41] by cundall.co.uk with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 8 Jun 2000 14:30:19 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <393F24A8.2321106C@dynamicsoft.com> References: <393F24A8.2321106C@dynamicsoft.com> Date: Thu, 8 Jun 2000 14:31:41 +0100 To: Jonathan Rosenberg , sip From: Lawrence Conroy Subject: Re: [SIP] missing extension placeholders 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:44 am -0400 8/6/00, Jonathan Rosenberg wrote: >Folks, > >Unfortunately, rfc2543 has a few places where we really need extension >placeholders in the grammar, but they are not there. We would like to >add these in to the revised draft; please shout if you have a problem >with this. Some of the places: > >1. transport parameter of SIP URL (we need sctp and tls plus who knows >what else..) >2. user parameter in SIP URL >3. Hide header >4. Content-Disposition To which I reply: Absolutely fine, but how will this fit with TEL: urls? If we expand the parameters of a SIP URL, then it would be nice if they could be done in a way that still fits with the current RFC 2806 BNF for future-extension (I doubt it will as 2806's BNF for this is pretty generic, but...). -- All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd pay me for them" | |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 09: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 JAA07739 for ; Thu, 8 Jun 2000 09:50: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 06D49443FF; Thu, 8 Jun 2000 09:39:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 3CD8F443F4 for ; Thu, 8 Jun 2000 09:38:57 -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.9) with ESMTP id e58Dn6r04938; Thu, 8 Jun 2000 15:49:07 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA16387; Thu, 8 Jun 2000 16:49:05 +0300 (EET DST) Message-ID: <393FA410.1A1C4981@lmf.ericsson.se> Date: Thu, 08 Jun 2000 16:48:00 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: "McMurry, Kathleen" , "'Jonathan Rosenberg'" , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses References: <75C79E507864D3118AFC00805FEAB7D85B392B@ripexch001.mcit.com> <393CFB7E.B7A901BF@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: > > While verifying CANCEL source address is somewhat useful, I wouldn't put > too much faith in it (or feel too bad about not implementing it). In the > realistic cases where somebody can intercept the original INVITE (and, > thus, know the To, From, CSeq and Call-ID needed to spoof the CANCEL), > the same person can probably also fake the source address. I agree. Source address validation does not seem that useful. If loose source routing or strict source routing (provided by IP) are used the source IP address is not even the last "host" that handled the packet. Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 09:55: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 JAA07806 for ; Thu, 8 Jun 2000 09:55: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 3A12344402; Thu, 8 Jun 2000 09:43: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 B1C28443F4 for ; Thu, 8 Jun 2000 09:42: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 JAA19413; Thu, 8 Jun 2000 09:53:06 -0400 (EDT) Message-ID: <393FA542.FDEBBDB9@cs.columbia.edu> Date: Thu, 08 Jun 2000 09:53: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: Gethin Liddell Cc: adam.roach@ericsson.com, Jonathan Rosenberg , Sip Mail List Subject: Re: [SIP] RE: Lessons Learned References: <00060811434200.20037@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: > > >In general, the *request URI* is what is important in processing a > >request. The To field is used only for (1) call leg identification > >(along with From and Call-ID), and (2) FYI to the called party. The > >request URI represents the desired user at the server being contacted. > >The To field may contain a URI which is meaningless within the namespace > >served by the server. This was changed April 23 and has been in the 2543bis since that time. > > I agree with the sentiments here but I have a question. > > How is it possible to correctly equate two separate unknown > URI's in a transaction ID? > > For example lets say the server (UA or Proxy etc..) receives a > To: header that contains an Unknown URI as follows: > > To: > > A URI allows escaping, may be case sensitive, may be case > insensitive or may be both. So how is it possible to equate the > URI above to: > > To: > > they may or may not be equal. it all depends on the URI specification itself. > > So if two INVITE's are received, identical apart from the To headers shown above, > what is the server to do. Practically speaking, this would only occur if the other side intentionally mangled the URL on either responses or for requests in the other direction. Thus, the correct solution (particularly for URL types other than SIP) is that the callee copies the URL in the From field into the To field and vice versa if it wants to send a request in the other direction (for the same call). For request-URI, comparison only matters to compute branch ids for loops. However, request URIs are not likely to be random URI types as they have to be understood by the receiving proxy. In addition, you'd have to have a truly strange proxy that does random equivalence transformations on URLs looked up locally, within the same transaction. Via's don't contain URLs and obviously have nothing to do with call legs. Contact are copied into Request-URIs, so they don't matter for call leg computation. Thus, byte-by-byte comparison of unknown URL types would seem to work fine in practice. > > If it does byte by byte comparison, then it will consider them two separate messages. > If it is really one message then a UA may provide two alertings for the one call or > may accept one and send a BUSY back on the other. Whatever, both are wrong. > > Conversely, if it unescapes the chars and does a case-insensitive comparison then > it will consider the two messages identical. If however, the difference in case is > important to the URI spec then they are in fact two different messages and again the > action taken will be wrong. > > This has been added to the bis draft (Section F, top of page 117, although i can't > find where it refers to) but it only considers the To header. This does in fact have > broader implications and is an issue for every element that uses URI's (From, Via, > Request-uri), and subsequently every transaction id, Call-Leg and thus message. > > As i see it, the original action (RFC 2543) of sending an error back on Unknown URI's > was the correct one. It would be nice to handle unknown URI's properly but i don't > see how this is possible. > > BTW sorry for bringing up a problem with a thread that is over a month old. Big up the > massive ;) > > -- > Gethin Liddell > Team Geffin > 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 -- 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 Jun 8 10:02: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 KAA07947 for ; Thu, 8 Jun 2000 10:02: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 E3C4A443F4; Thu, 8 Jun 2000 09:51:39 -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 24C7B443DC for ; Thu, 8 Jun 2000 09:51:37 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id JAA15138; Thu, 8 Jun 2000 09:01:53 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA21094; Thu, 8 Jun 2000 09:01:53 -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 JAA23483; Thu, 8 Jun 2000 09:01:52 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id JAA08128; Thu, 8 Jun 2000 09:01:52 -0500 (CDT) Date: Thu, 8 Jun 2000 09:01:52 -0500 (CDT) Message-Id: <200006081401.JAA08128@b04a45.exu.ericsson.se> To: adam.roach@ericsson.com, jdrosen@dynamicsoft.com, gethin@ubiquity.net Subject: Re: [SIP] RE: Lessons Learned Cc: 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 X-BeenThere: sip@lists.bell-labs.com > I agree with the sentiments here but I have a question. > > How is it possible to correctly equate two separate unknown > URI's in a transaction ID? > You have three options: 1) Treat the URI as "generic" in the sense of RFC2396. Then you can create a canonical form using basic heuristics like the "host" should be CI, the "userinfo" should CS, etc. Make a best effort guess as to whether or not various portions of the URI should be excluded and/or considered CI. Before anyone comments that this won't work in all situations, let me assure you that I know this :) It does, however, work fairly well. 2) Treat the URI as an opaque string and do a byte-for-byte comparison. This also won't work in all cases. It is a best effort attempt. (This would work for most tel: URIs.) 3) Cry foul and reject with a 4xx response. It is VERY unfortunate that you can't treat the To: and From: URIs as immutable strings and so here we are (I hope that anyone writing a SIP implementation out there will take this into account when they are considering whether or not to add the port to the URI or change the case of the hostname or other things like that). What Adam is arguing for (and I agree) is to do your best and not be overly concerned about details that may not be meaningful to you and your application anyways. sean -- Sean Olson > -- > Gethin Liddell > Team Geffin > 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 Jun 8 10: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 KAA08117 for ; Thu, 8 Jun 2000 10: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 6B7974440B; Thu, 8 Jun 2000 09:53:26 -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 416FB443FB for ; Thu, 8 Jun 2000 09:53:23 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id JAA15748; Thu, 8 Jun 2000 09:03:38 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA22272; Thu, 8 Jun 2000 09:03:38 -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 JAA23635; Thu, 8 Jun 2000 09:03:38 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id JAA08132; Thu, 8 Jun 2000 09:03:37 -0500 (CDT) Date: Thu, 8 Jun 2000 09:03:37 -0500 (CDT) Message-Id: <200006081403.JAA08132@b04a45.exu.ericsson.se> To: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com, lwc@roke.co.uk Subject: Re: [SIP] missing extension placeholders 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 X-BeenThere: sip@lists.bell-labs.com > >Unfortunately, rfc2543 has a few places where we really need extension > >placeholders in the grammar, but they are not there. We would like to > >add these in to the revised draft; please shout if you have a problem > >with this. Some of the places: > > > >1. transport parameter of SIP URL (we need sctp and tls plus who knows > >what else..) > >2. user parameter in SIP URL > >3. Hide header > >4. Content-Disposition > To which I reply: > Absolutely fine, but how will this fit with TEL: urls? > If we expand the parameters of a SIP URL, then it would be nice if they > could be done in a way that still fits with the current RFC 2806 BNF > for future-extension (I doubt it will as 2806's BNF for this is > pretty generic, but...). The transport and user parameters don't need to be added to the tel: URI so this should be ok. sean -- Sean Olson > -- > All the best, Lawrence > ----------------------------------------------------------------------- > | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | > | Roke Manor Research | were my Company's they'd pay me for them" | > |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 10:44: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 KAA08702 for ; Thu, 8 Jun 2000 10:44: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 B09C0443D2; Thu, 8 Jun 2000 08:19:47 -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 3E04944336 for ; Thu, 8 Jun 2000 08:19:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 8 08:28:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0C9AF44345; Thu, 8 Jun 2000 08:15:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id CDCFD44341 for ; Thu, 8 Jun 2000 08:15:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DCDB152C4; Thu, 8 Jun 2000 08:15:22 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0CC0952B6 for ; Thu, 8 Jun 2000 08:15:19 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 8 08:13:25 EDT 2000 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by dusty; Thu Jun 8 08:13:24 EDT 2000 Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA09926 for ; Thu, 8 Jun 2000 14:12:45 +0200 (MET DST) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA05523 for ; Thu, 8 Jun 2000 14:13:04 +0200 (MET DST) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id ; Thu, 8 Jun 2000 14:15:45 +0200 Message-ID: <679076A067F2D211A8F70090274481B8440687@LNN201E> From: Taji Rachid To: sip@lists.research.bell-labs.com Date: Thu, 8 Jun 2000 14:14:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Subject: [SIP] how to retransmit final response ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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; What is the policy for reliability of final responses in UDP ? I didn't find anywhere in the SIP RFC the way to retransmit final responses. Can anyone of you help me ? Thanks Rachid _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 10:51: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 KAA08868 for ; Thu, 8 Jun 2000 10:51: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 47331443DC; Thu, 8 Jun 2000 10:40:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 1E6A34439B for ; Thu, 8 Jun 2000 10:40:38 -0400 (EDT) Received: from ORANLT ([171.68.181.170]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA449A; Thu, 8 Jun 2000 10:51:06 -0400 From: "Dave Oran" To: "Sekhar Banerjee" , Subject: RE: [SIP] Distinctive ringing feature Date: Thu, 8 Jun 2000 10:50:52 -0400 Keywords: IETF 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.2911.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 Why can't the SIP user agent just figure it out for itself? The "PSTN version" of this can just play a different audio file (or built-in ting tone) based on the To: field or the Request-URI field in the Invite. More sophisticated UAs can play different rings based on the From: field (say to ring "outside" and "inside" calls differently, or just about anything it's clever enough to figure out from the Invite message. The possibilities are limitless once you decouple the user interface from the protocol! Dave. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Sekhar Banerjee > Sent: Wednesday, June 07, 2000 5:22 PM > To: 'SIP@lists.bell-labs.com' > Subject: [SIP] Distinctive ringing feature > > > Hi, > I would like to know if it would be possible to use SIP to instruct > the endpoints/UA's to provide different ringing sequences. If someone has > implemented this feature I would love to know more about it. I am talking > about the distinctive ringing feature as it is present in the PSTN network > today. > > Thanks > > Sekhar > > > _______________________________________________ > 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 Jun 8 10: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 KAA08997 for ; Thu, 8 Jun 2000 10:58: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 72C864440A; Thu, 8 Jun 2000 10:42:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 7DF244439B for ; Thu, 8 Jun 2000 10:42:11 -0400 (EDT) Received: from ORANLT ([171.68.181.170]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA44FC; Thu, 8 Jun 2000 10:52:39 -0400 From: "Dave Oran" To: "Sean Olson" , Subject: RE: [SIP] Proposal for providing additional error information to UACs Date: Thu, 8 Jun 2000 10:52:24 -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.2911.0) In-Reply-To: <200006072331.SAA07126@b04a45.exu.ericsson.se> 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 The body approach does seem themost flexible, but it also is the heaviest-weight. The way I see this used it's likely to be a proxy which inserts the information and I don't relish having to write proxy code that tears apart and re-constructs a MIME multi-part body to add this information. We'd probably also need some MIME notation to indicate what the purpose of the body part was, at least via conventions documented somewhere. I'm on the fence on this one, like Jonathan. Any suggestions how to reach closure? Dave > -----Original Message----- > From: Sean Olson [mailto:eussean@exu.ericsson.se] > Sent: Wednesday, June 07, 2000 7:32 PM > To: sip@lists.bell-labs.com; oran@cisco.com > Subject: RE: [SIP] Proposal for providing additional error information > to UACs > > > > Let's suppose you do get a 3xx-style redirect. If we had a > separate header, > > like Scott's proposed "Error-URL:" the UAC could *both* act on the URL, > > *and* retry the invite to the parties listed in the Contact: header. > > > > For example, let's suppose I'm on vacation, and I set my UAS > (or my local > > proxy) to reject the Invite with a 302 Moved Temporarily, with > the contact > > field set to, say, my voicemail server, and the new header set > a URL which > > points to an audio file that says "Sorry I'm away, you'll have > to talk to my > > voicemail". The UAC could then access the message either before > retrying, or > > in parallel with retrying to the voicemail. > > > > Don't know if people find this example useful, but it might stimulate > > further discussion and hopefully consensus. > > > > Dave. > > This is a perfect example why Contact: should not be used. I personally > think a URI in the body is the best solution provided enough > implementations > support multipart MIME bodies. The allows you to easily specify additional > details about the nature of the content of the URI such as > language. This is > also in line with specifying additional information as a > text/html body in > a 4xx/6xx response. Consider this as analagous to the SDP payload of a > 183 Session Progress response: you are specifying additional > information or an > alternate form of that information. > > sean > -- > Sean Olson > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 12: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 MAA11838 for ; Thu, 8 Jun 2000 12: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 C853444336; Thu, 8 Jun 2000 12:40:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by lists.bell-labs.com (Postfix) with ESMTP id 103A844389 for ; Thu, 8 Jun 2000 12:40:41 -0400 (EDT) Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D3GFA52U@mta5.rcsntx.swbell.net> for sip@lists.bell-labs.com; Thu, 8 Jun 2000 11:06:15 -0500 (CDT) Date: Thu, 08 Jun 2000 11:06:15 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net From: zainprov@swbell.net To: sip@lists.bell-labs.com Message-id: <0FVU00DO2FEE2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Subject: [SIP] Shocking LOSE 10-100lbs. DESTINY Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry 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 Jun 8 15:26: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 PAA14920 for ; Thu, 8 Jun 2000 15:26: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 9123B44389; Thu, 8 Jun 2000 15:15:43 -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 8ACC54433A for ; Thu, 8 Jun 2000 15:15: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 PAA16355; Thu, 8 Jun 2000 15:25:45 -0400 (EDT) Message-ID: <393FF339.6A0DF2EB@cs.columbia.edu> Date: Thu, 08 Jun 2000 15:25:45 -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: petri.koskelainen@nokia.com, sip@lists.bell-labs.com References: <25B79E9476BAD211811B0008C7894CDC32B1FD@treis04nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: About Proxy-Supported and Proxy-Unsupported Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 petri.koskelainen@nokia.com wrote: > > What do you think about Proxy-Supported and Proxy-Unsupported > headers to be included into 2543bis ? > > The syntax would be similar to Supported header. > > We will very likely need those (at least Proxy-Supported) in 3G > registration. This isn't quite symmetric to Require. Would proxies add or subtract features from the "Proxy-Supported" and "Proxy-Unsupported" list? (Presumably subtract and add, respectively...) Would only those proxies that are on the record-route be allowed to do this? > > Best Regards, > -- > Petri Koskelainen > Nokia Research Center -- 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 Jun 8 16:14: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 QAA15764 for ; Thu, 8 Jun 2000 16:14: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 2DA2A443F3; Thu, 8 Jun 2000 16:03: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 40AAE4433A for ; Thu, 8 Jun 2000 16:03:56 -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 QAA13178; Thu, 8 Jun 2000 16:15:37 -0400 (EDT) Message-ID: <393FFEB6.56DE9D8A@dynamicsoft.com> Date: Thu, 08 Jun 2000 16:14: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: petri.koskelainen@nokia.com, sip@lists.bell-labs.com Subject: Re: [SIP] Re: About Proxy-Supported and Proxy-Unsupported References: <25B79E9476BAD211811B0008C7894CDC32B1FD@treis04nok> <393FF339.6A0DF2EB@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: > > > We will very likely need those (at least Proxy-Supported) in 3G > > registration. > > This isn't quite symmetric to Require. Would proxies add or subtract > features from the "Proxy-Supported" and "Proxy-Unsupported" list? > (Presumably subtract and add, respectively...) Would only those proxies > that are on the record-route be allowed to do this? We discussed these and other issues in the past on the list (in fact, I posted a note outlining every possible combination of who needs what features from who else); it turned out to be overly complicated, and there were no real applications for it. So, we solved the basic problem which there was a clear need for. You mention some application in 3G registration. Can you elaborate on that? -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 Jun 8 16: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 QAA16669 for ; Thu, 8 Jun 2000 16:56: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 EAED2443C3; Thu, 8 Jun 2000 16:45:42 -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 418754433A for ; Thu, 8 Jun 2000 16:45:40 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FVU00A01ST1KI@firewall.mcit.com> for SIP@lists.bell-labs.com; Thu, 8 Jun 2000 20:55:49 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FVU00A3TST19P@firewall.mcit.com>; Thu, 08 Jun 2000 20:55:49 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0FVU00K01STQHM@dgismtp04.wcomnet.com>; Thu, 08 Jun 2000 20:56:14 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FVU00K01STJGP@dgismtp04.wcomnet.com>; Thu, 08 Jun 2000 20:56:14 +0000 (GMT) Received: from C25776A ([166.37.29.8]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FVU00ENLST92Z@dgismtp04.wcomnet.com>; Thu, 08 Jun 2000 20:55:58 +0000 (GMT) Date: Thu, 08 Jun 2000 15:55:28 -0500 From: Henry Sinnreich Subject: RE: [SIP] Distinctive ringing feature In-reply-to: <652568F8.00193A95.00@sampark.hss.hns.com> To: archow@hss.hns.com, Sekhar Banerjee Cc: SIP@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 Could distinctive ringing be a caller/called preference? Thanks, Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >archow@hss.hns.com >Sent: Wednesday, June 07, 2000 11:36 PM >To: Sekhar Banerjee >Cc: 'SIP@lists.bell-labs.com' >Subject: Re: [SIP] Distinctive ringing feature > > > > >Hi, >you can definetely implement distinctive ringing from >a SIP endpoint. >The distinctive ring implementation is purely an >endpoint side feature (see >SIP FAQ on Henning's site) >and does not need any special SIP signalling. >For example, if say your phone has two alloted phone >numbers - and you want >a different ringing tone depending >on the number the caller dialed - your implementation >would simply see the >phone number from the SIP headers >and generate the appropriate ring for that phone. > > >Regds >Arjun >-- >Arjun Roychowdhury @ Hughes Software Systems > > > > > > >Sekhar Banerjee on 06/08/2000 >02:52:13 AM > >To: "'SIP@lists.bell-labs.com'" >cc: > >Subject: [SIP] Distinctive ringing feature > > > > >Hi, > I would like to know if it would be possible to >use SIP to instruct >the endpoints/UA's to provide different ringing >sequences. If someone has >implemented this feature I would love to know more >about it. I am talking >about the distinctive ringing feature as it is present >in the PSTN network >today. > >Thanks > >Sekhar > > >_______________________________________________ >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 Jun 8 17:15: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 RAA17014 for ; Thu, 8 Jun 2000 17: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 8963444405; Thu, 8 Jun 2000 17:04: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 B0BCC443F1 for ; Thu, 8 Jun 2000 17:04:56 -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 RAA13429; Thu, 8 Jun 2000 17:16:09 -0400 (EDT) Message-ID: <39400CE6.7B55B84E@dynamicsoft.com> Date: Thu, 08 Jun 2000 17:15:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Schroeder, Tim" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] comments on draft-sparks-sip-cc-transfer-00.txt References: <4D45BA2A58A7D3119E050008C7E69E290790F2@trimail2.tri.sbc.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 "Schroeder, Tim" wrote: > > I could maybe contrive some more examples, but these are the two that come > to mind first. I guess if the transferor and the target are un-related, it > doesn't make much difference if the transfer fails because it was tried and > failed, or because it was declined. But in the cases where the transferor > and the target are more tightly coupled (in the same umbrella organization, > perhaps), it does seems to make a difference. The user-to-user session can > proceed differently if the TRANSFER failed because the transferee > declined/balked, or whether the TRANSFER failed despite the agreeableness of > the transferee. > > So, using my numbering scheme, I still like > (1) 400-600-class failure [problem with the TRANSFER request] > (2) 200 OK [transfer attempted and succeeded] > (3) ??? [some response that specifically means transfer attempted but > failed] I would say this is a 500 class response. I believe 500 class responses generally mean, "this request failed this time, but the same request might succeed later on". Thats exactly the case here. You could even include a Retry-After in the response indicating when to try. -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 Jun 8 17:25: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 RAA17182 for ; Thu, 8 Jun 2000 17:25: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 8FA1A44418; Thu, 8 Jun 2000 17:10:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by lists.bell-labs.com (Postfix) with ESMTP id 47EB6443F1 for ; Thu, 8 Jun 2000 17:10:21 -0400 (EDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id 8D42D225C; Thu, 8 Jun 2000 16:20:37 -0500 (CDT) Received: from exchou-gh01.cca.cpqcorp.net (exchou-gh01.cca.cpqcorp.net [16.110.248.201]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 790422035; Thu, 8 Jun 2000 16:20:37 -0500 (CDT) Received: by exchou-gh01.cca.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 16:20:36 -0500 Message-ID: <202F03744BDCD31194270000F803CA9E76FD32@cxoexc2.cxo.dec.com> From: "Maddux, Michel" To: "'Henry Sinnreich'" , archow@hss.hns.com, Sekhar Banerjee Cc: SIP@lists.bell-labs.com Subject: RE: [SIP] Distinctive ringing feature Date: Thu, 8 Jun 2000 16:20:34 -0500 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 Greetings: It occurs to me that this is an exmple of the ability of the called party to establish a personal filter based upon multiple characteristics; e.g. From: list (preference to girlfriend/wife/mother) etc... Alarm tone for inbound solicitors. Isn't this up to the endpoint to supply multiple ring capability? Obvious fun with .wav files include mooing from certain callers, even up to a personalized voice announcment ("Hi honey, it's me. Please pick up.") Sort of changes the whole distinctive ringing concept. Is there any problem with this sort of concept? thanks. /m. > -----Original Message----- > From: Henry Sinnreich [SMTP:Henry.Sinnreich@WCom.com] > Sent: Thursday, June 08, 2000 2:55 PM > To: archow@hss.hns.com; Sekhar Banerjee > Cc: SIP@lists.bell-labs.com > Subject: RE: [SIP] Distinctive ringing feature > > Could distinctive ringing be a caller/called preference? > > Thanks, Henry > > >-----Original Message----- > >From: sip-admin@lists.bell-labs.com > >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of > >archow@hss.hns.com > >Sent: Wednesday, June 07, 2000 11:36 PM > >To: Sekhar Banerjee > >Cc: 'SIP@lists.bell-labs.com' > >Subject: Re: [SIP] Distinctive ringing feature > > > > > > > > > >Hi, > >you can definetely implement distinctive ringing from > >a SIP endpoint. > >The distinctive ring implementation is purely an > >endpoint side feature (see > >SIP FAQ on Henning's site) > >and does not need any special SIP signalling. > >For example, if say your phone has two alloted phone > >numbers - and you want > >a different ringing tone depending > >on the number the caller dialed - your implementation > >would simply see the > >phone number from the SIP headers > >and generate the appropriate ring for that phone. > > > > > >Regds > >Arjun > >-- > >Arjun Roychowdhury @ Hughes Software Systems > > > > > > > > > > > > > >Sekhar Banerjee on 06/08/2000 > >02:52:13 AM > > > >To: "'SIP@lists.bell-labs.com'" > >cc: > > > >Subject: [SIP] Distinctive ringing feature > > > > > > > > > >Hi, > > I would like to know if it would be possible to > >use SIP to instruct > >the endpoints/UA's to provide different ringing > >sequences. If someone has > >implemented this feature I would love to know more > >about it. I am talking > >about the distinctive ringing feature as it is present > >in the PSTN network > >today. > > > >Thanks > > > >Sekhar > > > > > >_______________________________________________ > >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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 17:31: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 RAA17299 for ; Thu, 8 Jun 2000 17:31: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 BFD7B4441C; Thu, 8 Jun 2000 17:17:53 -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 3A8B1443EA for ; Thu, 8 Jun 2000 17:17:50 -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 RAA13498; Thu, 8 Jun 2000 17:29:32 -0400 (EDT) Message-ID: <39401009.CB1DCD4A@dynamicsoft.com> Date: Thu, 08 Jun 2000 17:28:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Maddux, Michel" Cc: "'Henry Sinnreich'" , archow@hss.hns.com, Sekhar Banerjee , SIP@lists.bell-labs.com Subject: Re: [SIP] Distinctive ringing feature References: <202F03744BDCD31194270000F803CA9E76FD32@cxoexc2.cxo.dec.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 "Maddux, Michel" wrote: > > Greetings: > > It occurs to me that this is an exmple of the ability of the called party to > establish a personal filter based upon multiple characteristics; e.g. From: > list (preference to girlfriend/wife/mother) etc... Alarm tone for inbound > solicitors. Isn't > this up to the endpoint to supply multiple ring capability? Obvious fun > with .wav files include mooing from certain callers, > even up to a personalized voice announcment ("Hi honey, it's me. Please > pick up.") Sort of changes the whole distinctive ringing concept. > > Is there any problem with this sort of concept? thanks. /m. No problem at all. Thats what people have been saying by "its a matter of local implementation." What you describe is the approach supported in the SIP model. -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 Jun 8 17:39: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 RAA17444 for ; Thu, 8 Jun 2000 17:39: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 B656B443EA; Thu, 8 Jun 2000 17:26:13 -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 123CD4433A for ; Thu, 8 Jun 2000 17:26:11 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FVU00A01UOUZ0@firewall.mcit.com> for SIP@lists.bell-labs.com; Thu, 8 Jun 2000 21:36:30 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FVU00920UOULC@firewall.mcit.com>; Thu, 08 Jun 2000 21:36:30 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FVU00L01UMZGL@pmismtp03.wcomnet.com>; Thu, 08 Jun 2000 21:35:23 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVU00L01UMYGF@pmismtp03.wcomnet.com>; Thu, 08 Jun 2000 21:35:23 +0000 (GMT) Received: from C25776A ([166.37.29.8]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVU00I9LUMIOW@pmismtp03.wcomnet.com>; Thu, 08 Jun 2000 21:35:08 +0000 (GMT) Date: Thu, 08 Jun 2000 16:36:10 -0500 From: Henry Sinnreich Subject: RE: [SIP] Distinctive ringing feature In-reply-to: <202F03744BDCD31194270000F803CA9E76FD32@cxoexc2.cxo.dec.com> To: "Maddux, Michel" , archow@hss.hns.com, Sekhar Banerjee Cc: SIP@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 >>Is there any problem with this sort of concept? thanks. /m. Thought the same , but wanted some confirmation. Thanks, Henry >-----Original Message----- >From: Maddux, Michel [mailto:Michel.Maddux@COMPAQ.com] >Sent: Thursday, June 08, 2000 4:21 PM >To: 'Henry Sinnreich'; archow@hss.hns.com; Sekhar Banerjee >Cc: SIP@lists.bell-labs.com >Subject: RE: [SIP] Distinctive ringing feature > > >Greetings: > >It occurs to me that this is an exmple of the ability >of the called party to >establish a personal filter based upon multiple >characteristics; e.g. From: >list (preference to girlfriend/wife/mother) etc... >Alarm tone for inbound >solicitors. Isn't >this up to the endpoint to supply multiple ring >capability? Obvious fun >with .wav files include mooing from certain callers, >even up to a personalized voice announcment ("Hi >honey, it's me. Please >pick up.") Sort of changes the whole distinctive >ringing concept. > >Is there any problem with this sort of concept? thanks. /m. > >> -----Original Message----- >> From: Henry Sinnreich [SMTP:Henry.Sinnreich@WCom.com] >> Sent: Thursday, June 08, 2000 2:55 PM >> To: archow@hss.hns.com; Sekhar Banerjee >> Cc: SIP@lists.bell-labs.com >> Subject: RE: [SIP] Distinctive ringing feature >> >> Could distinctive ringing be a caller/called preference? >> >> Thanks, Henry >> >> >-----Original Message----- >> >From: sip-admin@lists.bell-labs.com >> >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >> >archow@hss.hns.com >> >Sent: Wednesday, June 07, 2000 11:36 PM >> >To: Sekhar Banerjee >> >Cc: 'SIP@lists.bell-labs.com' >> >Subject: Re: [SIP] Distinctive ringing feature >> > >> > >> > >> > >> >Hi, >> >you can definetely implement distinctive ringing from >> >a SIP endpoint. >> >The distinctive ring implementation is purely an >> >endpoint side feature (see >> >SIP FAQ on Henning's site) >> >and does not need any special SIP signalling. >> >For example, if say your phone has two alloted phone >> >numbers - and you want >> >a different ringing tone depending >> >on the number the caller dialed - your implementation >> >would simply see the >> >phone number from the SIP headers >> >and generate the appropriate ring for that phone. >> > >> > >> >Regds >> >Arjun >> >-- >> >Arjun Roychowdhury @ Hughes Software Systems >> > >> > >> > >> > >> > >> > >> >Sekhar Banerjee on 06/08/2000 >> >02:52:13 AM >> > >> >To: "'SIP@lists.bell-labs.com'" >> >cc: >> > >> >Subject: [SIP] Distinctive ringing feature >> > >> > >> > >> > >> >Hi, >> > I would like to know if it would be possible to >> >use SIP to instruct >> >the endpoints/UA's to provide different ringing >> >sequences. If someone has >> >implemented this feature I would love to know more >> >about it. I am talking >> >about the distinctive ringing feature as it is present >> >in the PSTN network >> >today. >> > >> >Thanks >> > >> >Sekhar >> > >> > >> >_______________________________________________ >> >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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 18:07: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 SAA17928 for ; Thu, 8 Jun 2000 18:07: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 B285A44427; Thu, 8 Jun 2000 17:28:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lists.bell-labs.com (Postfix) with ESMTP id 03C224433A for ; Thu, 8 Jun 2000 17:28:35 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id B23634DC; Thu, 8 Jun 2000 16:38:54 -0500 (CDT) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id A2B521AE; Thu, 8 Jun 2000 16:38:54 -0500 (CDT) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 16:38:54 -0500 Message-ID: <202F03744BDCD31194270000F803CA9E76FD33@cxoexc2.cxo.dec.com> From: "Maddux, Michel" To: "'Henry Sinnreich'" , archow@hss.hns.com, Sekhar Banerjee Cc: SIP@lists.bell-labs.com Subject: RE: [SIP] Distinctive ringing feature Date: Thu, 8 Jun 2000 16:38:50 -0500 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 Actually, having the phone moo when mother in law calls might be the next killer app. ;^) /m. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 18:17: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 SAA18053 for ; Thu, 8 Jun 2000 18:17: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 0335444431; Thu, 8 Jun 2000 17:31:39 -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 326184442C for ; Thu, 8 Jun 2000 17:31:36 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FVU00E01UXVEB@firewall.mcit.com> for SIP@lists.bell-labs.com; Thu, 8 Jun 2000 21:41:55 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FVU006EGUXVAQ@firewall.mcit.com>; Thu, 08 Jun 2000 21:41:55 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FVU00001UW07Y@pmismtp03.wcomnet.com>; Thu, 08 Jun 2000 21:40:48 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVU00001UVX7N@pmismtp03.wcomnet.com>; Thu, 08 Jun 2000 21:40:47 +0000 (GMT) Received: from C25776A ([166.37.29.8]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVU00IG1UVNOY@pmismtp03.wcomnet.com>; Thu, 08 Jun 2000 21:40:36 +0000 (GMT) Date: Thu, 08 Jun 2000 16:41:37 -0500 From: Henry Sinnreich In-reply-to: <39401009.CB1DCD4A@dynamicsoft.com> To: Henry.Sinnreich@WCom.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [SIP] SIP at Supercomm2000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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.infoworld.com/articles/hn/xml/00/06/06/000606hnworldc om.xml Enjoy! Henry _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 8 18:50: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 SAA18513 for ; Thu, 8 Jun 2000 18:50: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 AB8824441A; Thu, 8 Jun 2000 18:37:43 -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 35E2A44416 for ; Thu, 8 Jun 2000 18:37:41 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 8 18:46:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C9E0C44344; Thu, 8 Jun 2000 18:33:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9750F44341 for ; Thu, 8 Jun 2000 18:33:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7340652C4; Thu, 8 Jun 2000 18:33:21 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9CB2252AB for ; Thu, 8 Jun 2000 18:33:18 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 8 18:31:17 EDT 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Jun 8 18:31:16 EDT 2000 Received: from vovida.com (a98.vovida.com [209.237.8.98] (may be forged)) by repulse.cnchost.com id SAA20137; Thu, 8 Jun 2000 18:31:12 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <39401EAF.B5544846@vovida.com> Date: Thu, 08 Jun 2000 15:31:11 -0700 From: Krishan Veer Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Reg: SipUrl Grammmer Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 everyone! Can some explain me with example about the grammer in SipUrl; hostname= *(domainlabel".")toplabel["."] domainlabel & toplabel correct usage examples ? thanks -- Krishan veer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 9 00: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 AAA23735 for ; Fri, 9 Jun 2000 00:20: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 85B2A443E3; Fri, 9 Jun 2000 00:09:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id 22C804433A for ; Fri, 9 Jun 2000 00:07:59 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA25879; Fri, 9 Jun 2000 10:33:41 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568F9.00182BD2 ; Fri, 9 Jun 2000 09:54:00 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Henry Sinnreich Cc: archow@hss.hns.com, Sekhar Banerjee , SIP@lists.bell-labs.com Message-ID: <652568F9.00182AD9.00@sampark.hss.hns.com> Date: Fri, 9 Jun 2000 09:53:57 +0530 Subject: RE: [SIP] Distinctive ringing feature 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 why not ? :-) lots of interesting things can be put in. Since this is totally a client side implemenation that does not affect the SIP signalling in any way, we also did some cute(?!?) things like the ring volume being dynamically modulated as duration of ring increases etc (you know, like those alarms clocks that start with a whisper and keep screaming louder and louder (till a point) till you hit on the button.... On the lighter side - here's some rings my limited imagination brings up: Girl/BoyFriend Ring - sweet chimes (or doomsday bongs - depending on what state you are with her/him) Beer pal ring - hic..hic...ring.ring...hic..hic Boss Ring - no ring :-p Wife Ring - continuous monotonic ring :-)) etc...... Oh well :-) Back to work - I enjoyed keying in this mail :-p Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Technical Leader, VOIP Solutions Off: Prestige Opal,146 Infantry Road,Blore - 560001 Ph:+91-080-2286390/1/2 Res: 68/G 2nd Narayanappa Block, RT Nagar,Blore - 560032 Ph:3430565 http://arjun.cjb.net Henry Sinnreich on 06/09/2000 02:25:28 AM To: archow, Sekhar Banerjee cc: SIP@lists.bell-labs.com Subject: RE: [SIP] Distinctive ringing feature Could distinctive ringing be a caller/called preference? Thanks, Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >archow@hss.hns.com >Sent: Wednesday, June 07, 2000 11:36 PM >To: Sekhar Banerjee >Cc: 'SIP@lists.bell-labs.com' >Subject: Re: [SIP] Distinctive ringing feature > > > > >Hi, >you can definetely implement distinctive ringing from >a SIP endpoint. >The distinctive ring implementation is purely an >endpoint side feature (see >SIP FAQ on Henning's site) >and does not need any special SIP signalling. >For example, if say your phone has two alloted phone >numbers - and you want >a different ringing tone depending >on the number the caller dialed - your implementation >would simply see the >phone number from the SIP headers >and generate the appropriate ring for that phone. > > >Regds >Arjun >-- >Arjun Roychowdhury @ Hughes Software Systems > > > > > > >Sekhar Banerjee on 06/08/2000 >02:52:13 AM > >To: "'SIP@lists.bell-labs.com'" >cc: > >Subject: [SIP] Distinctive ringing feature > > > > >Hi, > I would like to know if it would be possible to >use SIP to instruct >the endpoints/UA's to provide different ringing >sequences. If someone has >implemented this feature I would love to know more >about it. I am talking >about the distinctive ringing feature as it is present >in the PSTN network >today. > >Thanks > >Sekhar > > >_______________________________________________ >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 Jun 9 01:42: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 BAA29405 for ; Fri, 9 Jun 2000 01:42: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 03E06443F7; Fri, 9 Jun 2000 01:31:42 -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 1655E4433A for ; Fri, 9 Jun 2000 01:31:39 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 9 01:40:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9CCDD44344; Fri, 9 Jun 2000 01:27:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 6CC3E44341 for ; Fri, 9 Jun 2000 01:27:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2A07952C4; Fri, 9 Jun 2000 01:27:20 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 5B99A52B6 for ; Fri, 9 Jun 2000 01:27:17 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Jun 9 01:25:11 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Fri Jun 9 01:25:10 EDT 2000 Received: from dynamicsoft.com (1Cust98.tnt1.long-branch.nj.da.uu.net [63.25.225.98]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14058; Fri, 9 Jun 2000 01:26:28 -0400 (EDT) Message-ID: <39408094.ADB9B93F@dynamicsoft.com> Date: Fri, 09 Jun 2000 01:28:52 -0400 From: Igor Slepchin X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Krishan Veer Cc: sip Subject: Re: [SIP] Reg: SipUrl Grammmer References: <39401EAF.B5544846@vovida.com> 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 vovida.com would be an example of a host name complying with the BNF:) Just in case: vovida is a domainlabel, com is a toplabel. --- Igor Slepchin Krishan Veer wrote: > > Hi everyone! > > Can some explain me with example about the grammer in SipUrl; > hostname= *(domainlabel".")toplabel["."] > > domainlabel & toplabel correct usage examples ? > > thanks > -- > Krishan veer > > _______________________________________________ > 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 Jun 9 04:50: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 EAA07707 for ; Fri, 9 Jun 2000 04:50: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 6D7DF443B1; Fri, 9 Jun 2000 04:39:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6DC6044339 for ; Fri, 9 Jun 2000 04:39:09 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id OAA06044 for ; Fri, 9 Jun 2000 14:17:27 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 09 Jun 2000 12:17:15 +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 MAA27966 for ; Fri, 9 Jun 2000 12:17:11 +0530 (IST) Message-ID: <009c01bfd1dd$60ed3840$8c40000a@sasi.com> From: "rafi" To: References: <25B79E9476BAD211811B0008C7894CDC32B1FD@treis04nok> <393FF339.6A0DF2EB@cs.columbia.edu> Date: Fri, 9 Jun 2000 12:08:53 +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 Subject: [SIP] [SIP]: Caching of Final Response(s) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 the following paragraph in RFC 2543, section 10.4.1 ....... the server sends a final response, it cannot be sure the client has received the response, and thus SHOULD cache the results for at least 10*T2 seconds to avoid having to, for example, contact the user or location server again upon receiving a request retransmission. Now consider the following scenarios. Scenario 1 : Consider a UAS supporting many calls (each call's media stream may terminate at different IP address). If server caches the final response then in worst case server may be caching all the responses almost at same time. This caching may cause the server run out of buffer space thereby preventing the server from serving new requests. Scenario 2: Consider a misbehaved client which is sending request in such way that each time it sends a request it challenges the server to send final response. Client can quickly make the server run out of buffer space and bring down its operation. Any comment are welcome. Thank You Rafi Assadi H.M. Silicon Automation Systems Bangalore, INDIA. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 9 06:06: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 GAA08125 for ; Fri, 9 Jun 2000 06:06: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 2FC5944400; Fri, 9 Jun 2000 05:54:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id D1D4844339 for ; Fri, 9 Jun 2000 05:54:37 -0400 (EDT) Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id QAA18724; Fri, 9 Jun 2000 16:21:35 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 652568F9.00368AF3 ; Fri, 9 Jun 2000 15:25:45 +0530 X-Lotus-FromDomain: HSS From: dmalhotra@hss.hns.com To: "rafi" , sip@lists.bell-labs.com Message-ID: <652568F9.00368A14.00@sandesh.hss.hns.com> Date: Fri, 9 Jun 2000 15:34:47 +0530 Subject: Re: [SIP] [SIP]: Caching of Final Response(s) 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 Rafi, In scenario 1, you are right that if multiple responses are cached then the server may go out of buffer space but I have a point here that all the calls do not appear simultaneously generally they have some pattern and even if it is not there then the implementation can put a limit on the number of simultaneous calls for which it will support caching. After that it may not support the caching and may release the call or whatever specific action it wants to take. As far as the scenario 2 is concerned, You have probably missed one point that server is going to keep this info maximum upto 10*T2 seconds. T2 being 4 seconds so worst case it is 40 seconds. Regards Dhiraj Malhotra "rafi" on 06/09/2000 12:08:53 PM To: sip@lists.bell-labs.com cc: (bcc: Dhiraj Malhotra/HSS) Subject: [SIP] [SIP]: Caching of Final Response(s) Hi, Consider the following paragraph in RFC 2543, section 10.4.1 ....... the server sends a final response, it cannot be sure the client has received the response, and thus SHOULD cache the results for at least 10*T2 seconds to avoid having to, for example, contact the user or location server again upon receiving a request retransmission. Now consider the following scenarios. Scenario 1 : Consider a UAS supporting many calls (each call's media stream may terminate at different IP address). If server caches the final response then in worst case server may be caching all the responses almost at same time. This caching may cause the server run out of buffer space thereby preventing the server from serving new requests. Scenario 2: Consider a misbehaved client which is sending request in such way that each time it sends a request it challenges the server to send final response. Client can quickly make the server run out of buffer space and bring down its operation. Any comment are welcome. Thank You Rafi Assadi H.M. Silicon Automation Systems Bangalore, INDIA. _______________________________________________ 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 Jun 9 06: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 GAA08321 for ; Fri, 9 Jun 2000 06: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 3544244411; Fri, 9 Jun 2000 06:41:47 -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 5B6EC44339 for ; Fri, 9 Jun 2000 06:41:42 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 9 06:51:30 EDT 2000 Received: by lists.bell-labs.com (Postfix) id F24B044341; Fri, 9 Jun 2000 06:25:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id BEFB944345 for ; Fri, 9 Jun 2000 06:25:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A414A52AB; Fri, 9 Jun 2000 06:25:22 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6CECC52C4 for ; Fri, 9 Jun 2000 06:25:19 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jun 9 06:24:52 EDT 2000 Received: from smtp2.cluster.oleane.net ([195.25.12.17]) by dusty; Fri Jun 9 06:24:52 EDT 2000 Received: from oleane (dyn-1-2-224.Vin.dialup.oleane.fr [194.2.4.224]) by smtp2.cluster.oleane.net with SMTP id MAA11054 for ; Fri, 9 Jun 2000 12:25:27 +0200 (CEST) Message-ID: <005c01bfd1fc$bac500e0$7501a8c0@oleane.oleane.com> From: "Peter Lewis" To: Date: Fri, 9 Jun 2000 12:23:17 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01BFD20D.7DAD9940" 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] MGC CALL FOR PAPER Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_0059_01BFD20D.7DAD9940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MGCP/Megaco Conference 14 to 17 November 2000. Second edition: = deployment experiences, operational issues, interoperability status. Please get more details on the call for papers online: http://www.upperside.fr/bamgc2yk.htm ------=_NextPart_000_0059_01BFD20D.7DAD9940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
MGCP/Megaco Conference 14 to 17 = November 2000.=20 Second edition: deployment experiences, operational issues, = interoperability=20 status.
Please get = more details on=20 the call for papers online:
http://www.upperside.fr/bam= gc2yk.htm
------=_NextPart_000_0059_01BFD20D.7DAD9940-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 9 07:32: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 HAA08843 for ; Fri, 9 Jun 2000 07:32: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 CD9ED4436E; Fri, 9 Jun 2000 07:20:59 -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 9DAAB44339 for ; Fri, 9 Jun 2000 07:20:56 -0400 (EDT) Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id OAA04888; Fri, 9 Jun 2000 14:30:49 +0300 (EETDST) From: petri.koskelainen@nokia.com Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id OAA25404; Fri, 9 Jun 2000 14:30:39 +0300 (EETDST) Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Fri, 9 Jun 2000 14:30:33 +0300 Message-ID: <25B79E9476BAD211811B0008C7894CDC02F794CB@treis04nok> To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Cc: petri.koskelainen@nokia.com, sip@lists.bell-labs.com Subject: RE: [SIP] Re: About Proxy-Supported and Proxy-Unsupported Date: Fri, 9 Jun 2000 14:30:20 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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, > > This isn't quite symmetric to Require. Would proxies add or subtract > > features from the "Proxy-Supported" and "Proxy-Unsupported" list? > > (Presumably subtract and add, respectively...) Would only > those proxies > > that are on the record-route be allowed to do this? > > We discussed these and other issues in the past on the list > (in fact, I > posted a note outlining every possible combination of who needs what > features from who else); it turned out to be overly complicated, and > there were no real applications for it. So, we solved the > basic problem > which there was a clear need for. > > You mention some application in 3G registration. Can you elaborate on > that? > > -Jonathan R. I have been thinking that problem also. Initially, the idea behind Proxy-Supported was that only one proxy (in the visited network) describes the capabilites available in the visited domain (capabilities specific to 3G) and that REGISTER message is then forwarded into the home network. Other proxies should not be allowed to touch the Proxy-Supported header. If Proxy-Supported/UnSupported are used to describe the capabilities of several SIP proxies along the route, then subtract/add should be applied by each proxy (but then we end up with problems, e.g. proxies in different domains can not be trusted as much as local proxies etc). Maybe the name of the proposed Proxy-Supported header should be changed to something like "Local-Proxy-Capabilities", or "3G-local-capabilities". -- Petri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 9 08:03: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 IAA09390 for ; Fri, 9 Jun 2000 08:03: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 2851844433; Fri, 9 Jun 2000 07:36:33 -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 6FC1E44429 for ; Fri, 9 Jun 2000 07:36:30 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id GAA13991; Fri, 9 Jun 2000 06:46:46 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id GAA05483; Fri, 9 Jun 2000 06:46:45 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id GAA18855; Fri, 9 Jun 2000 06:46:45 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id GAA01579; Fri, 9 Jun 2000 06:46:45 -0500 (CDT) Message-Id: <200006091146.GAA01579@b04a24.exu.ericsson.se> Subject: Re: [SIP] Re: About Proxy-Supported and Proxy-Unsupported To: petri.koskelainen@nokia.com Date: Fri, 9 Jun 2000 06:46:45 -0500 (CDT) Cc: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, sip@lists.bell-labs.com In-Reply-To: <25B79E9476BAD211811B0008C7894CDC02F794CB@treis04nok> from "petri.koskelainen@nokia.com" at Jun 09, 2000 02:30:20 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 Proxy-Supported/UnSupported are used to describe the capabilities of >several >SIP proxies along the route, then subtract/add should be applied >by each proxy (but then we end up with problems, e.g. proxies in >different domains can not be trusted as much as local proxies etc). > >Maybe the name of the proposed Proxy-Supported header should be changed >to something like "Local-Proxy-Capabilities", or "3G-local-capabilities". Perhaps. I beleive you're a bit confused about the semantics of the Supported: header. It is used to denote that certain SIP extension drafts are supported, not capability sets within a service architecture. For example, you may want to define an extension (the name of which would go in the "Supported" header) which defines how to negotiate the version of a service triggering protocol (this information would go in a new header defined by the above mentioned extension draft). You can't really mix the ideas. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 9 11:13: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 LAA12821 for ; Fri, 9 Jun 2000 11:13: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 C58824433F; Fri, 9 Jun 2000 11:01:42 -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 63F1F44336 for ; Fri, 9 Jun 2000 11:01:37 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 9 11:10:21 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7E6A244344; Fri, 9 Jun 2000 10:57:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 535C744341 for ; Fri, 9 Jun 2000 10:57:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id F3DBD52C8; Fri, 9 Jun 2000 10:57:22 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6CEFD52AB for ; Fri, 9 Jun 2000 10:57:18 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jun 9 10:55:48 EDT 2000 Received: from mail-green.research.att.com ([135.207.30.103]) by dusty; Fri Jun 9 10:55:47 EDT 2000 Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id E7EF71E00A for ; Fri, 9 Jun 2000 10:55:46 -0400 (EDT) Received: from research.att.com (fpdhcp073.research.att.com [135.207.28.73]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id KAA20037 for ; Fri, 9 Jun 2000 10:55:41 -0400 (EDT) Message-ID: <3941043F.544B393F@research.att.com> Date: Fri, 09 Jun 2000 10:50:39 -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.research.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] 3rd CFP (EXTENDED DEADLINE): IP Telecom Services Workshop 2000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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.] ------------- THIRD CALL FOR PAPERS --------------- ------------- EXTENDED DEADLINE --------------- 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 submission deadline: June 23, 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. The IPTS 2000 Program Committee invites submission of papers on substantial, original and previously unpublished research in IP telecom services, including, but not limited to: - service architectures (e.g. AIN, SoftSwitch, JAIN, Parlay, DFC) - service creation environments - protocols, standards and interoperability (e.g. H.323, SIP, MGCP, Megaco/H.248, etc.) - service programming languages - service management - billing, fault tolerance, monitoring - novel services We welcome papers describing original research; position papers describing research interests in the field, work in progress, or future directions of research; project or system descriptions. IMPORTANT DATES June 23, 2000 Submission deadline July 21, 2000 Notification of acceptance August 25, 2000 Final version of papers September 11, 2000 IPTS 2000 PAPER SUBMISSIONS Papers must describe original, previously unpublished work that has not been simultaneously submitted for publication elsewhere. They must be written in English, not exceeding 6 pages including figures, tables and references in 10-12 point font on 8.5x11-inch (US letter) paper. The first page must include an abstract of up to 200 words, keywords, and email address of the corresponding author. All papers must be submitted electronically unless specifically approved by the Workshop Co-Chairs. Submissions in PostScript or PDF format should be sent to mailto:ipts2000@research.att.com. Authors of accepted papers are expected to present their contribution at the workshop. The proceedings will be published in hardcopy and on the web. REVIEW PROCEDURE All submissions will be subject to academic peer review by the IPTS 2000 Program Committee under the chairmanship of the Workshop Co-Chairs. Each paper will receive three written reviews, and reviews will be returned to the authors. The Workshop Co-Chairs have final authority over the review process and all decisions relating to acceptance of papers. Review criteria include originality of ideas, technical soundness, significance of results, and quality of presentation. CONFERENCE VENUE AND RELATED EVENTS 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). Details about Fall 2000 VON can be found at http://pulver.com. 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 Jun 9 11:45: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 LAA13482 for ; Fri, 9 Jun 2000 11:45: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 3240944340; Fri, 9 Jun 2000 11:34:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id 3955E44336 for ; Fri, 9 Jun 2000 11:34:44 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 59D824CE28 for ; Fri, 9 Jun 2000 11:45:10 -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 LAA05896 for ; Fri, 9 Jun 2000 11:45:09 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id LAA86765 for sip@lists.bell-labs.com; Fri, 9 Jun 2000 11:44:32 -0400 (EDT) Date: Fri, 9 Jun 2000 11:44:32 -0400 (EDT) Message-Id: <200006091544.LAA86765@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: [SIP] updated manyfolks 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 I have submitted an updated version of the 'manyfolks' draft on resource preconditions for SIP sessions. Until it appears in the normal ietf directories, it may be obtained from ftp://ftp.research.att.com/dist/wtm/draft-manyfolks-sip-resource-01.txt The most important change in this version of the draft is the full compliance with Section 10 of RFC 2026. This also incorporates all the comments received in Adelaide, and on the email list subsequent to the last IETF meeting. The PacketCable DCS group has produced an updated specification incorporating all of the draft-dcsgroup-* extensions. It provides numerous detailed call flow examples, and message-by- message requirements and test sequences for DCS clients and proxies. A copy of the latest DCS document is available at http://www.softarmor.com/sipwg/drafts/dcsdraft2.pdf and also available at ftp://ftp.cablelabs.com/pub/ietfdocs/dcsdraft2.pdf 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 Fri Jun 9 15:43: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 PAA18062 for ; Fri, 9 Jun 2000 15:43: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 53F1D44349; Fri, 9 Jun 2000 15:31:40 -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 7269744336 for ; Fri, 9 Jun 2000 15:31:34 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Jun 9 15:40:02 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0BBA344346; Fri, 9 Jun 2000 15:26:53 -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 A0FD744345; Fri, 9 Jun 2000 15:26:52 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA02557; Fri, 9 Jun 2000 14:26:48 -0500 Cc: Lawrence Conroy , pint@lists.research.bell-labs.com, SPIRITS list Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA02553; Fri, 9 Jun 2000 14:26:47 -0500 Message-ID: <39414575.C030AC3C@lucent.com> Date: Fri, 09 Jun 2000 14:28:53 -0500 From: Alec Brusilovsky X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: sip@lists.bell-labs.com Original-CC: Lawrence Conroy , pint@lists.research.bell-labs.com, SPIRITS list References: Content-Type: multipart/mixed; boundary="------------47E8D138D00E5CB71F3B136B" Subject: [SIP] Re: [PINT] UDP support changed from SHOULD to MUST Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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. --------------47E8D138D00E5CB71F3B136B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please see my comments inline. Regards, Alec Lawrence Conroy wrote: > * UDP support changed from SHOULD to MUST in SIP 2453 bis draft. > It looks like support for UDP is gradually moving from a SHOULD to a > MUST in SIP. > > In PINT we may not have that assumption. We can have a good reason > for using TCP only (inline content, security using TLS, ...), so *for > PINT* I'd prefer to leave this as a SHOULD. > I would like to add to what Lawrence is saying that some SIP applications might need a more flexible and rapid session set up than others. PINT is a good example, SPIRITS might as well be another one, assuming that the WG will decide to use SIP. > > I wonder if the move to a MUST in the core spec will cause grief for > any other extension or application. > > The key point here is ->in the core spec<- Looks like the core spec. needs to be more accommodating to the needs of extensions (PINT). SHOULD is just fine. Why break something that actually works? > > > I had the same feeling at the Interim meeting in D.C. when the > subject of "Busy Line Verification" was raised - there's a lot of > focus on VoIP, when I can easily imagine SIP being used for a much > wider set of applications even for "straight" conferences; for > example, Quake, as Dean suggests. > Let's imagine an Operator listening in on the sampled Quake audio > track that I'm conferencing. How long before the Police arrive? An > over-emphasis on VoIP can lead to bad assumptions, IMHO - SIP is much > wider than that. > -- > lwc@roke.co.uk -- +44 1794 833666 > ------------------------------------------------------------- > Herewith a pointless waste of a few lines, stating that > Roke Manor Research Limited is NOT responsible for my rantings > and that they would very much like people to sue me rather than > them if this email contains racist or sexist comments, please. > Also, I can't do anything; only our lawyers can, so speak to them. > Oh, and by the way, if our I.T. department has so mangled our > email system that this has been misdirected, beware that having > read this far, your eyes are about to fall out from reading > this highly sensitive information, unless you immediately > forget that this ever darkened your mailbox. Do it now. > ------------------------------------------------------------- > > _______________________________________________ > PINT mailing list > PINT@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/pint --------------47E8D138D00E5CB71F3B136B Content-Type: text/x-vcard; charset=us-ascii; name="abrusilovsky.vcf" Content-Description: Card for Alec Brusilovsky Content-Disposition: attachment; filename="abrusilovsky.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Brusilovsky;Alec tel;fax:+1 630 713 5840 tel;work:+1 630 713 8401 x-mozilla-html:FALSE org:Lucent (jg7290000) version:2.1 email;internet:abrusilovsky@lucent.com title:MTS adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S x-mozilla-cpt:;-29888 fn:Alec Brusilovsky end:vcard --------------47E8D138D00E5CB71F3B136B-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jun 10 00:29: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 AAA24267 for ; Sat, 10 Jun 2000 00: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 957184433D; Sat, 10 Jun 2000 00:18: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 5616144336; Sat, 10 Jun 2000 00:18:11 -0400 (EDT) Received: from dynamicsoft.com (1Cust37.tnt2.freehold.nj.da.uu.net [63.17.114.37]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA17842; Sat, 10 Jun 2000 00:29:50 -0400 (EDT) Message-ID: <3941C415.C9995130@dynamicsoft.com> Date: Sat, 10 Jun 2000 00:29:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alec Brusilovsky Cc: sip@lists.bell-labs.com, Lawrence Conroy , pint@lists.research.bell-labs.com, SPIRITS list Subject: Re: [SIP] Re: [PINT] UDP support changed from SHOULD to MUST References: <39414575.C030AC3C@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 Alec Brusilovsky wrote: > > Please see my comments inline. > > Regards, > Alec > > Lawrence Conroy wrote: > > > * UDP support changed from SHOULD to MUST in SIP 2453 bis draft. > > It looks like support for UDP is gradually moving from a SHOULD to a > > MUST in SIP. > > > > In PINT we may not have that assumption. We can have a good reason > > for using TCP only (inline content, security using TLS, ...), so *for > > PINT* I'd prefer to leave this as a SHOULD. > > > > I would like to add to what Lawrence is saying that some SIP applications > might need a more flexible and rapid session set up than others. PINT is a > good example, SPIRITS might as well be another one, assuming that the WG > will decide to use SIP. Right; both UDP and TCP are still there. You can still do TCP if you want, or just UDP, but just not ONLY TCP. > > > > > I wonder if the move to a MUST in the core spec will cause grief for > > any other extension or application. > > > > The key point here is ->in the core spec<- > > Looks like the core spec. needs to be more accommodating to the needs of > extensions (PINT). SHOULD is just fine. Why break something that actually > works? Because it doesn't - thats the problem. UA to UA interoperability is not possible in all cases unless there is a baseline transport. The "core spec" must be a workable protocol in its own right, without clarifications and specifics being defined only in extensions, as pint 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 Sat Jun 10 01:41: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 BAA29518 for ; Sat, 10 Jun 2000 01: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 8BABC4433F; Sat, 10 Jun 2000 01:31: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 1999444336 for ; Sat, 10 Jun 2000 01:31:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust37.tnt2.freehold.nj.da.uu.net [63.17.114.37]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA17871; Sat, 10 Jun 2000 01:43:06 -0400 (EDT) Message-ID: <3941D540.9033D813@dynamicsoft.com> Date: Sat, 10 Jun 2000 01:42:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Oran Cc: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Proposal for providing additional error information to UACs 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 Oran wrote: > > The body approach does seem themost flexible, but it also is the > heaviest-weight. The way I see this used it's likely to be a proxy which > inserts the information and I don't relish having to write proxy code that > tears apart and re-constructs a MIME multi-part body to add this > information. > > We'd probably also need some MIME notation to indicate what the purpose of > the body part was, at least via conventions documented somewhere. > > I'm on the fence on this one, like Jonathan. Any suggestions how to reach > closure? Well, one way would be to move the pros/cons from theory to something concrete. Can anyone come up with an example where using Contact would cause something to go wrong somewhere? -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 Sat Jun 10 13:03:51 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09695 for ; Sat, 10 Jun 2000 13:03: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 B135044348; Sat, 10 Jun 2000 12:52:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by lists.bell-labs.com (Postfix) with ESMTP id 8FB7544336 for ; Sat, 10 Jun 2000 12:52:03 -0400 (EDT) Received: from MATT.ascend.com (ts024d29.lap-ca.concentric.net [64.1.213.185]) by renown.cnchost.com id NAA24492; Sat, 10 Jun 2000 13:02:35 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-Id: <4.3.1.2.20000609095844.00bb95d0@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 09 Jun 2000 10:02:34 -0700 To: "Dave Oran" From: Matt Holdrege Subject: Re: [SIP] Porposal for providing additional error information to UACs Cc: "IETF SIP WG" 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 04:13 PM 6/6/00 -0400, Dave Oran wrote: >One idea I find rather appealing is to allow a Contact header on any >response (not just redirects) and use that to point the UAC via a URL to >some kind of server which can give more feedback about the error. Servers >might include an RTSP server, a fancy speech synthesizer with computed >content, or just an ftp: url to an audio file. So, for example, you could >do: This is a great idea. I can see how implementers would have had specialized hooks in their phones to do this anyway. That would have led to a lot of user confusion and complaints of too much complexity with SIP phones. This makes things easy and perhaps more important even for everyone by allowing for it in the protocol. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jun 11 19:24: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 TAA10140 for ; Sun, 11 Jun 2000 19:24: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 79C9E44357; Sun, 11 Jun 2000 19:12:51 -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 1D5154433D for ; Sun, 11 Jun 2000 19:12:47 -0400 (EDT) Received: from cisco.com (rtp-dial-1-128.cisco.com [10.83.97.128]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id QAA20450; Sun, 11 Jun 2000 16:23:29 -0700 (PDT) Message-ID: <39442037.7A577919@cisco.com> Date: Sun, 11 Jun 2000 19:26:47 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Flemming Andreasen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] DCS privacy update - open 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 X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Having cleared the RFC 2026 issues, I'm in the process of updating the dcs-privacy draft (draft-dcsgroup-sip-privacy-01.txt) based on the comments received in Adelaide, but would like some list discussion on some of these first. 1. Remote-Party-ID authenticity ====================== Currently, the Remote-Party-ID may include an "rpi-auth" token intended to provide authenticity service for the Remote-Party-ID specified. The current scheme has some shortcomings, most notably that it is not linked to the INVITE, which can be rectified fairly easily. However, upon thinking further about this and also based on the SIP Security meeting, it seems to me that this is simply a special case of a more general security service, i.e. to provide authenticity (or other security) service for one or more fields in a SIP message. The proposal is therefore to simply to remove the "rpi-auth" token. 2. Remote-Party-ID type ================= The "rpi-type" is intended to identify users by type rather than by name under the assumption that some types of users may be granted privileges different than others. One particular example we have identified and defined in the draft is the type "operator" which we need for the Busy-Line-Very end Emergency Interrupt. As has been noted, these are specific service examples and the "operator" type tends to fall in the service specific category as well. As the concept seems to apply in general, but the particular application of it may depend on the environment, the proposal is therefore simply to define "rpi-type" as a token and have local policy determine particular values that may or may not be supported. 3. OSPS header ============ As noted above, the OSPS header is not particularly general. but rather service specific. In the case of BLV, busy call processing should not result in a busy indication being returned but rather a duplicate media stream. In the case of EI, a conversation/conference should be the result. Taking a step back, the OSPS header can be viewed as a caller request for some kind of specifial call processing - as has been noted, this looks rather similar to caller preferences. The Request-Disposition "ring-feature" already achieves parts of this, and an alternative to the OSPS header would therefore be to simply expand upon this, e.g. by adding a "bridge-feature" (which might be further described in terms of simplex or duplex) or something similar. All comments appreciated. Thanks and regards Flemming Andreasen -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 05:29: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 FAA27135 for ; Mon, 12 Jun 2000 05:29: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 F3DE744352; Mon, 12 Jun 2000 05:17:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id 85F7044336 for ; Mon, 12 Jun 2000 05:17:13 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id PAA00550 for ; Mon, 12 Jun 2000 15:45:53 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568FC.0034ACDD ; Mon, 12 Jun 2000 15:05:21 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <652568FC.0034ACA3.00@sampark.hss.hns.com> Date: Mon, 12 Jun 2000 15:05:19 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] mobility support in SIP - basic 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 Hi, I just went thru draft-itsumo-sip-mobility-req-01.txt and have the following very basic Qs: 1. Is it correct to assume that no extensions are required in the SIP protocol to support mobility applications ? 2. Are there any other drafts/papers that address SIP & mobility which I need to see ? 3. Is there any doc that describes suggested SIP message exchanges b/w the various entities in a mobile environment ? (ie something more detailed wrt message flows ) Thx 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 Mon Jun 12 06:00: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 GAA27290 for ; Mon, 12 Jun 2000 06:00: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 1067E44358; Mon, 12 Jun 2000 05:49:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 7154044336 for ; Mon, 12 Jun 2000 05:49:42 -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.9) with ESMTP id e5CA0Ur13389; Mon, 12 Jun 2000 12:00:30 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA11985; Mon, 12 Jun 2000 13:00:29 +0300 (EET DST) Message-ID: <3944B4A3.9B9DD0A3@lmf.ericsson.se> Date: Mon, 12 Jun 2000 13:00:03 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] mobility support in SIP - basic questions References: <652568FC.0034ACA3.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 Hi, archow@hss.hns.com wrote: > > Hi, > I just went thru draft-itsumo-sip-mobility-req-01.txt and have the > following very basic Qs: > > 1. Is it correct to assume that no extensions are required in the SIP > protocol to support mobility applications ? It might be a correct assumption depending on what it is understood by mobility. If you want just a mobile SIP terminal in your research network vanilla SIP is probably enough. Extensions might be needed if you are thinking of using a UMTS access, or some services that are typically related to mobility, or being interoperable with other mobile systems... > 2. Are there any other drafts/papers that address SIP & mobility which I > need to see ? http://www.cs.columbia.edu/~hgs/papers/Wedl9908_Mobility.pdf > 3. Is there any doc that describes suggested SIP message exchanges b/w the > various entities in a mobile environment ? (ie something more detailed wrt > message flows ) You might want to follow ongoing work in 3GPP. Regards, Gonzalo > > Thx > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 08:06: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 IAA29327 for ; Mon, 12 Jun 2000 08:06: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 A7F054434D; Mon, 12 Jun 2000 07:54:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by lists.bell-labs.com (Postfix) with ESMTP id DCF7744336 for ; Mon, 12 Jun 2000 07:54:26 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id IAA28092; Mon, 12 Jun 2000 08:01:24 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568FC.004209EA ; Mon, 12 Jun 2000 08:01:19 -0400 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: Gonzalo Camarillo Cc: archow@hss.hns.com, sip@lists.bell-labs.com Message-ID: <852568FC.00420931.00@notes949.cc.telcordia.com> Date: Mon, 12 Jun 2000 07:59:14 -0400 Subject: Re: [SIP] mobility support in SIP - basic questions 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 Besides 3GPP, there is also some interest on SIP mobility in Mobile Wireless Internet Forum (www.mwif.org) which has started recently. SIP-2000 in Paris had a presentation on SIP mobility which addresses some SIP mobility issues as well. Besides the original work on SIP mobility by Henning and Elin, there are couple of related drafts in IETF for issues covering CDMA soft-handoff, and HMMP. Thanks Ashutosh _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 09:37: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 JAA01762 for ; Mon, 12 Jun 2000 09:37: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 5B11E4433B; Mon, 12 Jun 2000 09:26:06 -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 E93CD44336 for ; Mon, 12 Jun 2000 09:26:03 -0400 (EDT) Received: from hpqs0220.sqf.hp.com (hpqs0220.sqf.hp.com [15.144.178.52]) by palrel3.hp.com (Postfix) with ESMTP id CAB5B854 for ; Mon, 12 Jun 2000 06:36:52 -0700 (PDT) Received: from hpqs0220 (cdowney@localhost [127.0.0.1]) by hpqs0220.sqf.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.0) with SMTP id OAA28448 for ; Mon, 12 Jun 2000 14:36:50 +0100 (BST) Message-ID: <3944E770.4857@sqf.hp.com> Date: Mon, 12 Jun 2000 14:36:48 +0100 From: Christopher Downey Organization: Hewlett Packard LTD X-Mailer: Mozilla 3.04 (X11; I; HP-UX B.10.20 9000/712) MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP Message Examples Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 was wondering if someone could point me to a good source of example SIP messages. Any information much appreciated. Thank you Christopher -- ********************************************************************** Christopher Downey (Student Software Engineer) Agilent Technologies Research & Development Telecoms Systems Division Email : cdowney@sqf.hp.com South Queensferry Phone : +44 31 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 Jun 12 09:38: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 JAA01823 for ; Mon, 12 Jun 2000 09:38: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 A204844349; Mon, 12 Jun 2000 09:27: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 3C39C44336 for ; Mon, 12 Jun 2000 09:27:16 -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 JAA27581; Mon, 12 Jun 2000 09:38:05 -0400 (EDT) Message-ID: <3944E7BD.14BB3D16@cs.columbia.edu> Date: Mon, 12 Jun 2000 09:38: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: Billy Biggs , sip@lists.bell-labs.com References: <20000612014507.A20777@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Picky SIP bis draft comment Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 Billy Biggs wrote: > > Hi, > > I noticed you added SCTP and TLS to the transport URL parameter. On > page 19, when describing URL parameters, you don't mention them at all. > > This should be updated to say something like: > > "The transport parameter determines the transport mechanism to be used > for communications. SIP is currently defined to operate over TCP, > UDP, SCTP, and TLS, although others are possible." Thanks for catching this; fixed (with slightly different wording). > > One problem with this is that transport unfortunately isn't a list. > So, I guess if you support all of them, you have to publish each > transport you support as a seperate URL. Correct? Interesting point. A list would be more convenient, particularly when the URL is included on a web page. For Contact, enumeration will probably do, except that this won't work when Record-Route is used - the rules only allow to copy one Contact entry and the UAC has no clue which of the transport parameters might be appropriate for the last proxy before the Contact header address. Unfortunately, a list is not backward-compatible. I suppose we could define a new parameters, say, transports, which allows a list and deprecate the old version. -- 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 Jun 12 09:40: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 JAA01871 for ; Mon, 12 Jun 2000 09:40: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 EB8E444348; Mon, 12 Jun 2000 09: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 8179744336 for ; Mon, 12 Jun 2000 09: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 JAA27663; Mon, 12 Jun 2000 09:39:50 -0400 (EDT) Message-ID: <3944E826.D27202CB@cs.columbia.edu> Date: Mon, 12 Jun 2000 09:39:50 -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: Billy Biggs , sip@lists.bell-labs.com References: <20000612014507.A20777@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Picky SIP bis draft comment Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 a follow-up comment, this whole issue could be avoided if we could rely on DNS SRV. It seems far better to store transport availability in DNS rather than trying to update URLs on web pages... -- 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 Jun 12 09:45: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 JAA01932 for ; Mon, 12 Jun 2000 09:45: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 B9E084435C; Mon, 12 Jun 2000 09:34: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 23DB244336 for ; Mon, 12 Jun 2000 09:33:55 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA21936; Mon, 12 Jun 2000 14:42:33 +0100 (BST) From: "Jo Hornsby" To: Date: Mon, 12 Jun 2000 14:42:33 +0100 Message-ID: <000b01bfd474$0fcfba70$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] Max-Forwards Query Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 a little confused as to the proxy behaviour implied by section 6.26 of the June bis. In the case of OPTIONS, how should I (as a proxy) be responding? * Should I literally be responding as to _my_ Server capabilities? (I guess this can be useful with Supported, but I'm not sure how useful any of { Allow, Accept, Accept-Encoding, Accept-Language } are.) Or is this perhaps dependent on the Request-URI being me (the proxy)? * Should I return the response I would potentially have sent (e.g., do a provisional lookup to see if I could have proxied it further; if not, 404)? * Should I guess what the desired server (UA?) can do? &:) In the case of REGISTER, if the domain of the Request-URI is foreign, what should I return? Finally, if the request is neither OPTIONS nor REGISTER, I am supposed to respond with 483. If I do a lookup on the Request-URI, and discover that the target resolves in my Registrar with an action of "redirect", is it sensible to return a 3xx class? I guess what I'm asking is if there's any need to mandate the 483; aren't there some instances where a Proxy can return something that's maybe a little bit more useful? (Even a 404 could be said to be useful...no?) - Jo. -- 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 Mon Jun 12 09:46: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 JAA01962 for ; Mon, 12 Jun 2000 09:46: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 D3CB544360; Mon, 12 Jun 2000 09:34: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 45E5444336 for ; Mon, 12 Jun 2000 09:34:30 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA19906; Mon, 12 Jun 2000 14:39:37 +0100 (BST) Message-ID: <3944E818.79213D6E@ubiquity.net> Date: Mon, 12 Jun 2000 14:39:36 +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] SIP Message Examples References: <3944E770.4857@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 Check out the SIP call flows draft. There is a copy at Henning's site. http://www.cs.columbia.edu/%7Ehgs/sip/drafts/draft-ietf-sip-call-flows-00.txt hth, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net Christopher Downey wrote: > > Hi > > I was wondering if someone could point me to a good source of example > SIP messages. > > Any information much appreciated. > > Thank you > > Christopher > -- > ********************************************************************** > Christopher Downey (Student Software Engineer) > > Agilent Technologies > Research & Development > Telecoms Systems Division Email : cdowney@sqf.hp.com > South Queensferry Phone : +44 31 331 6137 > Scotland Internal : 33137 > ********************************************************************** > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- 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 Mon Jun 12 10:52: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 KAA03178 for ; Mon, 12 Jun 2000 10:52: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 6C98F4433E; Mon, 12 Jun 2000 10:41:54 -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 3F8A144336 for ; Mon, 12 Jun 2000 10:41:52 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FW100L01QNTCJ@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 12 Jun 2000 14:52:42 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FW100L02QNTCH@firewall.mcit.com>; Mon, 12 Jun 2000 14:52:41 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FW100401QMJFQ@dgismtp03.wcomnet.com>; Mon, 12 Jun 2000 14:51:55 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FW100401QMFF4@dgismtp03.wcomnet.com>; Mon, 12 Jun 2000 14:51:55 +0000 (GMT) Received: from C25776A ([166.46.18.60]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FW1002I3QLZIX@dgismtp03.wcomnet.com>; Mon, 12 Jun 2000 14:51:38 +0000 (GMT) Date: Mon, 12 Jun 2000 09:52:14 -0500 From: Henry Sinnreich Subject: RE: [SIP] SIP Message Examples In-reply-to: <3944E770.4857@sqf.hp.com> To: Christopher Downey , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 was wondering if someone could point me to a good >source of example >SIP messages. http://search.ietf.org/internet-drafts/draft-ietf-sip-call-flows -00.txt and http://search.ietf.org/internet-drafts/draft-sparks-sip-service- examples-00.txt Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >Christopher Downey >Sent: Monday, June 12, 2000 8:37 AM >To: sip@lists.bell-labs.com >Subject: [SIP] SIP Message Examples > > >Hi > >I was wondering if someone could point me to a good >source of example >SIP messages. > >Any information much appreciated. > >Thank you > >Christopher >-- >******************************************************* >*************** >Christopher Downey (Student Software Engineer) > >Agilent Technologies >Research & Development >Telecoms Systems Division Email : cdowney@sqf.hp.com >South Queensferry Phone : +44 31 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 Jun 12 11:03: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 LAA03518 for ; Mon, 12 Jun 2000 11:03: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 18EAF44359; Mon, 12 Jun 2000 10:52:08 -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 8CBFE44336 for ; Mon, 12 Jun 2000 10:52:03 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA24774; Mon, 12 Jun 2000 16:01:02 +0100 (BST) From: "Jo Hornsby" To: Date: Mon, 12 Jun 2000 16:01:02 +0100 Message-ID: <000c01bfd47f$067fff10$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] Forking Proxy Behaviour 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 Hullo, I have a couple of questions about section 12.4 in the June bis. The first paragraph after the C fragment contains the following sentence: "A proxy MAY send a CANCEL to all incomplete branches and return the best available final status to the client if not all responses have been received after 60 seconds or the timeout period specified in the Timeout header field of the request." ^^^^^^^ s/Timeout/Expires/? The next sentence says: "When forwarding responses, a proxy MUST forward all header fields of the selected response." Shouldn't this read more along the lines of forwarding the whole message, since there could be useful information in the message body? The next sentence says: "1xx: The proxy MAY forward the response upstream towards the client." Would it be better to whack this up to "SHOULD" (as long as the response is not 100)? (I guess this also applies to section 10.1.2.) Finally, is the notion of the "best response" strictly the lowest- numbered response (excluding 1xx), or is it more about the class of the response? The reason I ask this is because if this is the case, then I don't feel that the order of status codes (especially in the 4xx region) is necessarily very helpful. For instance, if a proxy forks to two locations, and one returns 486 and one returns 404, I would think that the 486 was a more useful response to return? Further, say a proxy receives an INVITE with a Request-URI that is unknown (i.e., not in the proxy's domain/locationserver), and thus the proxy just tries to route as best it can based on some DNS resolution. Now there's no server listening at the transport:IP:port that the proxy tries, so the proxy times-out [0]. As per 12.4, I guess one would expect the proxy to return a 408 response, but perhaps something like a 404 would be better? Comments? Cheers, - Jo. [0] Not particularly relevant for TCP, perhaps, but unfortunately it looks like we don't get the ICMP clues on Win32 Java. &:( -- 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 Mon Jun 12 11:06: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 LAA03558 for ; Mon, 12 Jun 2000 11:06: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 848F844362; Mon, 12 Jun 2000 10:54:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr703217-a.ktchnr1.on.wave.home.com [24.42.217.5]) by lists.bell-labs.com (Postfix) with ESMTP id 771B344336 for ; Mon, 12 Jun 2000 10:54:12 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 12 Jun 2000 11:04:59 -0400 (EDT) Date: Mon, 12 Jun 2000 11:04:59 -0400 From: Billy Biggs To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Re: Picky SIP bis draft comment Message-ID: <20000612110459.A21516@div8.net> References: <20000612014507.A20777@div8.net> <3944E826.D27202CB@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3944E826.D27202CB@cs.columbia.edu>; from schulzrinne@cs.columbia.edu on Mon, Jun 12, 2000 at 09:39:50AM -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 Henning Schulzrinne (schulzrinne@cs.columbia.edu): > As a follow-up comment, this whole issue could be avoided if we could > rely on DNS SRV. It seems far better to store transport availability in > DNS rather than trying to update URLs on web pages... I'm not sure I follow. You're suggesting that if we could rely on DNS SRV records, then we could announce URLs without specifying transport, and have the remote end use DNS to query what transports we support? That doesn't work very well with clients on machines that don't have access to their DNS entries, or to cases where many SIP clients (with seperate transport capabilities) are running on one machine... -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 11: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 LAA04108 for ; Mon, 12 Jun 2000 11: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 E9CF04435E; Mon, 12 Jun 2000 11:13: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 25FCE44336 for ; Mon, 12 Jun 2000 11:13: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 LAA02220; Mon, 12 Jun 2000 11:24:39 -0400 (EDT) Message-ID: <3945009C.295BE07A@dynamicsoft.com> Date: Mon, 12 Jun 2000 11:24:12 -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: Billy Biggs , sip@lists.bell-labs.com Subject: Re: [SIP] Re: Picky SIP bis draft comment References: <20000612014507.A20777@div8.net> <3944E826.D27202CB@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: > > As a follow-up comment, this whole issue could be avoided if we could > rely on DNS SRV. It seems far better to store transport availability in > DNS rather than trying to update URLs on web pages... I agree. I think we should keep transport as listing a single transport, which represents the "preferred" mechanism, but still allow for others discovered as a result of DNS and/or simply trying other transports to see what happens. -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 Jun 12 11:46: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 LAA04783 for ; Mon, 12 Jun 2000 11:46: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 DF2F744359; Mon, 12 Jun 2000 11:34: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 5CA1244336 for ; Mon, 12 Jun 2000 11:34:30 -0400 (EDT) Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA10197; Mon, 12 Jun 2000 16:43:12 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id QAA02338; Mon, 12 Jun 2000 16:43:11 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Mon, 12 Jun 2000 16:43:11 +0000 (GMT) From: James Undery To: Jo Hornsby Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Forking Proxy Behaviour Question In-Reply-To: <000c01bfd47f$067fff10$4e34c3c1@ubiquity.co.uk> 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 Mon, 12 Jun 2000, Jo Hornsby wrote: > Finally, is the notion of the "best response" strictly the lowest- > numbered response (excluding 1xx), or is it more about the class > of the response? The reason I ask this is because if this is the i.e. is the code fragment or the text to be taken as true. The code fragment returns the first response from the lowest "hundred group" of the responses. Yet the text says to return the lowest non 1xx error code seen. > case, then I don't feel that the order of status codes (especially > in the 4xx region) is necessarily very helpful. Although baseing response codes on HTTP was never going to produce a ordering of meaningful to SIP. Bearing this in mind the lowest non 1xx response will produce a consistent result, however, the lack of meaning in this makes it no better than using the first response from the lowest category of codes (excluding 1xx). Do other people feel this is a non-issue or something that ought to be standardised. 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 Mon Jun 12 12: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 MAA05895 for ; Mon, 12 Jun 2000 12: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 3C28B44358; Mon, 12 Jun 2000 12:12:52 -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 928A744336 for ; Mon, 12 Jun 2000 12:12:49 -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 MAA09667; Mon, 12 Jun 2000 12:23:35 -0400 (EDT) Message-ID: <39450E87.C044CF8A@cs.columbia.edu> Date: Mon, 12 Jun 2000 12:23: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: Billy Biggs Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Re: Picky SIP bis draft comment References: <20000612014507.A20777@div8.net> <3944E826.D27202CB@cs.columbia.edu> <20000612110459.A21516@div8.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 Billy Biggs wrote: > > Henning Schulzrinne (schulzrinne@cs.columbia.edu): > > > As a follow-up comment, this whole issue could be avoided if we could > > rely on DNS SRV. It seems far better to store transport availability in > > DNS rather than trying to update URLs on web pages... > > I'm not sure I follow. You're suggesting that if we could rely on DNS > SRV records, then we could announce URLs without specifying transport, > and have the remote end use DNS to query what transports we support? That would be one model that works some of the time. > > That doesn't work very well with clients on machines that don't have > access to their DNS entries, or to cases where many SIP clients (with > seperate transport capabilities) are running on one machine... Yes, but the alternative of changing dozens of web pages and an untold number of address book entries is probably higher. In the end, I'd imagine we end up with a hybrid system, where SRV is used for servers (where you typically wouldn't have a bunch running on the same system, at least not under the same externally visible name) and URL parameters for specifying the "favorite" transport and, like Jonathan said, try-others-if-necessary approach. To conclude this item: Unless somebody speaks up, the single-transport mechanism stays as is, rather than complicating things. -- 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 Jun 12 12:45: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 MAA06535 for ; Mon, 12 Jun 2000 12:45: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 CD79D44362; Mon, 12 Jun 2000 12:34:33 -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 5B74444336 for ; Mon, 12 Jun 2000 12:34:30 -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 MAA11392; Mon, 12 Jun 2000 12:44:39 -0400 (EDT) Message-ID: <39451377.1B6201E8@cs.columbia.edu> Date: Mon, 12 Jun 2000 12:44:39 -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: Jo Hornsby Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Forking Proxy Behaviour Question References: <000c01bfd47f$067fff10$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: > > Hullo, > > I have a couple of questions about section 12.4 in the June bis. > > The first paragraph after the C fragment contains the following > sentence: > "A proxy MAY send a CANCEL to all incomplete branches > and return the best available final status to the > client if not all responses have been received after > 60 seconds or the timeout period specified in the > Timeout header field of the request." > ^^^^^^^ > s/Timeout/Expires/? Yes; the 'timeout' word just got propagated inappropriately. > > The next sentence says: > "When forwarding responses, a proxy MUST forward all > header fields of the selected response." > Shouldn't this read more along the lines of forwarding the whole > message, since there could be useful information in the message > body? Proxies always forward the body, but I guess it doesn't hurt to belabor the (supposedly) obvious. Changed. > > The next sentence says: > "1xx: The proxy MAY forward the response upstream > towards the client." > Would it be better to whack this up to "SHOULD" (as long as > the response is not 100)? (I guess this also applies to section > 10.1.2.) I'm not sure it makes a big difference in practice, but I believe that's what most implementations do, so SHOULD seems appropriate. > > Finally, is the notion of the "best response" strictly the lowest- > numbered response (excluding 1xx), or is it more about the class > of the response? The reason I ask this is because if this is the > case, then I don't feel that the order of status codes (especially > in the 4xx region) is necessarily very helpful. > > For instance, if a proxy forks to two locations, and one returns > 486 and one returns 404, I would think that the 486 was a more > useful response to return? There are two cases: If the proxy "knows", it can apply whatever optimization it deems desirable - this seems like an implementation decision. In the absence of detailed status code knowledge, either first-in-lowest-class or number seems about as good. > > Further, say a proxy receives an INVITE with a Request-URI that > is unknown (i.e., not in the proxy's domain/locationserver), and > thus the proxy just tries to route as best it can based on some > DNS resolution. Now there's no server listening at the > transport:IP:port that the proxy tries, so the proxy times-out [0]. > As per 12.4, I guess one would expect the proxy to return a 408 > response, but perhaps something like a 404 would be better? I don't think you can distinguish the two with any degree of accuracy. If I'm not in my office when you knock, and you wait five minutes, was I "not found" or did you just "time out". Note that 404 indicates that you have definitive information that I don't exist (at that address). Proving the non-existence of people is hard. Just ask Elvis or the Loch Ness monster. > > Comments? > -- 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 Jun 12 13:25: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 NAA07384 for ; Mon, 12 Jun 2000 13:25: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 AA2C844368; Mon, 12 Jun 2000 13:14: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 89BB544336 for ; Mon, 12 Jun 2000 13:14:31 -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 NAA03135; Mon, 12 Jun 2000 13:26:38 -0400 (EDT) Message-ID: <39451CA7.5324283F@dynamicsoft.com> Date: Mon, 12 Jun 2000 13:23:51 -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: Jonathan Rosenberg Cc: Dave Oran , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Proposal for providing additional error information to UACs References: <3941D540.9033D813@dynamicsoft.com> 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 Jonathan Rosenberg wrote: > > > I'm on the fence on this one, like Jonathan. Any suggestions how to reach > > closure? > > Well, one way would be to move the pros/cons from theory to something > concrete. Can anyone come up with an example where using Contact would > cause something to go wrong somewhere? Yes: Contact already has some well-defined meaning in certain contexts, e.g., in 300 responses or responses to REGISTER. If we were to reuse it as a link to accessibility info, this would automatically mean that we are disabling that info in 300 responses or responses to REGISTER. I see no reason for this: defining a new header is no harder than overloading the old one. It even has an added advantage: the new header doesn't have to be defined in the base spec, which is thick enough as it is. --- 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 Mon Jun 12 17: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 RAA11205 for ; Mon, 12 Jun 2000 17:02: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 BCBD24435F; Mon, 12 Jun 2000 16:51:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rsys001a.roke.co.uk (rsys001a.roke.co.uk [193.118.192.110]) by lists.bell-labs.com (Postfix) with ESMTP id 0B04D44336 for ; Mon, 12 Jun 2000 16:51:12 -0400 (EDT) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 22:01:54 +0100 Received: from [193.118.192.80] (ppp.roke.co.uk [193.118.192.80]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LWXS6CY0; Mon, 12 Jun 2000 22:01:49 +0100 From: "Conroy, Lawrence (SMTP)" To: sip@lists.bell-labs.com Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Mon, 12 Jun 2000 22:02:14 +0100 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SIP] Transports 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 Hi Folks, If one can specify a transport other than UDP using a transport-parameter, then why does one HAVE TO support UDP in the first place? It looks like the bis draft now means that one MUST support it, even if only for an initial negotiation. Within enterprise environments, I can imagine providing a system which only supports TCP. No retransmit support, and using SSL/TLS for security for ALL session setups. I've been trying to see under what circumstances this is a problem. Of course, if I plug in a UA that only supports UDP, then certainly there's no success. However...this is not going to work anyway where we want to use SSL/TLS (in current implementations, at least). The new requirement for UDP support "come hell or high water" seems to make the current discussion on transport-parameter negotiation moot. You have to support UDP, so the initial negotiation will be done using UDP, so it's expensive to change to TCP - setting up all calls this way ends up with message exchanges worthy of H.323. UDP is a fine transport, and SIP's efficient support for reliable exchanges using UDP is one of its beauties, but making it MANDATORY for every implementation is not a good move, IMHO. -- lwc@roke.co.uk -- +44 1794 833666 ------------------------------------------------------------- Herewith a pointless waste of a few lines, stating that Roke Manor Research Limited is NOT responsible for my rantings and that they would very much like people to sue me rather than them if this email contains racist or sexist comments, please. Also, I can't do anything; only our lawyers can, so speak to them. Oh, and by the way, if our I.T. department has so mangled our email system that this has been misdirected, beware that having read this far, your eyes are about to fall out from reading this highly sensitive information, unless you immediately forget that this ever darkened your mailbox. Do it now. ------------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 17:20: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 RAA11468 for ; Mon, 12 Jun 2000 17:20: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 B09744436C; Mon, 12 Jun 2000 17:08:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [148.81.63.249]) by lists.bell-labs.com (Postfix) with ESMTP id 0D5E844336 for ; Mon, 12 Jun 2000 17:08:51 -0400 (EDT) Received: from pm65.warszawa.cvx.ppp.tpnet.pl ([213.76.108.65]:1625 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Mon, 12 Jun 2000 23:19:32 +0200 Message-ID: <39455323.F1579082@elka.pw.edu.pl> Date: Mon, 12 Jun 2000 23:16:19 +0200 From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Subject: [SIP] n-way conference Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, About n-way conferences: There is an example only 3-way conference in draft-ietf-sip-call-flows-00.txt. Did conisder anyone more participants (in any articles, drafts). Especialy, What's going with RTP streams then ? (I think about difference between 2-way and 3-way or more streaming) BR, Piotr -- All messages sent to P.Kossowski are delivered immediately also via SMS. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 17:36: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 RAA11695 for ; Mon, 12 Jun 2000 17:36: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 7CD8D44366; Mon, 12 Jun 2000 17:25:12 -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 09A9744336 for ; Mon, 12 Jun 2000 17:25:10 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jun 12 17:34:37 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 72C9944346; Mon, 12 Jun 2000 17:21:27 -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 1FC7D44345 for ; Mon, 12 Jun 2000 17:21:27 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA20992; Mon, 12 Jun 2000 16:21:25 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA20971; Mon, 12 Jun 2000 16:21:24 -0500 Message-ID: <39455451.91BF9CFE@lucent.com> Date: Mon, 12 Jun 2000 16:21:21 -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: "Conroy, Lawrence (SMTP)" Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Transports again 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 "Conroy, Lawrence (SMTP)" wrote: > > Hi Folks, > If one can specify a transport other than UDP using a > transport-parameter, then why does one HAVE TO support UDP in the > first place? So that two UACs can talk to each other without involoving a UDP->TCP proxy. In other words, if UDP is the de-facto standard that all SIP entities MUST support, then any entity can talk with any other one. If on the other hand, a UAC supports only UDP, then it can only talk to other UACs who support UDP. It cannot talk to a UAC that only supports TCP without necessarily involving a proxy that does UDP->TCP con- version. [...] > UDP is a fine transport, and SIP's efficient support for reliable > exchanges using UDP is one of its beauties, but making it MANDATORY > for every implementation is not a good move, IMHO. I belive most SIP implementations support UDP anyway. I also believe that under the new bis draft, UACs MUST support UDP and MAY support TCP; proxies on the other hand MUST support both UDP and TCP. I am not sure how the new requirements of support SCTP, etc. will affect the proxy. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Jun 12 17:56: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 RAA11843 for ; Mon, 12 Jun 2000 17:56: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 0CFB14436D; Mon, 12 Jun 2000 17:45:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.192.45]) by lists.bell-labs.com (Postfix) with ESMTP id 091E244336 for ; Mon, 12 Jun 2000 17:45:04 -0400 (EDT) Received: from [193.118.192.80] by cundall.co.uk with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 12 Jun 2000 22:54:53 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <39455451.91BF9CFE@lucent.com> References: <39455451.91BF9CFE@lucent.com> Date: Mon, 12 Jun 2000 22:56:08 +0100 To: vkg@lucent.com From: Lawrence Conroy Subject: Re: [SIP] Transports again Cc: sip@lists.bell-labs.com 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 4:21 pm -0500 12/6/00, Vijay K. Gurbani wrote: > >I belive most SIP implementations support UDP anyway. I also believe >that under the new bis draft, UACs MUST support UDP and MAY support >TCP; proxies on the other hand MUST support both UDP and TCP. > >I am not sure how the new requirements of support SCTP, etc. will affect >the proxy. To which I reply I agree that most SIP implementations support UDP. I understand from your comment that, if one has a TCP-only UA, it's non-standard. This is stronger than the original SHOULD for UDP support. If one wants to use a UDP-only UA in an enterprise with a set of TCP-only UAs then one has to go through a proxy - this was always the case and I'd expect to have such a beast even where the vast majority of UAs use TCP. The difference now is that the TCP-only UAs are non-standard. ^^^^^^^^^^^^ -- All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd pay me for them" | |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 17:57: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 RAA11863 for ; Mon, 12 Jun 2000 17:57: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 D656D44371; Mon, 12 Jun 2000 17:45: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 58D424436F for ; Mon, 12 Jun 2000 17:45:31 -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 RAA05279; Mon, 12 Jun 2000 17:57:28 -0400 (EDT) Message-ID: <39455C21.42EF3327@dynamicsoft.com> Date: Mon, 12 Jun 2000 17:54:41 -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: "Conroy, Lawrence (SMTP)" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Transports again References: 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 "Conroy, Lawrence (SMTP)" wrote: > You have > to support UDP, so the initial negotiation will be done using UDP, so it's > expensive to change to TCP - setting up all calls this way ends up with > message exchanges worthy of H.323. This isn't the case: there is no requirement for the protocol of initial transaction in SIP. If you know that the callee supports TCP, SCTP, pigeon carriers etc. (by examining callee's SRV record or by any other means), you are free to use that protocol for initial transaction. The requirement to implement UDP ensures that there is always a common protocol for communication. If a particular implementation/network configuration/PINT wants to use TCP only due to any reason (security considerations, inline contents etc), it is free to publish TCP as the preferred (or the only) protocol in its SRV records or SIP URLs. If it still receives a UDP request, it can either reject it or redirect with transport=tcp in the Contact. --- 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 Mon Jun 12 18:06: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 SAA12077 for ; Mon, 12 Jun 2000 18:06: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 0BF264436F; Mon, 12 Jun 2000 17:55: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 70D0B4435F for ; Mon, 12 Jun 2000 17:55: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 SAA06288; Mon, 12 Jun 2000 18:06:11 -0400 (EDT) Message-ID: <39455ED3.6652974@cs.columbia.edu> Date: Mon, 12 Jun 2000 18:06:11 -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: Lawrence Conroy Cc: vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Transports again References: <39455451.91BF9CFE@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 Lawrence Conroy wrote: > > At 4:21 pm -0500 12/6/00, Vijay K. Gurbani wrote: > > > >I belive most SIP implementations support UDP anyway. I also believe > >that under the new bis draft, UACs MUST support UDP and MAY support > >TCP; proxies on the other hand MUST support both UDP and TCP. > > > >I am not sure how the new requirements of support SCTP, etc. will affect > >the proxy. > To which I reply > I agree that most SIP implementations support UDP. > I understand from your comment that, if one has a TCP-only UA, it's > non-standard. This is stronger than the original SHOULD for UDP support. > If one wants to use a UDP-only UA in an enterprise with a set of TCP-only > UAs then one has to go through a proxy - this was always the case and I'd > expect to have such a beast even where the vast majority of UAs use TCP. > > The difference now is that the TCP-only UAs are non-standard. > ^^^^^^^^^^^^ Yes, that's intentional. The last thing I want to happen is that you and I both buy a SIP gadget, with a nice "Powered by SIP" logo pasted on the box, we plug them in and we can't communicate. Internet protocol implementations should always have a minimal way to communicate with each other to be standards-compliant. That is a common theme for all implementation aspects, from transport to security mechanisms. The effort in supporting both is minimal. The only time it would conceivably matter is for embedded systems - they would have a problem supporting TCP, not UDP. Yes, you may spend a few hours extra building UDP logic into your software. Standards compliance has its cost. -- 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 Jun 12 18:26: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 SAA12370 for ; Mon, 12 Jun 2000 18:26: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 02BC044367; Mon, 12 Jun 2000 18:15:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.pingtel.com (mail.pingtel.com [216.91.1.131]) by lists.bell-labs.com (Postfix) with ESMTP id 5BD1944336 for ; Mon, 12 Jun 2000 18:15:21 -0400 (EDT) Received: from stbarth.pingtel.com (cdhcp120.pingtel.com [10.1.1.120]) by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id SAA21648 for ; Mon, 12 Jun 2000 18:19:56 -0400 Message-Id: <4.3.1.2.20000612181551.00bd66f0@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 12 Jun 2000 18:23:37 -0400 To: SIP@lists.bell-labs.com From: Jay Batson Subject: RE: [SIP] Distinctive ringing feature In-Reply-To: <652568F9.00182AD9.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 X-BeenThere: sip@lists.bell-labs.com For those who are titillated by such behaviors as this, there's a SIP/Ethernet/Java phone that'll be available in the marketplace "real soon" to which this behavior can be added via a Java applet created by you or your favorite Java developer and which runs directly on the phone. We've created ring files with a bunch of old Hanna Barbera cartoon sound effects, like the Jetson's telephone ring sound, Fred Flintstone's bongo-feet-runaway, etc. They do catch your attention better than an old fashioned ring. Do our venture capitalists think it'll be the killer app? Nahh-- they're too boring. Now do *we* think it'll be cool? What do you think...? ;-) Go see http://www.pingtel.com for more info. -jb At 09:53 AM 6/9/00 +0530, you wrote: >why not ? :-) > >lots of interesting things can be put in. > >Since this is totally a client side implemenation that does not affect the >SIP signalling in any way, >we also did some cute(?!?) things like the ring volume being dynamically >modulated as duration of ring increases etc (you know, >like those alarms clocks that start with a whisper and keep screaming >louder and louder (till a point) till you hit on the button.... > >On the lighter side - here's some rings my limited imagination brings up: > >Girl/BoyFriend Ring - sweet chimes (or doomsday bongs - depending on what >state you are with her/him) >Beer pal ring - hic..hic...ring.ring...hic..hic >Boss Ring - no ring :-p >Wife Ring - continuous monotonic ring :-)) >etc...... > >Oh well :-) Back to work - I enjoyed keying in this mail :-p > >Regds >Arjun > >-- >Arjun Roychowdhury @ Hughes Software Systems >Technical Leader, VOIP Solutions >Off: Prestige Opal,146 Infantry Road,Blore - 560001 Ph:+91-080-2286390/1/2 >Res: 68/G 2nd Narayanappa Block, RT Nagar,Blore - 560032 Ph:3430565 >http://arjun.cjb.net > > >Henry Sinnreich on 06/09/2000 02:25:28 AM > >To: archow, Sekhar Banerjee >cc: SIP@lists.bell-labs.com > >Subject: RE: [SIP] Distinctive ringing feature > >Could distinctive ringing be a caller/called preference? > >Thanks, Henry > > >-----Original Message----- > >From: sip-admin@lists.bell-labs.com > >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of > >archow@hss.hns.com > >Sent: Wednesday, June 07, 2000 11:36 PM > >To: Sekhar Banerjee > >Cc: 'SIP@lists.bell-labs.com' > >Subject: Re: [SIP] Distinctive ringing feature > > > >Hi, > >you can definetely implement distinctive ringing from > >a SIP endpoint. > >The distinctive ring implementation is purely an > >endpoint side feature (see > >SIP FAQ on Henning's site) > >and does not need any special SIP signalling. > >For example, if say your phone has two alloted phone > >numbers - and you want > >a different ringing tone depending > >on the number the caller dialed - your implementation > >would simply see the > >phone number from the SIP headers > >and generate the appropriate ring for that phone. > > > > > >Regds > >Arjun > >-- > >Arjun Roychowdhury @ Hughes Software Systems > > > >Sekhar Banerjee on 06/08/2000 > >02:52:13 AM > > > >To: "'SIP@lists.bell-labs.com'" > >cc: > > > >Subject: [SIP] Distinctive ringing feature > > > > > > > > > >Hi, > > I would like to know if it would be possible to > >use SIP to instruct > >the endpoints/UA's to provide different ringing > >sequences. If someone has > >implemented this feature I would love to know more > >about it. I am talking > >about the distinctive ringing feature as it is present > >in the PSTN network > >today. > > > >Thanks > > > >Sekhar PingMe! Jay Batson President, CEO Pingtel Corp. jbatson@pingtel.com 781-938-5306 (office) 781-938-9650 (fax) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 18:38: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 SAA12539 for ; Mon, 12 Jun 2000 18:38: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 5D05544374; Mon, 12 Jun 2000 18:27:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.192.45]) by lists.bell-labs.com (Postfix) with ESMTP id 712E844368 for ; Mon, 12 Jun 2000 18:27:37 -0400 (EDT) Received: from [193.118.192.80] by cundall.co.uk with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 12 Jun 2000 23:37:27 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: In-Reply-To: <39455ED3.6652974@cs.columbia.edu> References: <39455451.91BF9CFE@lucent.com> <39455ED3.6652974@cs.columbia.edu> Date: Mon, 12 Jun 2000 23:33:44 +0100 To: Henning Schulzrinne From: Lawrence Conroy Subject: Re: [SIP] Transports again Cc: vkg@lucent.com, sip@lists.bell-labs.com 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 6:06 pm -0400 12/6/00, Henning Schulzrinne wrote: > > The difference now is that the TCP-only UAs are non-standard. > > ^^^^^^^^^^^^ >Yes, that's intentional. The last thing I want to happen is that you and >I both buy a SIP gadget, with a nice "Powered by SIP" logo pasted on the >box, we plug them in and we can't communicate. Internet protocol >implementations should always have a minimal way to communicate with >each other to be standards-compliant. That is a common theme for all >implementation aspects, from transport to security mechanisms. The >effort in supporting both is minimal. The only time it would conceivably >matter is for embedded systems - they would have a problem supporting >TCP, not UDP. Yes, you may spend a few hours extra building UDP logic >into your software. Standards compliance has its cost. Hmm... embedded systems may well have as hard a time supporting the retransmit-logic and storage implied by SIP-over-UDP - That software is not *yet* available completely off the shelf, whilst TCP stacks are. It's not the development time that's a problem here - it's the size and application processing requirements of the eventual product. I've realised that it may be my misunderstanding of the word SHOULD. I had thought that this could be translated as "you had better do this unless you have a good reason for doing otherwise". If I buy a "Powered by SIP" (apologies if this is someone's trademark :) device, then I would expect it to talk over UDP, unless it states that it only talks over TCP. I just believe that a TCP-only device should be a valid sub-set - but any such product had better state that it supports only this sub-set. Isn't that the sense of SHOULD? -- All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd pay me for them" | |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 22:51: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 WAA16563 for ; Mon, 12 Jun 2000 22:51: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 5364744368; Mon, 12 Jun 2000 22:40:25 -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 A9E3A44336 for ; Mon, 12 Jun 2000 22:40:22 -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 WAA06951; Mon, 12 Jun 2000 22:50:55 -0400 (EDT) Message-ID: <3945A1B1.F4902FB2@cs.columbia.edu> Date: Mon, 12 Jun 2000 22:51:29 -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: Lawrence Conroy Cc: vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Transports again References: <39455451.91BF9CFE@lucent.com> <39455ED3.6652974@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 > > Hmm... embedded systems may well have as hard a time supporting the > retransmit-logic and storage implied by SIP-over-UDP - That software > is not *yet* available completely off the shelf, whilst TCP stacks are. > It's not the development time that's a problem here - it's the size and > application processing requirements of the eventual product. Speaking from personal experience, with a lab that has developed a stack for both networking and SIP: TCP would have been far more complex than the trivial retransmit timer in SIP. For us, that's as much a code space problem as a development time problem. > > I've realised that it may be my misunderstanding of the word SHOULD. > I had thought that this could be translated as "you had better do this > unless you have a good reason for doing otherwise". > > If I buy a "Powered by SIP" (apologies if this is someone's trademark :) It should be, with a nice logo to go along with it :-) > device, then I would expect it to talk over UDP, unless it states that > it only talks over TCP. I just believe that a TCP-only device should be > a valid sub-set - but any such product had better state that it supports > only this sub-set. Isn't that the sense of SHOULD? My perception is that items crucial for basic interoperability are labeled MUST, while those more on the margins can be SHOULD. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 12 23: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 XAA16799 for ; Mon, 12 Jun 2000 23:26: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 7609244352; Mon, 12 Jun 2000 23:15:19 -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 1D78944336 for ; Mon, 12 Jun 2000 23:15:15 -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 e5D3Q8d14883; Mon, 12 Jun 2000 23:26:08 -0400 (EDT) Received: from research.telcordia.com (uunet-13-15.cc.telcordia.com [128.96.13.15]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id XAA07062; Mon, 12 Jun 2000 23:26:02 -0400 (EDT) Message-ID: <3945A9C8.8BA353CF@research.telcordia.com> Date: Mon, 12 Jun 2000 23:26:00 -0400 From: Faramak Vakil Organization: Telcordia Technologies X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ashutosh Dutta Cc: Gonzalo Camarillo , archow@hss.hns.com, sip@lists.bell-labs.com Subject: Re: [SIP] mobility support in SIP - basic questions References: <852568FC.00420931.00@notes949.cc.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 Ashutosh, MWIF has not considered/discussed any protocol for mobility management so far, and the statement about SIP mobility in MWIF is not accurate. Regards! Faramak Ashutosh Dutta wrote: > Besides 3GPP, there is also some interest on SIP mobility in Mobile Wireless > Internet Forum (www.mwif.org) which has started recently. SIP-2000 in Paris had > a presentation on SIP mobility which addresses some SIP mobility issues as well. > > Besides the original work on SIP mobility by Henning and Elin, there are couple > of related drafts in IETF for issues covering CDMA soft-handoff, and HMMP. > > Thanks > Ashutosh > > _______________________________________________ > 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 Jun 12 23:44: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 XAA17311 for ; Mon, 12 Jun 2000 23:44: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 B4B6C44344; Mon, 12 Jun 2000 23:33: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 2E13344336 for ; Mon, 12 Jun 2000 23:33:17 -0400 (EDT) Received: from dynamicsoft.com (1Cust202.tnt4.freehold.nj.da.uu.net [63.36.112.202]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA05989; Mon, 12 Jun 2000 23:45:28 -0400 (EDT) Message-ID: <3945AE3E.4DFC474F@dynamicsoft.com> Date: Mon, 12 Jun 2000 23:45:02 -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: Lawrence Conroy , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Transports again References: <39455451.91BF9CFE@lucent.com> <39455ED3.6652974@cs.columbia.edu> <3945A1B1.F4902FB2@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: > > > device, then I would expect it to talk over UDP, unless it states that > > it only talks over TCP. I just believe that a TCP-only device should be > > a valid sub-set - but any such product had better state that it supports > > only this sub-set. Isn't that the sense of SHOULD? > > My perception is that items crucial for basic interoperability are > labeled MUST, while those more on the margins can be SHOULD. SHOULD means an implementation can not do it and still be compliant. As has been pointed out, you can still build your network which always uses TCP/TLS when talking to each other. No UDP under normal conditions. But, you just need to be prepared for that UDP call from someone elses phone. -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 Jun 12 23:51: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 XAA17389 for ; Mon, 12 Jun 2000 23:51: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 D7E0E4437B; Mon, 12 Jun 2000 23:40: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 7B79D44336 for ; Mon, 12 Jun 2000 23:40:06 -0400 (EDT) Received: from dynamicsoft.com (1Cust202.tnt4.freehold.nj.da.uu.net [63.36.112.202]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA05993; Mon, 12 Jun 2000 23:52:20 -0400 (EDT) Message-ID: <3945AFDA.90B929B2@dynamicsoft.com> Date: Mon, 12 Jun 2000 23:51:54 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Dave Oran , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Proposal for providing additional error information to UACs References: <3941D540.9033D813@dynamicsoft.com> <39451CA7.5324283F@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 Igor Slepchin wrote: > > Jonathan Rosenberg wrote: > > > > > I'm on the fence on this one, like Jonathan. Any suggestions how to reach > > > closure? > > > > Well, one way would be to move the pros/cons from theory to something > > concrete. Can anyone come up with an example where using Contact would > > cause something to go wrong somewhere? > > Yes: Contact already has some well-defined meaning in certain contexts, > e.g., in 300 responses or responses to REGISTER. If we were to reuse it > as a link to accessibility info, this would automatically mean that we > are disabling that info in 300 responses or responses to REGISTER. I see > no reason for this: defining a new header is no harder than overloading > the old one. It even has an added advantage: the new header doesn't have > to be defined in the base spec, which is thick enough as it is. The big question is whether the current usage in 300 responses isn't what Dave wants anyway. I see no problem in returning an RTSP URL in a 300 redirect. This 300 is forwarded up to the UAC, which can act on the URL and fetch the streaming media content. No different than if the URL where an HTTP URL. One issue is if the UA wants to present the fetched data in some way which is different because the UA knows that the data is for the purposes of error reporting. Another issue, perhaps, is if a UA thinks that redirects are kind of optional, and so it ignores Contact headers in 300 class responses. These special error messages are probably more important and should be fetched by the UA. -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 Jun 13 00:16: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 AAA17522 for ; Tue, 13 Jun 2000 00:16: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 1D37B4433E; Tue, 13 Jun 2000 00:05:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id 1D5F444336 for ; Tue, 13 Jun 2000 00:05:12 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA08341; Tue, 13 Jun 2000 10:23:36 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568FD.00172643 ; Tue, 13 Jun 2000 09:42:51 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Henning Schulzrinne Cc: Lawrence Conroy , vkg@lucent.com, sip@lists.bell-labs.com Message-ID: <652568FD.00172599.00@sampark.hss.hns.com> Date: Tue, 13 Jun 2000 09:42:49 +0530 Subject: Re: [SIP] Transports again 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, thought Id put in my 2c worth: (responses preceded by ARC> ) > > Hmm... embedded systems may well have as hard a time supporting the > retransmit-logic and storage implied by SIP-over-UDP - That software > is not *yet* available completely off the shelf, whilst TCP stacks are. > It's not the development time that's a problem here - it's the size and > application processing requirements of the eventual product. Speaking from personal experience, with a lab that has developed a stack for both networking and SIP: TCP would have been far more complex than the trivial retransmit timer in SIP. For us, that's as much a code space problem as a development time problem. ARC> We have done a lot of porting of the SIP Stack on various embedded systems ARC> and the retransmission logic/ availability of a UDP stack was of no concern ARC> at all. As far as the retrans logic was concerned, it did not affect performance ARC> or run time overhead enough for us to look back at it. ARC> However, I would like to know of common RTOSes which dont have UDP ARC> support (so I can be prepared when we attack that RTOS next ;-) > > device, then I would expect it to talk over UDP, unless it states that > it only talks over TCP. I just believe that a TCP-only device should be > a valid sub-set - but any such product had better state that it supports > only this sub-set. Isn't that the sense of SHOULD? My perception is that items crucial for basic interoperability are labeled MUST, while those more on the margins can be SHOULD. ARC> Couldnt agree more. Its great to know that we have atleast one protocol ARC> which we know will be supported by others. If both are made SHOULD, im pretty ARC> sure in the next bakeoff we will have a lot of new ones. half supporting only TCP ARC> and the other only UDP who wont be able to talk to each other. I do understand ARC> your point that why use UDP if my network doesnt need it ? Its a tussle b/w ARC> your needs and making a minimal set of SIP fixed so that in broader interworking ARC> scenarios, there is lesser of ambiguity. If you say your n/w doesnt need UDP ARC> how about doing only TCP, and returning a final response Error of something ARC> like 300 (Protocol not allowed) (actually that was for SDP - sometinng similar ?) ARC> so that the sending terminal at least knows you are up and dont accept UDP without ARC> him trying to figure out if you are really up, or putting in extra logic at the ARC> sender to try TCP next... Not sure if this would be of any help though (?) ARC> However, im against suggesting this behaviour in the base spec for reasons I mentioned ARC> previously. 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 Tue Jun 13 00:37: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 AAA17691 for ; Tue, 13 Jun 2000 00:37: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 943C244352; Tue, 13 Jun 2000 00:25: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 1BD2D44336 for ; Tue, 13 Jun 2000 00:25:49 -0400 (EDT) Received: from dynamicsoft.com (1Cust202.tnt4.freehold.nj.da.uu.net [63.36.112.202]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA06064; Tue, 13 Jun 2000 00:34:12 -0400 (EDT) Message-ID: <3945B9A9.88605438@dynamicsoft.com> Date: Tue, 13 Jun 2000 00:33:45 -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: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] Forking Proxy Behaviour Question References: <000c01bfd47f$067fff10$4e34c3c1@ubiquity.co.uk> <39451377.1B6201E8@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: > > > > > The next sentence says: > > "1xx: The proxy MAY forward the response upstream > > towards the client." > > Would it be better to whack this up to "SHOULD" (as long as > > the response is not 100)? (I guess this also applies to section > > 10.1.2.) > > I'm not sure it makes a big difference in practice, but I believe that's > what most implementations do, so SHOULD seems appropriate. Actually, you really want to make this a SHOULD, since reliable provisional responses may not work otherwise. > > > > > Finally, is the notion of the "best response" strictly the lowest- > > numbered response (excluding 1xx), or is it more about the class > > of the response? The reason I ask this is because if this is the > > case, then I don't feel that the order of status codes (especially > > in the 4xx region) is necessarily very helpful. Hmm... actually, I always thought that the ordering was: 200 better than 600 better than 300 better than 400 better than 500 which is different from the code. A 600 response is a fairly strong statement, and I think it makes sense to make it higher than 300-599. -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 Jun 13 01:08: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 BAA18289 for ; Tue, 13 Jun 2000 01: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 E2F4F44369; Tue, 13 Jun 2000 00:57:26 -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 D306544336 for ; Tue, 13 Jun 2000 00:57:23 -0400 (EDT) Received: by EXCHANGESVR with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 22:09:16 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@lists.bell-labs.com'" Date: Mon, 12 Jun 2000 22:09: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] CSeq matching and multiple requests. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 CSeq matching logic. I don't think I have seen anything in the INFO or 2543bis drafts explicitly forbidding having multiple outstanding requests: eg a re-INVITE and INFO both outstanding. If this is the case then the CSeq matching logic is flawed as you cannot rely on the value CSeq monotonically increasing. Section 11.5 of RFC2543bis "Receiving Subsequent Requests" states that if the Cseq doesn 't match any previous requests AND the CSeq is higher than the last received value, then it is a new request. This doesn't work if can you have multiple outstanding requests. For instance, consider the case where one side sends an INFO request (eg application/mgcp-event) and then shortly after sends a re-INVITE. [Independent mid-call signaling is most immediate use I can see for multiple requests]. Now consider if the first INFO request UDP message is lost but the INVITE is not -> the INVITE can arrive before the INFO retransmission. Using the above logic, the UAS will now never respond to the INFO request. I remember on Henning's page, a CSeq clarification alluded to disallowing multiple outstanding requests but my interpretation of that (after subsequent discussion) was that this was referring to INVITE responses from either side (ie the glare condition). If I have missed some crucial piece of text then I think it should be moved to a more logical place in the draft (eg Section 11). Do we need multiple outstanding requests (per UA) anyway ? It certainly complicates matters significantly but also has a number of benefits!! It opens a whole can of worms: how many simultaneous requests? one per method? how do you handle CSeq? Comments? Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 13 09:59: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 JAA08451 for ; Tue, 13 Jun 2000 09:59: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 0979E44353; Tue, 13 Jun 2000 09:48:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id 3B0B544348 for ; Tue, 13 Jun 2000 09:48:23 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id JAA22492 for ; Tue, 13 Jun 2000 09:01:18 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id IAA12129 for ; Tue, 13 Jun 2000 08:58:46 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 08:58:45 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790F8@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: sip@lists.bell-labs.com Subject: RE: [SIP] comments on draft-sparks-sip-cc-transfer-00.txt Date: Tue, 13 Jun 2000 08:58:44 -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 > > (1) 400-600-class failure [problem with the TRANSFER request] > > (2) 200 OK [transfer attempted and succeeded] > > (3) ??? [response that specifically means transfer attempted but failed] [Jonathan R. responds:] > I would say this is a 500 class response. I believe 500 class responses > generally mean, "this request failed this time, but the same request > might succeed later on". That's exactly the case here. You could even > include a Retry-After in the response indicating when to try. With the Retry-After probably copied from the response to the failed transfer INVITE, if present. I say "probably" because one could likely contrive an example where the transferee has additional knowledge that enables it to generate a better Retry-After value. But the normal case could be to copy the Retry-After value, in effect saying, "I tried the transfer and it failed; they told me to try again in this many minutes; send me another TRANSFER then if you'd like me to do that." Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 13 11: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 LAA12349 for ; Tue, 13 Jun 2000 11:46: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 7BCE744368; Tue, 13 Jun 2000 11:34:24 -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 246F044336 for ; Tue, 13 Jun 2000 11:34:16 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Tue, 13 Jun 2000 10:43:39 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 10:44:11 -0500 Message-ID: <2E532B03F035D3119AF40000F80932C32073DF@crchy28d.us.nortel.com> From: "William Lee" To: sip@lists.bell-labs.com Date: Tue, 13 Jun 2000 10:44:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD54E.37CA6680" Subject: [SIP] SIP bis draft comment: 406 Not Acceptable vs. 488 Not Acceptable Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_01BFD54E.37CA6680 Content-Type: text/plain Are these suppose to be two distinct response messages? If so, it would be less confusing if the text also related that these are two unique responses. William Lee williaml@nortelnetworks.com ------_=_NextPart_001_01BFD54E.37CA6680 Content-Type: text/html SIP bis draft comment: 406 Not Acceptable vs. 488 Not Acceptable

Are these suppose to be two distinct response messages? If so, it would be less confusing if
the text also related that these are two unique responses.

William Lee
williaml@nortelnetworks.com

------_=_NextPart_001_01BFD54E.37CA6680-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 13 16:13: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 QAA21370 for ; Tue, 13 Jun 2000 16:13: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 8599E44369; Tue, 13 Jun 2000 16:01: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 39ED344336 for ; Tue, 13 Jun 2000 16:01: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 PAA21415 for ; Tue, 13 Jun 2000 15:13:02 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 15:08:15 -0500 Message-ID: From: "Culpepper, Bert" To: SIP List Date: Tue, 13 Jun 2000 15:08:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Out-of-Band DTMF in 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 Hello all, There have been a couple IDs written a short while back on DTMF transport, collection, etc. each using the SIP INFO method. I see out-of-band DTMF reporting as a "problem" to be solved to support carrying telecommunications traffic over SIP networks. IMO, Out-of-band "event" reporting is needed to minimize latency and provide services to PSTN-based users within SIP proxy/application servers that do not also "own" the gateways. MGCP and Megaco compliant gateways support DTMF collection and out-of-band reporting but there is no "agreed upon" method or interworking proposal in SIP/SIP-T that I have found. Is there a solution to this "problem" that I have missed or are others interested in addressing this area? As of this week, I've asked for a "slot" at the upcoming IETF meeting to present one ID on the subject but don't want to take others' time if there's no need. Thanks, Bert _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 13 16:19: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 QAA21523 for ; Tue, 13 Jun 2000 16:19: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 6721A44371; Tue, 13 Jun 2000 16:07:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by lists.bell-labs.com (Postfix) with ESMTP id EFB564436D for ; Tue, 13 Jun 2000 16:07:49 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id QAA23889; Tue, 13 Jun 2000 16:16:31 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568FD.006F5D5D ; Tue, 13 Jun 2000 16:16:23 -0400 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: Faramak Vakil Cc: Gonzalo Camarillo , archow@hss.hns.com, sip@lists.bell-labs.com Message-ID: <852568FD.006F5C9C.00@notes949.cc.telcordia.com> Date: Tue, 13 Jun 2000 16:14:18 -0400 Subject: Re: [SIP] mobility support in SIP - basic questions 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 Thanks Faramak for clarifying that. My impression about MWIF's interest about SIP was based on the two MWIF references that were mentioned in SIP-2000 presentation. But those date back to January though. Thanks Ashutosh Faramak Vakil on 06/12/2000 11:26:00 PM To: Ashutosh Dutta cc: Gonzalo Camarillo , archow@hss.hns.com, sip@lists.bell-labs.com (bcc: Ashutosh Dutta/Telcordia) Subject: Re: [SIP] mobility support in SIP - basic questions Ashutosh, MWIF has not considered/discussed any protocol for mobility management so far, and the statement about SIP mobility in MWIF is not accurate. Regards! Faramak Ashutosh Dutta wrote: > Besides 3GPP, there is also some interest on SIP mobility in Mobile Wireless > Internet Forum (www.mwif.org) which has started recently. SIP-2000 in Paris had > a presentation on SIP mobility which addresses some SIP mobility issues as well. > > Besides the original work on SIP mobility by Henning and Elin, there are couple > of related drafts in IETF for issues covering CDMA soft-handoff, and HMMP. > > Thanks > Ashutosh > > _______________________________________________ > 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 Jun 13 18: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 SAA23875 for ; Tue, 13 Jun 2000 18:09: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 8433E44369; Tue, 13 Jun 2000 17:57: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 08D7244336 for ; Tue, 13 Jun 2000 17:57: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 SAA20215; Tue, 13 Jun 2000 18:07:15 -0400 (EDT) Message-ID: <3946B093.4C71B5C2@cs.columbia.edu> Date: Tue, 13 Jun 2000 18:07:15 -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: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] Forking Proxy Behaviour Question References: <000c01bfd47f$067fff10$4e34c3c1@ubiquity.co.uk> <39451377.1B6201E8@cs.columbia.edu> <3945B9A9.88605438@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: > > Henning Schulzrinne wrote: > > Actually, you really want to make this a SHOULD, since reliable > provisional responses may not work otherwise. Changed to SHOULD. > > > > > > > > > Finally, is the notion of the "best response" strictly the lowest- > > > numbered response (excluding 1xx), or is it more about the class > > > of the response? The reason I ask this is because if this is the > > > case, then I don't feel that the order of status codes (especially > > > in the 4xx region) is necessarily very helpful. > > Hmm... actually, I always thought that the ordering was: > > 200 better than 600 better than 300 better than 400 better than 500 > > which is different from the code. A 600 response is a fairly strong > statement, and I think it makes sense to make it higher than 300-599. > Maybe I'm missing something, but I read the code as: If a class '6' arrives, best is set to this response and the search loop is terminated by 'break', so that the 6xx is returned. else if (class == 6) { best = r; break; } -- 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 Jun 13 20:59: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 UAA25912 for ; Tue, 13 Jun 2000 20:59: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 ADAE044360; Tue, 13 Jun 2000 20:48:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by lists.bell-labs.com (Postfix) with ESMTP id CF8E944336 for ; Tue, 13 Jun 2000 20:48:29 -0400 (EDT) Received: from vovida.com (a98.vovida.com [209.237.8.98] (may be forged)) by repulse.cnchost.com id UAA21849; Tue, 13 Jun 2000 20:59:31 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <3946D8F3.86230CC6@vovida.com> Date: Tue, 13 Jun 2000 17:59:31 -0700 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Content-Type: multipart/alternative; boundary="------------C9FF0E6D9ADC0203C2F25F28" Subject: [SIP] Clarification on the proxy behaviour. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------C9FF0E6D9ADC0203C2F25F28 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: If a message goes through a proxy twice , ex: client A----------> proxy1-------------> proxy 2 --------------------------> proxy1. sends invite forwards this sends this back to proxy 1 proxy1----------------> client B. In the above scenario, proxy 1 needs to distinguish between clientA--> proxy1 INVITE, and proxy2--->proxy1 INVITE. This can be done in SIP by putting a different branch in the Via. My concern was that in the standard it is said that when a proxy sees its own address in the Via, we need to remove it , otherwise this may cause a loop. Now if we change the branch, this will indeed not cause the loop. However, I wanted to know if there was any other repurcussions if a proxy does this. The SIP examples or the RFC as such does not mention this scenario any where. Thanks much ! -- Sunitha Kumar http://www.vovida.com --------------C9FF0E6D9ADC0203C2F25F28 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi:

If a message goes through a proxy twice , ex:
 

client A----------> proxy1-------------> proxy 2 -------------------------->    proxy1.
                 sends  invite                forwards this                           sends this back to proxy 1
 
 

proxy1----------------> client B.
 

In the above scenario, proxy 1 needs to distinguish between clientA--> proxy1 INVITE, and proxy2--->proxy1 INVITE. This can be done in SIP by putting a different branch in the Via.

My concern was that in the standard it is said that when a proxy sees its own address in the Via, we need to
remove it , otherwise this may cause a loop. Now if we change the branch, this will indeed not cause the loop.

However, I wanted to know if there was any other repurcussions if a proxy does  this.  The SIP examples or the RFC as such does not mention this scenario any where.

Thanks much ! 

-- 
Sunitha Kumar
http://www.vovida.com
  --------------C9FF0E6D9ADC0203C2F25F28-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 13 23:57: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 XAA29937 for ; Tue, 13 Jun 2000 23:57: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 6102D44360; Tue, 13 Jun 2000 23:46: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 1BEEE44336 for ; Tue, 13 Jun 2000 23:46:33 -0400 (EDT) Received: from dynamicsoft.com (1Cust213.tnt2.freehold.nj.da.uu.net [63.17.114.213]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA11131; Tue, 13 Jun 2000 23:58:40 -0400 (EDT) Message-ID: <394702DB.3C479937@dynamicsoft.com> Date: Tue, 13 Jun 2000 23:58:19 -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: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] CSeq matching and multiple requests. 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: > > I have a query about the CSeq matching logic. > > I don't think I have seen anything in the INFO or 2543bis drafts explicitly > forbidding having multiple outstanding requests: eg a re-INVITE and INFO > both outstanding. If this is the case then the CSeq matching logic is flawed > as you cannot rely on the value CSeq monotonically increasing. It has been discussed, but I don't think a concrete conclusion was ever reached on whether it was allowed. > > Section 11.5 of RFC2543bis "Receiving Subsequent Requests" states that if > the Cseq doesn 't match any previous requests AND the CSeq is higher than > the last received value, then it is a new request. > > This doesn't work if can you have multiple outstanding requests. For > instance, consider the case where one side sends an INFO request (eg > application/mgcp-event) and then shortly after sends a re-INVITE. > [Independent mid-call signaling is most immediate use I can see for multiple > requests]. Now consider if the first INFO request UDP message is lost but > the INVITE is not -> the INVITE can arrive before the INFO retransmission. > Using the above logic, the UAS will now never respond to the INFO request. This is true assuming the behavior for requests that are not new is to ignore them. If you are supporting multiple outstanding requests, you would not ignore such requests. You could determine them to be retransmissions if the CSeq matched a CSeq you had seen before, "old" if the CSeq is lower than the highest received CSeq, and "new" if its higher than the highest received CSeq. Both old and new requests would need to be processed. > If I have missed some crucial piece of text then I think it should be moved > to a more logical place in the draft (eg Section 11). Do we need multiple > outstanding requests (per UA) anyway ? It would be nice to hear if anyone has any concrete examples of a need for this. > It certainly complicates matters > significantly but also has a number of benefits!! No doubt, but nothing that isn't solvable. -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 Jun 14 00:14: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 AAA00116 for ; Wed, 14 Jun 2000 00: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 7025C44374; Wed, 14 Jun 2000 00:03:05 -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 CCDE844336 for ; Wed, 14 Jun 2000 00:03:02 -0400 (EDT) Received: from dynamicsoft.com (1Cust213.tnt2.freehold.nj.da.uu.net [63.17.114.213]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA11180; Wed, 14 Jun 2000 00:15:23 -0400 (EDT) Message-ID: <394706C6.34F12577@dynamicsoft.com> Date: Wed, 14 Jun 2000 00:15:02 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: SIPbell-labs Subject: Re: [SIP] Clarification on the proxy behaviour. References: <3946D8F3.86230CC6@vovida.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 issue has been discussed numerous times on the list. It is referred to as request "spiraling" and is not a loop. The mechanisms for constructing the Via to support this are defined in the bis draft, section 6.46. The text still needs some work though; a request is only a loop if your IP address is there, AND, when you compute the hash over the request URI, To, From, Call-ID, it matches the component in the branch parameter. -Jonathan R. Sunitha Kumar wrote: > > Hi: > > If a message goes through a proxy twice , ex: > > > client A----------> proxy1-------------> proxy 2 > --------------------------> proxy1. > sends invite forwards > this sends this back to proxy 1 > > > > proxy1----------------> client B. > > > In the above scenario, proxy 1 needs to distinguish between clientA--> > proxy1 INVITE, and proxy2--->proxy1 INVITE. This can be done in SIP by > putting a different branch in the Via. > > My concern was that in the standard it is said that when a proxy sees > its own address in the Via, we need to > remove it , otherwise this may cause a loop. Now if we change the > branch, this will indeed not cause the loop. > > However, I wanted to know if there was any other repurcussions if a > proxy does this. The SIP examples or the RFC as such does not > mention this scenario any where. > > Thanks much ! > > -- > Sunitha Kumar > http://www.vovida.com > > -- 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 Jun 14 00:23: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 AAA00157 for ; Wed, 14 Jun 2000 00:23: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 6316244378; Wed, 14 Jun 2000 00:12: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 A8C4E4436C for ; Wed, 14 Jun 2000 00:12:07 -0400 (EDT) Received: from dynamicsoft.com (1Cust213.tnt2.freehold.nj.da.uu.net [63.17.114.213]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA11223; Wed, 14 Jun 2000 00:23:41 -0400 (EDT) Message-ID: <394708B8.247B933B@dynamicsoft.com> Date: Wed, 14 Jun 2000 00:23:20 -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: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] Forking Proxy Behaviour Question References: <000c01bfd47f$067fff10$4e34c3c1@ubiquity.co.uk> <39451377.1B6201E8@cs.columbia.edu> <3945B9A9.88605438@dynamicsoft.com> <3946B093.4C71B5C2@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: > > Maybe I'm missing something, but I read the code as: If a class '6' > arrives, best is set to this response and the search loop is terminated > by 'break', so that the 6xx is returned. > > else if (class == 6) { > best = r; > break; > } You're right. Too much blood in my caffeine when I read that code again ;) -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 Jun 14 02:37: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 CAA13325 for ; Wed, 14 Jun 2000 02: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 6DCDB4436C; Wed, 14 Jun 2000 02:26:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 7AE5C44336 for ; Wed, 14 Jun 2000 02:26:25 -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.9) with ESMTP id e5E6bSr27692 for ; Wed, 14 Jun 2000 08:37:28 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA05082 for ; Wed, 14 Jun 2000 09:37:27 +0300 (EET DST) Message-ID: <39472802.15902A3D@lmf.ericsson.se> Date: Wed, 14 Jun 2000 09:36:50 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] [Fwd: Status of SDPng] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 sent this mail to the MMUSIC mailing list but I got no answer... maybe here somebody knows... Thanks, Gonzalo -------- Original Message -------- Subject: Status of SDPng Date: Mon, 12 Jun 2000 09:29:44 +0300 From: gonzalo.camarillo@lmf.ericsson.se Organization: Oy L M Ericsson Ab To: mmusic Hi, I would like to know the status of the so called, SDPng. Is there any draft available about it? Are there folks working on it? Time frame for this work, goals... Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 02:54: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 CAA13421 for ; Wed, 14 Jun 2000 02:54: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 57A2344378; Wed, 14 Jun 2000 02:43:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id BD9A244336 for ; Wed, 14 Jun 2000 02:43:18 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id MAA27913 for ; Wed, 14 Jun 2000 12:22:35 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Wed, 14 Jun 2000 12:22:32 +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 MAA22102 for ; Wed, 14 Jun 2000 12:22:28 +0530 (IST) Message-ID: <00ab01bfd5cb$c5fc8000$8c40000a@sasi.com> From: "rafi" To: Date: Wed, 14 Jun 2000 12:12:56 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01BFD5F9.DF8B8920" 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] Handling multiple Transfer Target Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_00A8_01BFD5F9.DF8B8920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Is it possible for the transferor to inform the transferee to try more than one transfer target serially or simultaneously? Probably one way to do is to include more than one Transfer-to-Header in the TRANSFER request message because transferee take decision=20 based on this field (section 4.6 of draft = draft-sparks-sip-cc-transfer-00.txt). May be order of the of each name-addr / addr-spec in = Transfer-to-Header implies=20 their priority. Having more than one Transfer-to-Header header is not allowed in the draft, draft-sparks-sip-cc-transfer-00.txt. Please note that contact field in the TRANSFER method is optional. = So my understanding is that only Transfer-to-Header is used to identify the = transfer target. Thanks Rafi AssadiH.M. Silicon Automation Systems Bangalore, INDIA ------=_NextPart_000_00A8_01BFD5F9.DF8B8920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
           Is = it=20 possible for the transferor to inform the=20 transferee
 to try more than one transfer=20 target serially or = simultaneously?
 Probably one way to do is to include more than one Transfer-to-Header
 in the=20 TRANSFER request message because = transferee take=20 decision
based on this field  (section 4.6 = of=20 draft  draft-sparks-sip-cc-transfer-00.txt).
 May be order of the = of each name-addr / addr-spec in  Transfer-to-Header implies =
their priority.=20 Having more than one Transfer-to-Header header
is not allowed in the draft,=20 draft-sparks-sip-cc-transfer-00.txt.
 
     Please note = that contact=20 field in the TRANSFER method is optional. So
my understanding is that only = Transfer-to-Header is=20 used to identify the transfer target.
 
 
Thanks
Rafi AssadiH.M.
Silicon Automation Systems
Bangalore, INDIA
 
 
 
------=_NextPart_000_00A8_01BFD5F9.DF8B8920-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 07:05: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 HAA15313 for ; Wed, 14 Jun 2000 07:05: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 2DA8D44379; Wed, 14 Jun 2000 06:52: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 3B5BC44336 for ; Wed, 14 Jun 2000 06:52:36 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA00828; Wed, 14 Jun 2000 12:01:41 +0100 (BST) Message-ID: <39476614.5C6B361E@ubiquity.net> Date: Wed, 14 Jun 2000 12:01:40 +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: Henning Schulzrinne Cc: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] Forking Proxy Behaviour Question References: <000c01bfd47f$067fff10$4e34c3c1@ubiquity.co.uk> <39451377.1B6201E8@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: > > Jo Hornsby wrote: [snip] > > Finally, is the notion of the "best response" strictly the lowest- > > numbered response (excluding 1xx), or is it more about the class > > of the response? The reason I ask this is because if this is the > > case, then I don't feel that the order of status codes (especially > > in the 4xx region) is necessarily very helpful. > > > > For instance, if a proxy forks to two locations, and one returns > > 486 and one returns 404, I would think that the 486 was a more > > useful response to return? > > There are two cases: If the proxy "knows", it can apply whatever > optimization it deems desirable - this seems like an implementation > decision. In the absence of detailed status code knowledge, either > first-in-lowest-class or number seems about as good. Is it clear that this is the intention? The text in 12.4 about sending back responses only refers to returning lowest-numbered responses within the 3xx, 4xx, 5xx categories. While the "C-code [which] describes the behaviour of a proxy" would send back the last 4xx or 5xx class response it receives, if there was nothing lower. 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 Jun 14 10:00: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 KAA20874 for ; Wed, 14 Jun 2000 10:00: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 D2B1344381; Wed, 14 Jun 2000 09:48:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from marlborough.cnchost.com (marlborough.concentric.net [207.155.248.14]) by lists.bell-labs.com (Postfix) with ESMTP id 1305F44379 for ; Wed, 14 Jun 2000 09:48:54 -0400 (EDT) Received: from ss8networks.com (gw-ss8networks.storm.ca [209.87.234.122]) by marlborough.cnchost.com id JAA01526; Wed, 14 Jun 2000 09:59:50 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <39478EA4.12B0C5C7@ss8networks.com> Date: Wed, 14 Jun 2000 09:54:44 -0400 From: Dave Walker Organization: SS8 Networks Inc X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: SIP List Subject: Re: [SIP] Out-of-Band DTMF in 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 What would you like to see? I don't think that agreement on the MIME-type is going to be easy to get. Your draft suggested MGCP events, others might prefer megaco. A SIP phone may not speak either, but if it uses RFC2833 it would be easy to send audio/tone MIME-type inside of INFO. We already have the Accept headers for this kind of thing. Would you like to see an option-tag defined for it? Regards, Dave Walker SS8 Networks Ottawa, Canada. "Culpepper, Bert" wrote: > > Hello all, > > There have been a couple IDs written a short while back on DTMF transport, > collection, etc. each using the SIP INFO method. I see out-of-band DTMF > reporting as a "problem" to be solved to support carrying telecommunications > traffic over SIP networks. IMO, Out-of-band "event" reporting is needed to > minimize latency and provide services to PSTN-based users within SIP > proxy/application servers that do not also "own" the gateways. MGCP and > Megaco compliant gateways support DTMF collection and out-of-band reporting > but there is no "agreed upon" method or interworking proposal in SIP/SIP-T > that I have found. > > Is there a solution to this "problem" that I have missed or are others > interested in addressing this area? As of this week, I've asked for a > "slot" at the upcoming IETF meeting to present one ID on the subject but > don't want to take others' time if there's no need. > > Thanks, > Bert > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 10:10: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 KAA21229 for ; Wed, 14 Jun 2000 10:10: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 B975644385; Wed, 14 Jun 2000 09:58:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id ED7FC44379 for ; Wed, 14 Jun 2000 09:58:32 -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.9) with ESMTP id e5EE9Zr17228 for ; Wed, 14 Jun 2000 16:09:36 +0200 (MET DST) 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 RAA06094 for ; Wed, 14 Jun 2000 17:09:34 +0300 (EET DST) Message-ID: <394791E4.CD32B405@ericsson.fi> Date: Wed, 14 Jun 2000 17:08:36 +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'" References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Receiver-tagged Via header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 all, The rcf2543bis states in section 6.45.2 "Every host that sends or forwards a SIP request adds a Via field indicating the host’s address. However, it is possible that Network Address Translators (NATs) change the source address and port of the request (e.g.,from a net-10 to a globally routable address), in which case the Via header field cannot be relied on to route replies. To prevent this, a proxy SHOULD check the top-most Via header field to ensure that it contains the sender’s correct network address, as seen from that proxy. If the sender’s address is incorrect, the proxy MUST add a “received” parameter to the Via header field inserted by the previous hop. Such a modified Via header field is known as a receiver-tagged Via header field." So, it is possible that the port is also changed. Yet the syntax for via-received looks like this: via-received = ”received” ”=” host shouldn't it be via-received = ”received” ”=” hostport or via-received = ”received” ”=” host [":" port] Thanks, Hisham _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 10: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 KAA21570 for ; Wed, 14 Jun 2000 10: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 4E7C54438C; Wed, 14 Jun 2000 10:09:36 -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 A914444379 for ; Wed, 14 Jun 2000 10:09: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 KAA09472; Wed, 14 Jun 2000 10:19:51 -0400 (EDT) Message-ID: <39479487.BFA92027@cs.columbia.edu> Date: Wed, 14 Jun 2000 10:19:51 -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: Dave Walker Cc: "Culpepper, Bert" , SIP List Subject: Re: [SIP] Out-of-Band DTMF in SIP References: <39478EA4.12B0C5C7@ss8networks.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 Dave Walker wrote: > > What would you like to see? I don't think that agreement on the > MIME-type is going to be easy to get. Your draft suggested MGCP > events, others might prefer megaco. A SIP phone may not speak > either, but if it uses RFC2833 it would be easy to send audio/tone > MIME-type inside of INFO. We already have the Accept headers for > this kind of thing. Would you like to see an option-tag defined > for it? > While this not be a bad idea (I might be biased, here...), it does need a bit more work, since carrying RTP packets in INFO would require some way of mapping RTP timestamps to absolute time [RTCP does this] and, less importantly, decide what significance the payload type (PT) field has in this context. Obviously, if you only need a duration, not absolute timing, sticking RTP packets into INFO is sufficient. However, you'd probably not want to use every such RTP packet, only when a new digit has been detected. -- 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 Jun 14 10:25: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 KAA22067 for ; Wed, 14 Jun 2000 10: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 24A9B44391; Wed, 14 Jun 2000 10:13:55 -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 C751644379 for ; Wed, 14 Jun 2000 10:13:50 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA10630; Wed, 14 Jun 2000 15:22:57 +0100 (BST) Message-ID: <39479540.D94316D3@ubiquity.net> Date: Wed, 14 Jun 2000 15:22:56 +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: Hisham Khartabil Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Receiver-tagged Via header References: <394791E4.CD32B405@ericsson.fi> 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 Correct, this is noted towards the end of Appendix G - Changes To Be Made as "recieved-port for NAPT support in Via header field". Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net Hisham Khartabil wrote: > > Hi all, > > The rcf2543bis states in section 6.45.2 > > "Every host that sends or forwards a SIP request adds a Via field indicating the > host’s address. However, it is possible that Network Address Translators (NATs) > change the source address and port of the request (e.g.,from a net-10 to a > globally routable address), in which case the Via header field cannot be relied > on to route replies. To prevent this, a proxy SHOULD check the top-most Via > header field to ensure that it contains the sender’s correct network address, as > seen from that proxy. If the sender’s address is incorrect, the proxy MUST add a > “received” parameter to the Via header field inserted by the previous hop. Such > a modified Via header field is known as a receiver-tagged Via header field." > > So, it is possible that the port is also changed. Yet the syntax for > via-received looks like this: > > via-received = ”received” ”=” host > > shouldn't it be > > via-received = ”received” ”=” hostport > or > via-received = ”received” ”=” host [":" port] > > Thanks, > 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 Wed Jun 14 10:29: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 KAA22341 for ; Wed, 14 Jun 2000 10:29: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 230814439B; Wed, 14 Jun 2000 10:17:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr703217-a.ktchnr1.on.wave.home.com [24.42.217.5]) by lists.bell-labs.com (Postfix) with ESMTP id 0EF2044379 for ; Wed, 14 Jun 2000 10:17:45 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 14 Jun 2000 10:28:50 -0400 (EDT) Date: Wed, 14 Jun 2000 10:28:50 -0400 From: Billy Biggs To: Hisham Khartabil Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Receiver-tagged Via header Message-ID: <20000614102850.A24951@div8.net> References: <394791E4.CD32B405@ericsson.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.0.1i In-Reply-To: <394791E4.CD32B405@ericsson.fi>; from hisham.khartabil@lmf.ericsson.se on Wed, Jun 14, 2000 at 05:08:36PM +0300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 Hisham Khartabil (hisham.khartabil@lmf.ericsson.se): > "Every host that sends or forwards a SIP request adds a Via field indicating the > host’s address. However, it is possible that Network Address Translators (NATs) > change the source address and port of the request (e.g.,from a net-10 to a > globally routable address), in which case the Via header field cannot be relied > on to route replies. To prevent this, a proxy SHOULD check the top-most Via > header field to ensure that it contains the sender’s correct network address, as > seen from that proxy. If the sender’s address is incorrect, the proxy MUST add a > “received” parameter to the Via header field inserted by the previous hop. Such > a modified Via header field is known as a receiver-tagged Via header field." > > So, it is possible that the port is also changed. Yet the syntax for > via-received looks like this: > > via-received = "received" "=" host > > shouldn't it be > > via-received = "received" "=" hostport > or > via-received = "received" "=" host [":" port] Wouldn't that be nice. You could put it in, but it won't help the NAPT problem. Unfortunately, responses in SIP always go back to the port listed in the sent-by of the Via, NOT the source of the message. This means you are free to open a UDP socket just to send one message and then nuke the socket (since the response will come back on your listening socket). This means that you don't care what port you received it on, you just care what port is listed in the sent-by of the Via. If the SIP message went through an NAPT, then the sent-by will list the wrong port anyways, and there won't be much use in indicating which port the message came from. The solution would be to recommend that clients use the same socket (source port) that they receive messages in as the socket they send messages from, and therefore sending a response to the source port will 'usually' work. It might be worth it..... -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 10:39: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 KAA23086 for ; Wed, 14 Jun 2000 10:39: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 62C5344385; Wed, 14 Jun 2000 10:28:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr703217-a.ktchnr1.on.wave.home.com [24.42.217.5]) by lists.bell-labs.com (Postfix) with ESMTP id 9572244379 for ; Wed, 14 Jun 2000 10:28:08 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 14 Jun 2000 10:39:10 -0400 (EDT) Date: Wed, 14 Jun 2000 10:39:10 -0400 From: Billy Biggs To: Neil Deason Cc: Hisham Khartabil , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Receiver-tagged Via header Message-ID: <20000614103910.A24989@div8.net> References: <394791E4.CD32B405@ericsson.fi> <39479540.D94316D3@ubiquity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39479540.D94316D3@ubiquity.net>; from ndeason@ubiquity.net on Wed, Jun 14, 2000 at 03:22:56PM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Neil Deason (ndeason@ubiquity.net): > Correct, this is noted towards the end of Appendix G - Changes To > Be Made as "recieved-port for NAPT support in Via header field". Cute, I hadn't noticed that. The spec would have to be changed to suggest that clients always send from the port that they intend to receive the message on, where possible. That breaks stuff pretty bad. I know my client (for one) opens a new socket for every outgoing message, and then closes it after. This is very very bad, and actually breaks my own NAT ALG (Linux doesn't like it when you do this). I'm going to fix my client, and I guess it's probably a good idea if we discourage unnecessary source port changes. Thoughts? -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 12:22: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 MAA26966 for ; Wed, 14 Jun 2000 12:22: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 AFC6B4433C; Wed, 14 Jun 2000 12:10:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by lists.bell-labs.com (Postfix) with ESMTP id E6F1144336 for ; Wed, 14 Jun 2000 12:10:46 -0400 (EDT) Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 12:21:16 -0400 Message-ID: <4D0A8ECBDC8AD211BD0900A0C9EBC13301C23D1B@rambo.globespan.net> From: Helpdesk MIS To: sip@lists.bell-labs.com Subject: [SIP] Handling multiple Transfer Target Date: Wed, 14 Jun 2000 12:21:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD61C.8FF3706C" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_01BFD61C.8FF3706C Content-Type: text/plain; charset="iso-8859-1" From: rafi Hi, Is it possible for the transferor to inform the transferee to try more than one transfer target serially or simultaneously? Probably one way to do is to include more than one Transfer-to-Header in the TRANSFER request message because transferee take decision based on this field (section 4.6 of draft draft-sparks-sip-cc-transfer-00.txt). May be order of the of each name-addr / addr-spec in Transfer-to-Header implies their priority. Having more than one Transfer-to-Header header is not allowed in the draft, draft-sparks-sip-cc-transfer-00.txt. Please note that contact field in the TRANSFER method is optional. So my understanding is that only Transfer-to-Header is used to identify the transfer target. Thanks Rafi AssadiH.M. Silicon Automation Systems Bangalore, INDIA ------_=_NextPart_001_01BFD61C.8FF3706C Content-Type: text/html; charset="iso-8859-1"
From:  rafi
Hi,
 
           Is it possible for the transferor to inform the transferee
 to try more than one transfer target serially or simultaneously?
 Probably one way to do is to include more than one Transfer-to-Header
 in the TRANSFER request message because transferee take decision
based on this field  (section 4.6 of draft  draft-sparks-sip-cc-transfer-00.txt).
 May be order of the of each name-addr / addr-spec in  Transfer-to-Header implies
their priority. Having more than one Transfer-to-Header header
is not allowed in the draft, draft-sparks-sip-cc-transfer-00.txt.
 
     Please note that contact field in the TRANSFER method is optional. So
my understanding is that only Transfer-to-Header is used to identify the transfer target.
 
 
Thanks
Rafi AssadiH.M.
Silicon Automation Systems
Bangalore, INDIA
 
 
 
------_=_NextPart_001_01BFD61C.8FF3706C-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 12:47: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 MAA27811 for ; Wed, 14 Jun 2000 12:47: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 4143C443A2; Wed, 14 Jun 2000 12:35:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from alpha.telecom-co.net (unknown [200.21.27.100]) by lists.bell-labs.com (Postfix) with ESMTP id 88651443A0 for ; Wed, 14 Jun 2000 12:35:18 -0400 (EDT) Received: from MABOL ([200.21.27.154]) by alpha.telecom-co.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M7J6NFB5; Wed, 14 Jun 2000 11:45:28 -0500 Message-ID: <005a01bfd620$2f40b2d0$9a1b15c8@mabol.telefonia> From: "=?iso-8859-1?Q?Mauricio_Bola=F1os_Arturo?=" To: Date: Wed, 14 Jun 2000 11:47:04 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01BFD5F6.42CFA9C0" 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] information Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_0052_01BFD5F6.42CFA9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello everybody! I'm working in a research group wich is starting a development about = SIP. Probably, we will need somethig help and we would like know whether = this list is properly to do this or there is another developers' list. =20 thanks a lot =20 Mauricio Bola=F1os Arturo ITEC-TELECOM Research Division Bogot=E1 - Colombia ------=_NextPart_000_0052_01BFD5F6.42CFA9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello everybody!
I'm working in a research group wich is starting a = development=20 about SIP. Probably, we will need somethig help and we would like know = whether=20 this list is properly to do this or there is another developers'=20 list.
 
thanks a lot
 
Mauricio Bolaños Arturo
ITEC-TELECOM
Research=20 Division
Bogotá - = Colombia
------=_NextPart_000_0052_01BFD5F6.42CFA9C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 13:57: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 NAA00020 for ; Wed, 14 Jun 2000 13:57: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 916D04438D; Wed, 14 Jun 2000 13:45:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pop-rocks.shoretel.com (pop-rocks.shoretel.com [208.163.34.3]) by lists.bell-labs.com (Postfix) with ESMTP id 6D62344336 for ; Wed, 14 Jun 2000 13:45:49 -0400 (EDT) Received: by pop-rocks.shoretel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 10:53:17 -0700 Message-ID: From: Amar Singh To: sip@lists.bell-labs.com Date: Wed, 14 Jun 2000 10:53:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD629.6A1AC72A" Subject: [SIP] Music On Hold Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_01BFD629.6A1AC72A Content-Type: text/plain; charset="iso-8859-1" Does SIP support Music on hold feature, If so please tell me where do I find its details thanks amar ------_=_NextPart_001_01BFD629.6A1AC72A Content-Type: text/html; charset="iso-8859-1"
Does SIP support Music on hold feature, If so please tell me where do I find its details
 
thanks
amar 
------_=_NextPart_001_01BFD629.6A1AC72A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 15: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 PAA02747 for ; Wed, 14 Jun 2000 15:34: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 DD46C44376; Wed, 14 Jun 2000 15:22: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 C927444336 for ; Wed, 14 Jun 2000 15:22:53 -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 OAA32019; Wed, 14 Jun 2000 14:34:54 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Wed, 14 Jun 2000 14:29:53 -0500 Message-ID: From: "Culpepper, Bert" To: Dave Walker Cc: SIP List Subject: RE: [SIP] Out-of-Band DTMF in SIP Date: Wed, 14 Jun 2000 14:29:50 -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 I understand agreement on MIME-type may be difficult to get, however ISUP and QSIG did ;-) or maybe I'm wrong about that. My ID did discuss Megaco (it actually provides better support than MGCP for DTMF and other terminal events). Anyway, I'd like to have a way to ask the MGC to "turn on" digit collection at the gateway during a call and report the collected digits. I'd also like to ask the MGC/gateway to report any/all detected terminal events. And I'm looking at PSTN-based terminals (telephones) and SIP-based application servers independent of the MGC (or softswitch). Granted, this is a "specialized" network architecture but one that is drawing a great deal of interest by many. Without the above functionality it is nearly impossible to deploy many of today's enhanced services in a VoIP network without having direct control of the gateways. Regards, Bert > -----Original Message----- > From: Dave Walker [mailto:drwalker@ss8networks.com] > Sent: Wednesday, June 14, 2000 9:55 AM > To: Culpepper, Bert > Cc: SIP List > Subject: Re: [SIP] Out-of-Band DTMF in SIP > > > What would you like to see? I don't think that agreement on the > MIME-type is going to be easy to get. Your draft suggested MGCP > events, others might prefer megaco. A SIP phone may not speak > either, but if it uses RFC2833 it would be easy to send audio/tone > MIME-type inside of INFO. We already have the Accept headers for > this kind of thing. Would you like to see an option-tag defined > for it? > > Regards, > > Dave Walker > SS8 Networks > Ottawa, Canada. > > "Culpepper, Bert" wrote: > > > > Hello all, > > > > There have been a couple IDs written a short while back on DTMF transport, > > collection, etc. each using the SIP INFO method. I see out-of-band DTMF > > reporting as a "problem" to be solved to support carrying telecommunications > > traffic over SIP networks. IMO, Out-of-band "event" reporting is needed to > > minimize latency and provide services to PSTN-based users within SIP > > proxy/application servers that do not also "own" the gateways. MGCP and > > Megaco compliant gateways support DTMF collection and out-of-band reporting > > but there is no "agreed upon" method or interworking proposal in SIP/SIP-T > > that I have found. > > > > Is there a solution to this "problem" that I have missed or are others > > interested in addressing this area? As of this week, I've asked for a > > "slot" at the upcoming IETF meeting to present one ID on the subject but > > don't want to take others' time if there's no need. > > > > Thanks, > > Bert > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 15:49: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 PAA03031 for ; Wed, 14 Jun 2000 15:49: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 A0E56443B0; Wed, 14 Jun 2000 15:27: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 AE111443AC for ; Wed, 14 Jun 2000 15:27:12 -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 PAA01556; Wed, 14 Jun 2000 15:38:16 -0400 (EDT) Message-ID: <3947DF28.DF425003@cs.columbia.edu> Date: Wed, 14 Jun 2000 15:38: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: Billy Biggs Cc: Hisham Khartabil , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Receiver-tagged Via header References: <394791E4.CD32B405@ericsson.fi> <20000614102850.A24951@div8.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 Billy Biggs wrote: > > Hisham Khartabil (hisham.khartabil@lmf.ericsson.se): > > > "Every host that sends or forwards a SIP request adds a Via field indicating the > > host?s address. However, it is possible that Network Address Translators (NATs) > > change the source address and port of the request (e.g.,from a net-10 to a > > globally routable address), in which case the Via header field cannot be relied > > on to route replies. To prevent this, a proxy SHOULD check the top-most Via > > header field to ensure that it contains the sender?s correct network address, as > > seen from that proxy. If the sender?s address is incorrect, the proxy MUST add a > > ?received? parameter to the Via header field inserted by the previous hop. Such > > a modified Via header field is known as a receiver-tagged Via header field." > > > > So, it is possible that the port is also changed. Yet the syntax for > > via-received looks like this: > > > > via-received = "received" "=" host > > > > shouldn't it be > > > > via-received = "received" "=" hostport > > or > > via-received = "received" "=" host [":" port] > > Wouldn't that be nice. You could put it in, but it won't help the NAPT > problem. > > Unfortunately, responses in SIP always go back to the port listed in > the sent-by of the Via, NOT the source of the message. This means you > are free to open a UDP socket just to send one message and then nuke the > socket (since the response will come back on your listening socket). > > This means that you don't care what port you received it on, you just > care what port is listed in the sent-by of the Via. If the SIP message > went through an NAPT, then the sent-by will list the wrong port anyways, > and there won't be much use in indicating which port the message came > from. > > The solution would be to recommend that clients use the same socket > (source port) that they receive messages in as the socket they send > messages from, and therefore sending a response to the source port will > 'usually' work. > > It might be worth it..... The only problem is that it does require listening to more sockets (every sending socket), unless you use a single socket to send and receive all messages (that socket would have to be on port 5060, typically). Having a single socket is difficult since it can't be a connected socket (which you need to detect ICMP errors). Thus, effectively, this means that you need to listen to every sending socket. I don't think that's a big deal (thread-based applications probably do that anyway), but it is a minor cost. -- 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 Jun 14 15:53: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 PAA03196 for ; Wed, 14 Jun 2000 15:53: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 15605443C5; Wed, 14 Jun 2000 15:36:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.estara.com (mail.estara.com [205.157.138.159]) by lists.bell-labs.com (Postfix) with ESMTP id 65D52443C0 for ; Wed, 14 Jun 2000 15:36:21 -0400 (EDT) Received: from kmiller ([64.23.131.55]) by mail.estara.com (8.9.3/8.8.8) with SMTP id PAA03803; Wed, 14 Jun 2000 15:46:52 -0400 Message-ID: <007401bfd639$2476d230$37831740@kmiller> From: "Karen Miller" To: "Amar Singh" , References: Subject: Re: [SIP] Music On Hold Date: Wed, 14 Jun 2000 15:45:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01BFD617.9C1B2600" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0071_01BFD617.9C1B2600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the paper "Comparison of H.323 and SIP for IP Telephony Signaling" by = Ismail Dalgic and Hanlin Fang, it says on page 6 "the holding side needs to send an INVITE message to the other side, = indicating a NULL set of receiving capability for any kind of media. MOH can be implemented by = asking an RTSP server to play to the IP address or phone number provided in the RTSP SETUP = request. - Karen ----- Original Message -----=20 From: Amar Singh=20 To: sip@lists.bell-labs.com=20 Sent: Wednesday, June 14, 2000 1:53 PM Subject: [SIP] Music On Hold Does SIP support Music on hold feature, If so please tell me where = do I find its details =20 thanks amar=20 ------=_NextPart_000_0071_01BFD617.9C1B2600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
In the paper "Comparison of H.323 and = SIP for IP=20 Telephony Signaling" by Ismail Dalgic and Hanlin Fang, it says on page=20 6
"the holding side needs to send an = INVITE message=20 to the other side, indicating a NULL set of
receiving capability for any kind of = media. =20 MOH can be implemented by asking an RTSP server to
play to the IP address or phone number = provided in=20 the RTSP SETUP request.
 
- Karen
----- Original Message -----
From:=20 Amar Singh=20
To: sip@lists.bell-labs.com
Sent: Wednesday, June 14, 2000 = 1:53=20 PM
Subject: [SIP] Music On = Hold

Does SIP = support Music=20 on hold feature, If so please tell me where do I find its=20 details
 
thanks
amar 
------=_NextPart_000_0071_01BFD617.9C1B2600-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 15:56: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 PAA03239 for ; Wed, 14 Jun 2000 15: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 58D06443C7; Wed, 14 Jun 2000 15:36: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 0B1D9443C0 for ; Wed, 14 Jun 2000 15:36:37 -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 PAA15770; Wed, 14 Jun 2000 15:48:56 -0400 (EDT) Message-ID: <3947E100.4D6B1049@dynamicsoft.com> Date: Wed, 14 Jun 2000 15:46:08 -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: Amar Singh Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Music On Hold References: 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 Take a look at draft-ietf-sip-183-00.txt. --- Igor Slepchin > Does SIP support Music on hold feature, > If so please tell me where do I find its details > > thanks > amar _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 14 15:59: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 PAA03314 for ; Wed, 14 Jun 2000 15:59: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 82DF3443D1; Wed, 14 Jun 2000 15:40:05 -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 5009E443A3 for ; Wed, 14 Jun 2000 15:40:01 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 12:51:09 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE67A7E0@sd_exchange.nuera.com> From: "Bratakos, Maroula" To: "'Henning Schulzrinne'" , Dave Walker Cc: "Culpepper, Bert" , SIP List Subject: RE: [SIP] Out-of-Band DTMF in SIP Date: Wed, 14 Jun 2000 12:51:07 -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 Even devices that don't speak mgcp or megaco could implement the out-of-band DTMF using the method described in the culpepper draft because it only uses a very small subset of mgcp/megaco commands. I think it is a cleaner method than carrying RTP in the INFO message because you don't have to worry about absolute time or the payload type, which for avt-tones is dynamic. And the mgcp/megaco commands provide a way to request DTMF via INFO to be turned on/off, which is a major plus. I'm not sure how you would turn INFO on/off with RTP. Regards, Maroula Bratakos -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Wednesday, June 14, 2000 7:20 AM To: Dave Walker Cc: Culpepper, Bert; SIP List Subject: Re: [SIP] Out-of-Band DTMF in SIP Dave Walker wrote: > > What would you like to see? I don't think that agreement on the > MIME-type is going to be easy to get. Your draft suggested MGCP > events, others might prefer megaco. A SIP phone may not speak > either, but if it uses RFC2833 it would be easy to send audio/tone > MIME-type inside of INFO. We already have the Accept headers for > this kind of thing. Would you like to see an option-tag defined > for it? > While this not be a bad idea (I might be biased, here...), it does need a bit more work, since carrying RTP packets in INFO would require some way of mapping RTP timestamps to absolute time [RTCP does this] and, less importantly, decide what significance the payload type (PT) field has in this context. Obviously, if you only need a duration, not absolute timing, sticking RTP packets into INFO is sufficient. However, you'd probably not want to use every such RTP packet, only when a new digit has been detected. -- 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 Jun 14 16:01: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 QAA03400 for ; Wed, 14 Jun 2000 16:01: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 2FF4C443B3; Wed, 14 Jun 2000 15:49: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 81648443AA for ; Wed, 14 Jun 2000 15:49: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 QAA03218; Wed, 14 Jun 2000 16:00:34 -0400 (EDT) Message-ID: <3947E462.13244D75@cs.columbia.edu> Date: Wed, 14 Jun 2000 16:00:34 -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: "Bratakos, Maroula" Cc: Dave Walker , "Culpepper, Bert" , SIP List Subject: Re: [SIP] Out-of-Band DTMF in SIP References: <613A6A6A3F09D3118F5C00508B2C24FE67A7E0@sd_exchange.nuera.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 "Bratakos, Maroula" wrote: > > Even devices that don't speak mgcp or megaco could implement the out-of-band > DTMF using the method described in the culpepper draft because it only uses > a very small subset of mgcp/megaco commands. I think it is a cleaner method > than carrying RTP in the INFO message because you don't have to worry about > absolute time or the payload type, which for avt-tones is dynamic. And the Since the PT doesn't matter, you can ignore it. The timestamp is a wash: with MGCP-lite, you don't get any better timing information than the arrival of the MGCP packet, which is what RTP also provides by simply ignoring the timestamp. RTP gives you better relative timing between tones, based on timestamps. > mgcp/megaco commands provide a way to request DTMF via INFO to be turned > on/off, which is a major plus. I'm not sure how you would turn INFO on/off > with RTP. Easy: don't put the MIME type in Accept. It would be more difficult to change your mind mid-call. > > Regards, > Maroula Bratakos > > -- 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 Jun 14 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 QAA03783 for ; Wed, 14 Jun 2000 16:30: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 A2B76443A8; Wed, 14 Jun 2000 16:18:53 -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 0CE9544338 for ; Wed, 14 Jun 2000 16:18:50 -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 PAA32726; Wed, 14 Jun 2000 15:30:56 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Wed, 14 Jun 2000 15:26:07 -0500 Message-ID: From: "Culpepper, Bert" To: Henning Schulzrinne , "Bratakos, Maroula" Cc: Dave Walker , "Culpepper, Bert" , SIP List Subject: RE: [SIP] Out-of-Band DTMF in SIP Date: Wed, 14 Jun 2000 15:25: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 What I'd like to avoid is "processing" RTP during a session for scenarios similar to those in draft-rosenberg-sip-3pcc-00.txt. Although having the SIP network edge device multicast RTP is a possibility (but is this possible when a media gateway doesn't speak SIP?). Thanks, Bert -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Wednesday, June 14, 2000 4:01 PM To: Bratakos, Maroula Cc: Dave Walker; Culpepper, Bert; SIP List Subject: Re: [SIP] Out-of-Band DTMF in SIP "Bratakos, Maroula" wrote: > > Even devices that don't speak mgcp or megaco could implement the out-of-band > DTMF using the method described in the culpepper draft because it only uses > a very small subset of mgcp/megaco commands. I think it is a cleaner method > than carrying RTP in the INFO message because you don't have to worry about > absolute time or the payload type, which for avt-tones is dynamic. And the Since the PT doesn't matter, you can ignore it. The timestamp is a wash: with MGCP-lite, you don't get any better timing information than the arrival of the MGCP packet, which is what RTP also provides by simply ignoring the timestamp. RTP gives you better relative timing between tones, based on timestamps. > mgcp/megaco commands provide a way to request DTMF via INFO to be turned > on/off, which is a major plus. I'm not sure how you would turn INFO on/off > with RTP. Easy: don't put the MIME type in Accept. It would be more difficult to change your mind mid-call. > > Regards, > Maroula Bratakos > > -- 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 Jun 15 00:29: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 AAA11392 for ; Thu, 15 Jun 2000 00:29: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 E0E5544369; Thu, 15 Jun 2000 00:17:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from localhost (unknown [198.223.202.70]) by lists.bell-labs.com (Postfix) with ESMTP id 1C3BD44336 for ; Thu, 15 Jun 2000 00:17:14 -0400 (EDT) Received: from localhost (scott.petrack@localhost) by localhost (8.9.3/8.9.3) with ESMTP id AAA01329; Thu, 15 Jun 2000 00:34:10 -0400 X-Authentication-Warning: localhost: scott.petrack owned process doing -bs Date: Thu, 15 Jun 2000 00:33:09 -0400 (EDT) From: Scott Petrack X-Sender: scott.petrack@localhost To: "Culpepper, Bert" Cc: SIP List Subject: Re: [SIP] Out-of-Band DTMF in SIP 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 This subject has come up periodically over the past 5 years or so. At the risk of beating dead horses: 1. In the Internet we don't really have "bands" to be "out of" or "in to." We have hosts, and the requirement to transport information between (or among) those hosts. You have stated a very common and important requirement -- the need to transport DTMF information from some hosts on the net to "SIP proxy/application servers that do not also 'own' the gateways" -- aka "other hosts". You have stated the requirement that the transport method minimizes latency. There are other requirements you might have mentioned, which have to do with keeping the time synchrony of the DTMF tones aligned to the voice media. (Think of systems where you can "press 1 or say 'yes'", and what might happen if the dtmf tone path gets out of time synch with the voice path.) 2. There is actually an RFC 2833 which describes how to use RTP to transport DTMF tones in such a way that these requirements are met. Please don't think that somehow it is illegal or even strange to use RTP to transport information to a SIP server. If you need the realtime information, you need the realtime information. It is not a difficult payload format to parse, and you might just find that if you do something else, you will miss some point that when into the godzillion too many hours that went into getting agreement on that payload format. I once suggested to someone as a joke that if they really really needed to use SIP, they should just take the RTP packet and put it into a SIP INFO message with a body of type application/rtp. Just like the ISUP-within-SIP people do. I have since heard that this got implemented. Well, at least they used the RTP payload format.... Scott On Tue, 13 Jun 2000, Culpepper, Bert wrote: > Hello all, > > There have been a couple IDs written a short while back on DTMF transport, > collection, etc. each using the SIP INFO method. I see out-of-band DTMF > reporting as a "problem" to be solved to support carrying telecommunications > traffic over SIP networks. IMO, Out-of-band "event" reporting is needed to > minimize latency and provide services to PSTN-based users within SIP > proxy/application servers that do not also "own" the gateways. MGCP and > Megaco compliant gateways support DTMF collection and out-of-band reporting > but there is no "agreed upon" method or interworking proposal in SIP/SIP-T > that I have found. > > Is there a solution to this "problem" that I have missed or are others > interested in addressing this area? As of this week, I've asked for a > "slot" at the upcoming IETF meeting to present one ID on the subject but > don't want to take others' time if there's no need. > > Thanks, > Bert > > > _______________________________________________ > 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 Jun 15 01:29: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 BAA15296 for ; Thu, 15 Jun 2000 01:29: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 7C1CB44383; Thu, 15 Jun 2000 01:17:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 96D9F44339 for ; Thu, 15 Jun 2000 01:17:33 -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.9) with ESMTP id e5F5Shr29408; Thu, 15 Jun 2000 07:28:43 +0200 (MET DST) 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 IAA05414; Thu, 15 Jun 2000 08:28:42 +0300 (EET DST) Message-ID: <3948694F.409BF606@ericsson.fi> Date: Thu, 15 Jun 2000 08:27:43 +0300 From: Hisham Khartabil X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: schulzrinne@cs.columbia.edu, jdrosen@dynamicsoft.com Cc: sip@lists.bell-labs.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Receiver-tagged Via header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 all, The rcf2543bis states in section 6.45.2 "Every host that sends or forwards a SIP request adds a Via field indicating the host’s address. However, it is possible that Network Address Translators (NATs) change the source address and port of the request (e.g.,from a net-10 to a globally routable address), in which case the Via header field cannot be relied on to route replies. To prevent this, a proxy SHOULD check the top-most Via header field to ensure that it contains the sender’s correct network address, as seen from that proxy. If the sender’s address is incorrect, the proxy MUST add a “received” parameter to the Via header field inserted by the previous hop. Such a modified Via header field is known as a receiver-tagged Via header field." So, it is possible that the port is also changed. Yet the syntax for via-received looks like this: via-received = ”received” ”=” host shouldn't it be via-received = ”received” ”=” hostport or via-received = ”received” ”=” host [":" port] Thanks, Hisham _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 02:14: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 CAA23934 for ; Thu, 15 Jun 2000 02:14: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 EA6FA44339; Thu, 15 Jun 2000 02:03:19 -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 1BA0144336 for ; Thu, 15 Jun 2000 02:03:17 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 23:14:32 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Scott Petrack'" Cc: SIP List Subject: RE: [SIP] Out-of-Band DTMF in SIP Date: Wed, 14 Jun 2000 23:14:31 -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 Scott, Here we use in-band and out-of-band to indicate whether the DTMF packets are sent along the media path (with the RTP voice packets) or whether they are sent along the call processing path. You may quite often want to send DTMF notification along _both_ paths. A classic example is with pre-paid calling card systems. When the user makes a call through the system, the RTP media is connected to the remote SIP gateway. For obvious reasons you also need to pass avt-tones RTP packets through to the remote gateway; however, if the user presses and holds the '#' key then they should be taken back to the IVR system. The IVR application server is not in the media path and so the DTMF notification needs to be sent along the SIP call processing path for this to work. The requirements for each DTMF transport path are different. In most cases the INFO DTMF events do not need to be matched to the media timestamp (as they are independent to the media path). Additionally, a low number of INFO DTMF event packets is desirable and so an event driven event package (such as the suggestions in the Culpepper draft) seems a good fit. As other people have said, using RTP avt-tones packets in INFO requests has no way of enabling/disabling INFO event transmission mid-call (so far). Regards, Robert. -----Original Message----- From: Scott Petrack [mailto:scott.petrack@metatel.com] Sent: Thursday, June 15, 2000 12:33 PM To: Culpepper, Bert Cc: SIP List Subject: Re: [SIP] Out-of-Band DTMF in SIP This subject has come up periodically over the past 5 years or so. At the risk of beating dead horses: 1. In the Internet we don't really have "bands" to be "out of" or "in to." We have hosts, and the requirement to transport information between (or among) those hosts. You have stated a very common and important requirement -- the need to transport DTMF information from some hosts on the net to "SIP proxy/application servers that do not also 'own' the gateways" -- aka "other hosts". You have stated the requirement that the transport method minimizes latency. There are other requirements you might have mentioned, which have to do with keeping the time synchrony of the DTMF tones aligned to the voice media. (Think of systems where you can "press 1 or say 'yes'", and what might happen if the dtmf tone path gets out of time synch with the voice path.) 2. There is actually an RFC 2833 which describes how to use RTP to transport DTMF tones in such a way that these requirements are met. Please don't think that somehow it is illegal or even strange to use RTP to transport information to a SIP server. If you need the realtime information, you need the realtime information. It is not a difficult payload format to parse, and you might just find that if you do something else, you will miss some point that when into the godzillion too many hours that went into getting agreement on that payload format. I once suggested to someone as a joke that if they really really needed to use SIP, they should just take the RTP packet and put it into a SIP INFO message with a body of type application/rtp. Just like the ISUP-within-SIP people do. I have since heard that this got implemented. Well, at least they used the RTP payload format.... Scott On Tue, 13 Jun 2000, Culpepper, Bert wrote: > Hello all, > > There have been a couple IDs written a short while back on DTMF transport, > collection, etc. each using the SIP INFO method. I see out-of-band DTMF > reporting as a "problem" to be solved to support carrying telecommunications > traffic over SIP networks. IMO, Out-of-band "event" reporting is needed to > minimize latency and provide services to PSTN-based users within SIP > proxy/application servers that do not also "own" the gateways. MGCP and > Megaco compliant gateways support DTMF collection and out-of-band reporting > but there is no "agreed upon" method or interworking proposal in SIP/SIP-T > that I have found. > > Is there a solution to this "problem" that I have missed or are others > interested in addressing this area? As of this week, I've asked for a > "slot" at the upcoming IETF meeting to present one ID on the subject but > don't want to take others' time if there's no need. > > Thanks, > Bert > > > _______________________________________________ > 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 Jun 15 03:26: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 DAA24579 for ; Thu, 15 Jun 2000 03:26: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 8D74C44378; Thu, 15 Jun 2000 03:14:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3]) by lists.bell-labs.com (Postfix) with ESMTP id 7FFCB44336 for ; Thu, 15 Jun 2000 03:14:50 -0400 (EDT) Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e5F7Pl326963; Thu, 15 Jun 2000 09:25:48 +0200 (MET DST) Message-Id: <200006150725.e5F7Pl326963@bettina.informatik.uni-bremen.de> X-Sender: jo@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 15 Jun 2000 09:24:07 +0200 To: Gonzalo Camarillo , mmusic From: Joerg Ott Cc: sip@lists.bell-labs.com In-Reply-To: <39448358.48155264@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Re: Status of SDPng Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 DAA24579 Gonzalo, the last available draft is draft-ott-mmusic-caps-01.txt which is currently being heavily revised (note that the syntax section in the end is just giving examaples). At the moment we working on completing the modeling aspects taking into account the various signaling protocols available (particularly H.323 and SIP, also MEGACO to some degree) to provide a sufficiently rich yet reasonably simple means for description that can satisfy the needs of all these protocols. We also consider local interaction between system components (e.g. via the Mbus) for the modeling looking into how to model call, conferences, applications (=media sessions), and individual media streams. (this has to fit with SIP, SIP call control services, a future conference control protocol, RTSP, and who knows what). This model then needs to be linked to the concrete syntax (a step that is entirely omitted in the old draft). From a syntax point of view, we are yet undecided. There is good reasoning to stick close to the current SDP syntax to allow smooth introduction of new features into implementations and retain backward compatibility. And this is what we would like to achieve given the increasing installed base of SDP. Nevertheless, a little more expressiveness for grouping, alternatives and the like would be nice to have. There are ideas how you can do this without breaking SDP syntax but the semantics typically changes with such extensions so that a new version numbers allowing for new features does not seem unreasonable either. We plan to publish the revised draft as basis for discussion by the end of June or the beginning of July. Of course, we welcome any input on all of this. Joerg >Hi, > >I would like to know the status of the so called, SDPng. Is there any >draft available about it? Are there folks working on it? Time frame for >this work, goals... > >Thanks, > >Gonzalo >-- >Gonzalo Camarillo Phone : +358 9 299 33 71 >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >Telecom R&D Fax : +358 9 299 30 52 >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >Finland > ------------------------------------------------------------------------------- Joerg Ott                                                  jo@tzi.uni-bremen.de Universitaet Bremen, Germany                              fax + 49 421 218-7000 Center for Computing Technology (TZI)                   voice + 49 421 201-7028 Digital Media and Networks                     http://www.tzi.uni-bremen.de/dmn _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 06:52: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 GAA26355 for ; Thu, 15 Jun 2000 06:52: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 0B6504437B; Thu, 15 Jun 2000 06:41:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 4255844336 for ; Thu, 15 Jun 2000 06:41:21 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e5FAqYr14357 for ; Thu, 15 Jun 2000 12:52:34 +0200 (MET DST) 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 e5FAqYT19475 for ; Thu, 15 Jun 2000 12:52:34 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id MAA02311; Thu, 15 Jun 2000 12:52:29 +0200 (MET DST) Message-ID: <3948B56D.E1821A57@uab.ericsson.se> Date: Thu, 15 Jun 2000 12:52:29 +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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] proxy protocol conversion Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 kind of new in SIP design and have a couple of basic questions regarding proxy protocol conversion. Assuming that "proxy protocol conversion" means something like this: ---transport-1--> proxy ----transport-2--> For which cases are protocol conversion applicable in a proxy: * when the proxy adds more data to the message, so it cannot be stored within a UDP package when proxying the message? * when an outbound proxy receives a UDP package from a UAC, stating transport=tcp in the Request-URI? * when a proxy is configured to always go through another proxy using TCP, disregarding any transport parameters in the SIP message? * when a proxy has one client which only knowns UDP on one side and a client who only knows TCP on the other (ie the attempt to contact the called client with UDP fails)? * ... ? Which of those (if applicable) scenarios was tested at the 4th bakeoff? If "proxy protocol conversions" refers to scenarios like the ones mentioned above, what is it called when you need to do this: caller-client ----request, transport1 ----> server caller-client <-- response, transport2 ---- same server :) (For example if the response for some reason would be bigger than max UDP size). 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 Jun 15 06:55: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 GAA26378 for ; Thu, 15 Jun 2000 06:55: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 BBFF744395; Thu, 15 Jun 2000 06:42:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 6930844390 for ; Thu, 15 Jun 2000 06:42:41 -0400 (EDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e5FArqr15366 for ; Thu, 15 Jun 2000 12:53:52 +0200 (MET DST) 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 e5FArqT19666 for ; Thu, 15 Jun 2000 12:53:52 +0200 (MET DST) Received: from uab.ericsson.se by uabx04c148.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id MAA02316; Thu, 15 Jun 2000 12:53:51 +0200 (MET DST) Message-ID: <3948B5BE.DE04E769@uab.ericsson.se> Date: Thu, 15 Jun 2000 12:53:50 +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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] sequential/parallell forking Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, On what basis does the proxy decide whether to fork in parallell or use sequential forking? 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 Jun 15 10:15: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 KAA02699 for ; Thu, 15 Jun 2000 10:15: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 9C26C4438A; Thu, 15 Jun 2000 10:03:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by lists.bell-labs.com (Postfix) with ESMTP id 534A244336 for ; Thu, 15 Jun 2000 10:03:18 -0400 (EDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id HAA24703; Thu, 15 Jun 2000 07:14:31 -0700 (PDT) From: Anoop_Tripathi@3com.com Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id HAA26505; Thu, 15 Jun 2000 07:14:20 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882568FF.004E0933 ; Thu, 15 Jun 2000 07:12:21 -0700 X-Lotus-FromDomain: 3COM To: Loita Jahnsson Cc: sip@lists.bell-labs.com Message-ID: <882568FF.004E070F.00@hqoutbound.ops.3com.com> Date: Thu, 15 Jun 2000 09:12:02 -0500 Subject: Re: [SIP] sequential/parallell forking 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 Based on the internal policies for the network/originating user/dialed number etc. Anoop Loita Jahnsson on 06/15/2000 05:53:50 AM Sent by: Loita Jahnsson To: sip@lists.bell-labs.com cc: (Anoop Tripathi/MW/US/3Com) Subject: [SIP] sequential/parallell forking Hi, On what basis does the proxy decide whether to fork in parallell or use sequential forking? Regards, Loita Jahnsson _______________________________________________ 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 Jun 15 10:25: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 KAA02933 for ; Thu, 15 Jun 2000 10:25: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 E570A44390; Thu, 15 Jun 2000 10:14: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 7E0D644336 for ; Thu, 15 Jun 2000 10:14:08 -0400 (EDT) Received: from dynamicsoft.com (1Cust213.tnt2.freehold.nj.da.uu.net [63.17.114.213]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA19215; Thu, 15 Jun 2000 10:26:30 -0400 (EDT) Message-ID: <3948E76F.1A23BE8E@dynamicsoft.com> Date: Thu, 15 Jun 2000 10:25:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anoop_Tripathi@3com.com Cc: Loita Jahnsson , sip@lists.bell-labs.com Subject: Re: [SIP] sequential/parallell forking References: <882568FF.004E070F.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 They can also be based on caller preferences expressed with the Request-Disposition header, defined in the caller preferences extension. Honoring this preference is, of course, at the policy discretion of the proxy server. -Jonathan R. Anoop_Tripathi@3com.com wrote: > > Based on the internal policies for the network/originating user/dialed number > etc. > > Anoop > > Loita Jahnsson on 06/15/2000 05:53:50 AM > > Sent by: Loita Jahnsson > > To: sip@lists.bell-labs.com > cc: (Anoop Tripathi/MW/US/3Com) > Subject: [SIP] sequential/parallell forking > > Hi, > > On what basis does the proxy decide whether to fork > in parallell or use sequential forking? > > Regards, > > Loita Jahnsson > > _______________________________________________ > 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 Thu Jun 15 12:14: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 MAA06420 for ; Thu, 15 Jun 2000 12:14: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 7295444383; Thu, 15 Jun 2000 12:02:00 -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 E0DD544339 for ; Thu, 15 Jun 2000 12:01:56 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Thu, 15 Jun 2000 11:11:40 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 11:12:20 -0500 Message-ID: <2E532B03F035D3119AF40000F80932C32073E4@crchy28d.us.nortel.com> From: "William Lee" To: sip@lists.bell-labs.com Date: Thu, 15 Jun 2000 11:12:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD6E4.7AA4210C" Subject: [SIP] Question on Tag for To and From headers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_01BFD6E4.7AA4210C Content-Type: text/plain The syntax for the To and the From headers is: ( name-addr | addr-spec ) *(";"addr-params) where addr-params = tag-param | addr-extension Does this mean that you can have zero or more tag-params followed or inter-mingled among zero or more addr-extensions? This is very unclear. There is a similar situation with the Server and User-Agent headers 1*( product | comment ). Is there a one to one relationship between product and comment, or can there be say one product followed by several comments, etc. ? ------_=_NextPart_001_01BFD6E4.7AA4210C Content-Type: text/html Content-Transfer-Encoding: quoted-printable Question on Tag for To and From headers

The syntax for the To and the From = headers is: ( name-addr | addr-spec ) *(";"addr-params) = where
addr-params =3D tag-param | = addr-extension

Does this mean that you can have zero = or more tag-params followed or inter-mingled among zero or more
addr-extensions? This is very = unclear.


There is a similar situation with the = Server and User-Agent headers 1*( product | comment ).  Is there = a
one to one relationship between = product and comment, or can there be say one product followed by
several comments, etc. ?




------_=_NextPart_001_01BFD6E4.7AA4210C-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 12:16: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 MAA06534 for ; Thu, 15 Jun 2000 12:16: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 BE2C94438F; Thu, 15 Jun 2000 12:05:04 -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 10FAB4437B for ; Thu, 15 Jun 2000 12:05:01 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA29431 for ; Thu, 15 Jun 2000 11:16:11 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA13373 for ; Thu, 15 Jun 2000 11:16:10 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA19679 for ; Thu, 15 Jun 2000 11:16:10 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA12031 for sip@lists.bell-labs.com; Thu, 15 Jun 2000 11:16:09 -0500 (CDT) Message-Id: <200006151616.LAA12031@b04a24.exu.ericsson.se> To: sip@lists.bell-labs.com Date: Thu, 15 Jun 2000 11:16:09 -0500 (CDT) From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Static Images Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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'm trying to get a feeling for what most people think the most appropriate way of sending static pictures (generally, at a frame rate too slow to constitute animation, and definitely not at a fixed frequency) in the course of a SIP session. For a frame of reference, some of you may have seen consumer phones that use some extrodinarily slow and proprietary transfer protocol to send greyscale images during the course of a phone conversation. ("I've got a picture of Annie right here. She's just started walking. I'll send it to you" sort of applications). As I see it, there are a few options for doing this sort of thing: 1) In the signalling path: use a SIP INFO (or similar) message with a type image/jpeg body. Since SIP isn't really meant as a transport protocol, this doesn't necessarily seem appropriate. 2) As a new, variable frame-rate video codec with packet-loss correction (without multiple frames per image, packet loss can be a serious issue). 3) By using an existing video codec, but just sending the same frame over and over (until a new picture is sent). This is, of course, a bit heavyweight for what should be a simple application. 4) As a short-lived TCP "stream" set up with a re-INVITE message; this would require an additional transport type to be defined for SDP, but could easily look something like: INVITE sip:ejsmith@hotmail.com SIP/2.0 To: "Mom and Dad" ;tag=abcde From: "John Smith" ;tag=99999 Contact: Call-ID: 31f-39046c6b-119d5b79-1@138.85.60.124 CSeq: 9986 INVITE Accept: application/sdp Content-Type: application/sdp Content-Length: 119 v=0 o=jsmith 95659121152363266 0 IN IP4 138.85.60.124 s=- p=+1 214 555 1212 c=IN IP4 138.85.60.124 t=0 0 m=audio 5000 RTP/AVP 0 m=image 5098 tcp jpeg a=sendonly 5) As a special function of a whiteboard program. I consider this punting, as it wouldn't work very well for the embeded type phones I mention in the introduction to this mail. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 12:27: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 MAA06859 for ; Thu, 15 Jun 2000 12:27: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 4F94844390; Thu, 15 Jun 2000 12:15: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 39F8044339 for ; Thu, 15 Jun 2000 12:15:51 -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 MAA22658; Thu, 15 Jun 2000 12:24:40 -0400 (EDT) Message-ID: <39490348.CE8E3E85@cs.columbia.edu> Date: Thu, 15 Jun 2000 12:24:40 -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 Lee Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Question on Tag for To and From headers References: <2E532B03F035D3119AF40000F80932C32073E4@crchy28d.us.nortel.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 Lee wrote: > > The syntax for the To and the From headers is: ( name-addr | addr-spec > ) *(";"addr-params) where > addr-params = tag-param | addr-extension > > Does this mean that you can have zero or more tag-params followed or > inter-mingled among zero or more > addr-extensions? This is very unclear. Yes, that's what the BNF says. As has been discussed here in different contexts, BNFs are not good at (and not meant for) conveying semantic restrictions such as "no duplication". That said, since there's only one tag, it makes sense to label it as [ tag-param ] *addr-extension > > There is a similar situation with the Server and User-Agent headers > 1*( product | comment ). Is there a > one to one relationship between product and comment, or can there be > say one product followed by > several comments, etc. ? Yes. -- 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 Jun 15 12:28: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 MAA06898 for ; Thu, 15 Jun 2000 12:28: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 F267F443A9; Thu, 15 Jun 2000 12:16:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id A5E90443A7 for ; Thu, 15 Jun 2000 12:15:57 -0400 (EDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 15 Jun 2000 17:27:01 +0100 To: "Adam B. Roach" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Static Images In-reply-to: Your message of "Thu, 15 Jun 2000 11:16:09 CDT." <200006151616.LAA12031@b04a24.exu.ericsson.se> Date: Thu, 15 Jun 2000 17:27:00 +0100 Message-ID: <6847.961086420@cs.ucl.ac.uk> 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 --> "Adam B. Roach" writes: >I'm trying to get a feeling for what most people think the most >appropriate way of sending static pictures (generally, at a frame >rate too slow to constitute animation, and definitely not at a >fixed frequency) in the course of a SIP session. ... >As I see it, there are a few options for doing this sort of thing: ... >4) As a short-lived TCP "stream" set up with a re-INVITE message; > this would require an additional transport type to be defined > for SDP, but could easily look something like: > > INVITE sip:ejsmith@hotmail.com SIP/2.0 > To: "Mom and Dad" ;tag=abcde > From: "John Smith" ;tag=99999 > Contact: > Call-ID: 31f-39046c6b-119d5b79-1@138.85.60.124 > CSeq: 9986 INVITE > Accept: application/sdp > Content-Type: application/sdp > Content-Length: 119 > > v=0 > o=jsmith 95659121152363266 0 IN IP4 138.85.60.124 > s=- > p=+1 214 555 1212 > c=IN IP4 138.85.60.124 > t=0 0 > m=audio 5000 RTP/AVP 0 > m=image 5098 tcp jpeg > a=sendonly Is it too disgusting to use... INVITE sip:ejsmith@hotmail.com SIP/2.0 To: "Mom and Dad" ;tag=abcde From: "John Smith" ;tag=99999 Contact: Call-ID: 31f-39046c6b-119d5b79-1@138.85.60.124 CSeq: 9986 INVITE Accept: application/sdp Content-Type: application/sdp Content-Length: 119 v=0 o=jsmith 95659121152363266 0 IN IP4 138.85.60.124 s=- p=+1 214 555 1212 c=IN IP4 138.85.60.124 t=0 0 m=audio 5000 RTP/AVP 0 m=image 80 http jpeg a=sendonly to indicate fetchming image/jpeg using http? Weird, but fits existing usage of the m= line... 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 Jun 15 12:32: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 MAA07082 for ; Thu, 15 Jun 2000 12:32: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 63D1D443B3; Thu, 15 Jun 2000 12:19:46 -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 918C144378 for ; Thu, 15 Jun 2000 12:19:42 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA04954; Thu, 15 Jun 2000 11:30:57 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA17175; Thu, 15 Jun 2000 11:30:57 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA20506; Thu, 15 Jun 2000 11:30:56 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA12052; Thu, 15 Jun 2000 11:30:56 -0500 (CDT) Message-Id: <200006151630.LAA12052@b04a24.exu.ericsson.se> Subject: Re: [SIP] CSeq matching and multiple requests. To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Thu, 15 Jun 2000 11:30:56 -0500 (CDT) Cc: rfairlie@nuera.com (Fairlie-Cuninghame Robert), sip@lists.bell-labs.com ('sip@lists.bell-labs.com') In-Reply-To: <394702DB.3C479937@dynamicsoft.com> from "Jonathan Rosenberg" at Jun 13, 2000 11:58:19 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 have missed some crucial piece of text then I think it should be moved >> to a more logical place in the draft (eg Section 11). Do we need multiple >> outstanding requests (per UA) anyway ? > >It would be nice to hear if anyone has any concrete examples of a need >for this. There are some thoughts that such a need might arise during ISUP tunneling for some national variants of ISUP. From a practical point of view, you also have the issue that PRACKs are also being sent and completeing before the INVITE receives a final response. I would strongly prefer that PRACK isn't an exception to an overall rule of "one pending request per direction". The simple way to get around the problem being described is to say that you can't send a new request until the previous request has received a response. Note the subtle difference: not completed, just received a response (including provisionals). This may cause problems at proxies, who can generate 100s without the far end necessarily receiving the message. You *could* have the proxies hold onto the messages until the next hop responds to the previous messages to ensure in-order delivery, but this seems overly complicated. Perhaps, as in most other cases, we can just say that 100 responses are an exception? -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 13:00: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 NAA07990 for ; Thu, 15 Jun 2000 13:00: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 2FF4044378; Thu, 15 Jun 2000 12:49:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr703217-a.ktchnr1.on.wave.home.com [24.42.217.5]) by lists.bell-labs.com (Postfix) with ESMTP id 5C8B944336 for ; Thu, 15 Jun 2000 12:49:06 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 15 Jun 2000 13:00:09 -0400 (EDT) Date: Thu, 15 Jun 2000 13:00:09 -0400 From: Billy Biggs To: Colin Perkins Cc: "Adam B. Roach" , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images Message-ID: <20000615130009.B27495@div8.net> References: <200006151616.LAA12031@b04a24.exu.ericsson.se> <6847.961086420@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <6847.961086420@cs.ucl.ac.uk>; from C.Perkins@cs.ucl.ac.uk on Thu, Jun 15, 2000 at 05:27:00PM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Colin Perkins (C.Perkins@cs.ucl.ac.uk): > --> "Adam B. Roach" writes: > >I'm trying to get a feeling for what most people think the most > >appropriate way of sending static pictures (generally, at a frame > >rate too slow to constitute animation, and definitely not at a > >fixed frequency) in the course of a SIP session. > ... > >As I see it, there are a few options for doing this sort of thing: > ... > >4) As a short-lived TCP "stream" set up with a re-INVITE message; > > this would require an additional transport type to be defined > > for SDP, but could easily look something like: > > > > [...] > > m=image 5098 tcp jpeg > > a=sendonly > > Is it too disgusting to use... > > [...] > m=image 80 http jpeg > a=sendonly > > to indicate fetchming image/jpeg using http? Weird, but fits existing usage > of the m= line... I agree that it is definitely a session description issue and not a SIP issue. You need to define a protocol for the exchange of a slow stream of images. One method is to use http. Then you need to describe it in the description protocol. It really is a new protocol, since you want to be able to indicate when the next image is available, if at all, etc... Definitely do-able. This is one of the applications I was working on last summer when I was investigating alternate description protocols. -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 13: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 NAA08206 for ; Thu, 15 Jun 2000 13:05: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 4AA9B443AE; Thu, 15 Jun 2000 12:53:43 -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 C0FF44438D for ; Thu, 15 Jun 2000 12:53: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 NAA25722; Thu, 15 Jun 2000 13:04:48 -0400 (EDT) Message-ID: <39490CB0.52860D1F@cs.columbia.edu> Date: Thu, 15 Jun 2000 13:04:48 -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: Billy Biggs Cc: Colin Perkins , "Adam B. Roach" , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006151616.LAA12031@b04a24.exu.ericsson.se> <6847.961086420@cs.ucl.ac.uk> <20000615130009.B27495@div8.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 Why couldn't an RTP-over-TCP stream be used here? Telling the client to go fetch it seems strange, particularly since it also requires that you somehow upload the image to another server or run a web server on your PC/phone. -- 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 Jun 15 13:07: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 NAA08257 for ; Thu, 15 Jun 2000 13:07: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 96DE8443A9; Thu, 15 Jun 2000 12:55:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from turin.trillium.com (turin.trillium.com [206.216.108.218]) by lists.bell-labs.com (Postfix) with ESMTP id 49B5C44336 for ; Thu, 15 Jun 2000 12:55:49 -0400 (EDT) Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 15 Jun 2000 10:19:40 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id KAA09553 for ; Thu, 15 Jun 2000 10:06:51 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 10:04:41 -0700 Message-ID: <8BBD33A986C5D311804000902719FF5D3798EE@aega.trillium.com> From: Aseem Agarwal To: "'sip@lists.bell-labs.com'" Cc: Srini Beereddy Date: Thu, 15 Jun 2000 10:04:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD6EB.CB74C7B0" Subject: [SIP] Looking for SIP client and server 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 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_01BFD6EB.CB74C7B0 Content-Type: text/plain; charset="iso-8859-1" Hi, I am looking for a SIP client and server implementations which I can use to establish a SIP call (including media). I came across a few freely available stacks/libraries but no integrated product (something like NetMeeting for H.323). Is anyone aware of any such product ? Any help would be appreciated. Regards, aseem ------_=_NextPart_001_01BFD6EB.CB74C7B0 Content-Type: text/html; charset="iso-8859-1" Question on Tag for To and From headers
Hi,
   I am looking for a SIP client and server implementations which I can use to establish a SIP
call (including media). I came across a few freely available stacks/libraries but no  integrated
product (something like NetMeeting for H.323).
Is anyone aware of any such product ? Any help would be appreciated.
 
Regards,
aseem
------_=_NextPart_001_01BFD6EB.CB74C7B0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 13:22: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 NAA08983 for ; Thu, 15 Jun 2000 13:22: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 0B886443B0; Thu, 15 Jun 2000 13:10:30 -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 00E1644336 for ; Thu, 15 Jun 2000 13:10:26 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Thu, 15 Jun 2000 13:16:02 -0400 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M857S5D3; Thu, 15 Jun 2000 13:16:00 -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.2650.21) id LCMSP77B; Thu, 15 Jun 2000 13:16:01 -0400 Message-ID: <39491035.9550A07C@americasm01.nt.com> Date: Thu, 15 Jun 2000 13:19:49 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: "William Lee" , sip@lists.bell-labs.com Subject: Re: [SIP] Question on Tag for To and From headers References: <2E532B03F035D3119AF40000F80932C32073E4@crchy28d.us.nortel.com> <39490348.CE8E3E85@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------CAA940D6F2510F529BEC7414" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------CAA940D6F2510F529BEC7414 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'd even argue for taking it one step further. Since tag-param fits into the syntactic defintion of addr-extension, why not: ( name-addr | addr-spec ) *(";"addr-extension) and leave it up to the semantic desription of what address parameters are allowed, what are the semantics of duplicates, and what they actually mean at the application level (as opposed to what they look like). I generally think that applying semantic restrictions in formal syntax specifications is not a good idea, even though it's sometimes possible. Rick Workman Nortel Networks Henning Schulzrinne wrote: > > William Lee wrote: > > > > The syntax for the To and the From headers is: ( name-addr | addr-spec > > ) *(";"addr-params) where > > addr-params = tag-param | addr-extension > > > > Does this mean that you can have zero or more tag-params followed or > > inter-mingled among zero or more > > addr-extensions? This is very unclear. > > Yes, that's what the BNF says. As has been discussed here in different > contexts, BNFs are not good at (and not meant for) conveying semantic > restrictions such as "no duplication". That said, since there's only one > tag, it makes sense to label it as > > [ tag-param ] *addr-extension > > > > > There is a similar situation with the Server and User-Agent headers > > 1*( product | comment ). Is there a > > one to one relationship between product and comment, or can there be > > say one product followed by > > several comments, etc. ? > > Yes. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------CAA940D6F2510F529BEC7414 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I'd even argue for taking it one step further. Since tag-param fits into the syntactic defintion of addr-extension, why not:

( name-addr | addr-spec ) *(";"addr-extension)

and leave it up to the semantic desription of what address parameters are allowed, what are the semantics of duplicates, and what they actually mean at the application level (as opposed to what they look like). I generally think that applying semantic restrictions in formal syntax specifications is not a good idea, even though it's sometimes possible.

Rick Workman
Nortel Networks
 

Henning Schulzrinne wrote:

> William Lee wrote:
>
> The syntax for the To and the From headers is: ( name-addr | addr-spec
> ) *(";"addr-params) where
> addr-params = tag-param | addr-extension
>
> Does this mean that you can have zero or more tag-params followed or
> inter-mingled among zero or more
> addr-extensions? This is very unclear.

Yes, that's what the BNF says. As has been discussed here in different
contexts, BNFs are not good at (and not meant for) conveying semantic
restrictions such as "no duplication". That said, since there's only one
tag, it makes sense to label it as

[ tag-param ] *addr-extension

>
> There is a similar situation with the Server and User-Agent headers
> 1*( product | comment ).  Is there a
> one to one relationship between product and comment, or can there be
> say one product followed by
> several comments, etc. ?

Yes.

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

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

--------------CAA940D6F2510F529BEC7414-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 13:25: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 NAA09098 for ; Thu, 15 Jun 2000 13:25: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 08DF6443B8; Thu, 15 Jun 2000 13:13:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by lists.bell-labs.com (Postfix) with ESMTP id 1F2D0443B6 for ; Thu, 15 Jun 2000 13:13:49 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id UAA20263; Thu, 15 Jun 2000 20:23:17 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14665.4357.306555.240051@lohi.eng.telia.fi> Date: Thu, 15 Jun 2000 20:23:17 +0300 (EEST) To: Aseem Agarwal Cc: "'sip@lists.bell-labs.com'" , Srini Beereddy Subject: [SIP] Looking for SIP client and server implementation In-Reply-To: <8BBD33A986C5D311804000902719FF5D3798EE@aega.trillium.com> References: <8BBD33A986C5D311804000902719FF5D3798EE@aega.trillium.com> X-Mailer: VM 6.75 under Emacs 19.34.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 i'm using kphone from kdenonbeta. see http://www.div8.net/dissipate/. it runs fine on linux. i don't know nor care about bill gates uas. send him email and ask to include sip support in the next version of netmeeting. -- juha _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 13:32: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 NAA09386 for ; Thu, 15 Jun 2000 13:32: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 EF914443B2; Thu, 15 Jun 2000 13:20: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 D82B344336 for ; Thu, 15 Jun 2000 13:20:32 -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 NAA27573; Thu, 15 Jun 2000 13:28:25 -0400 (EDT) Message-ID: <39491239.2B4F62D0@cs.columbia.edu> Date: Thu, 15 Jun 2000 13:28: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: Aseem Agarwal Cc: "'sip@lists.bell-labs.com'" , Srini Beereddy Subject: Re: [SIP] Looking for SIP client and server implementation References: <8BBD33A986C5D311804000902719FF5D3798EE@aega.trillium.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 > Aseem Agarwal wrote: > > Hi, > I am looking for a SIP client and server implementations which I > can use to establish a SIP > call (including media). I came across a few freely available > stacks/libraries but no integrated > product (something like NetMeeting for H.323). > Is anyone aware of any such product ? Any help would be appreciated. See http://www.cs.columbia.edu/~hgs/sip for a list. > > Regards, > aseem -- 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 Jun 15 14: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 OAA11593 for ; Thu, 15 Jun 2000 14:46: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 0B41744383; Thu, 15 Jun 2000 14:34: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 8E5DA44336 for ; Thu, 15 Jun 2000 14:34:22 -0400 (EDT) Received: from fokus.gmd.de (shaky [193.175.132.94]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id UAA26595; Thu, 15 Jun 2000 20:43:21 +0200 (MET DST) Message-ID: <39492446.CA94C7C6@fokus.gmd.de> Date: Thu, 15 Jun 2000 20:45:26 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: kuthan@fokus.gmd.de Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Firewall Control Protocol Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, I submitted the Firewall Control Protocol (FCP) Internet Draft to IETF tonight. This protocol may be used by SIP proxies to open pinholes in firewalls so that the SIP sessions get through them. Feel free to review/comment/etc. Until the draft appears in the IETF directory, it is available at http://www.fokus.gmd.de/research/cc/glone/employees/jiri.kuthan/private/fcp/draft-kuthan-fcp-01.txt The FCP discussion is taking place at the foglamps mailing list: - foglamps@lists.panix.com - To subscribe, send email to majordomo@lists.panix.com with “subscribe foglamps” in the body of message Regards, Jiri -- Jiri Kuthan Phone: +49-30-3463 7271 GMD FOKUS Fax : +49-30-3463 8271 Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de D-10589 Berlin, Germany WWW : http://www.fokus.gmd.de/usr/kuthan -- Curious about Internet Telephony? Check http://www.fokus.gmd.de/glone/projects/ipt today! _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 14: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 OAA11714 for ; Thu, 15 Jun 2000 14: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 85BCB443B2; Thu, 15 Jun 2000 14:39: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 5D328443B0 for ; Thu, 15 Jun 2000 14:39: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 OAA04761; Thu, 15 Jun 2000 14:50:52 -0400 (EDT) Message-ID: <3949258C.77E3B44C@cs.columbia.edu> Date: Thu, 15 Jun 2000 14:50: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: Jonathan Rosenberg Cc: Sunitha Kumar , SIPbell-labs Subject: Re: [SIP] Clarification on the proxy behaviour. References: <3946D8F3.86230CC6@vovida.com> <394706C6.34F12577@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 Loop detection is described in 12.3.1 of the 2543bis draft. Suggestions for improved wording are welcome. I added a reference to this section in the Via description. -- 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 Jun 15 16:40: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 QAA14159 for ; Thu, 15 Jun 2000 16:40: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 C57A5443AE; Thu, 15 Jun 2000 16:28: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 C7B4E44336 for ; Thu, 15 Jun 2000 16:28:49 -0400 (EDT) Received: from dynamicsoft.com (1Cust213.tnt2.freehold.nj.da.uu.net [63.17.114.213]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA22917; Thu, 15 Jun 2000 16:41:18 -0400 (EDT) Message-ID: <39493F3E.B7753B1F@dynamicsoft.com> Date: Thu, 15 Jun 2000 16:40:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IMPP WG Cc: sip , rem-conf@es.net, "iptel, list" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] proposal for IMPP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, Some colleagues and I have put together a suite of protocols for IMPP, based partly on SIP. Its actually seven separate drafts, althouth the core is just two. They have been submitted to the I-D editor, but you can grab them right now from: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-presence-00.txt Core presence protocol. We've written it to be understandable by non SIP experts, and to also indicate what parts of SIP you do and don't need for presence. Don't be scared by the size (70 pages), nearly half are example message flows. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-im-00.txt Core IM protocol. Also written to be both a tutorial on SIP and explain how to do IM. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-qauth-00.txt A mini-protocol for authorizing subscriptions, to support, among other things, the ability for subscriptions to happen when the presentity is offline. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-pidf-00.txt An XML PIDF format, optional in our architecture. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-lpidf-00.txt A really thin pidf, good for wireless devices, since it uses the same parser SIP uses. This is mandatory to support in our architecture. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-watcherinfo-00.txt A format for watcher info. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-buddylist-00.txt Something we never discussed on the list before; a buddylist document, much akin to bookmarks, which you can store on a server. This way, when you go to a different machine, you can fetch your buddylist, and get your presence services there. Comments and questions are welcome, of course. -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 Jun 15 18:19: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 SAA15941 for ; Thu, 15 Jun 2000 18:19: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 41512443BB; Thu, 15 Jun 2000 18:07:51 -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 AC6CB44336 for ; Thu, 15 Jun 2000 18:07:47 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 15:19:03 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE7F35E6@sd_exchange.nuera.com> From: "Fox, Mike" To: Jonathan Rosenberg , IMPP WG Cc: sip , rem-conf@es.net, "iptel, list" Date: Thu, 15 Jun 2000 15:18:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: proposal for IMPP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol may be the right way. Call it SIP Control by Unified Methods. SOAP SCUM 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 Jun 15 18:32: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 SAA16319 for ; Thu, 15 Jun 2000 18:32: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 763D3443D3; Thu, 15 Jun 2000 18:18:06 -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 49C4E443CB for ; Thu, 15 Jun 2000 18:18:01 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id RAA07985; Thu, 15 Jun 2000 17:29:17 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id RAA18007; Thu, 15 Jun 2000 17:29:16 -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 RAA09689; Thu, 15 Jun 2000 17:29:16 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id RAA00788; Thu, 15 Jun 2000 17:29:15 -0500 (CDT) Date: Thu, 15 Jun 2000 17:29:15 -0500 (CDT) Message-Id: <200006152229.RAA00788@b04a45.exu.ericsson.se> To: vektor@div8.net, schulzrinne@cs.columbia.edu Subject: Re: [SIP] Static Images Cc: C.Perkins@cs.ucl.ac.uk, Adam.Roach@Ericsson.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 X-BeenThere: sip@lists.bell-labs.com > Why couldn't an RTP-over-TCP stream be used here? Telling the client to > go fetch it seems strange, particularly since it also requires that you > somehow upload the image to another server or run a web server on your > PC/phone. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > That is of course assuming that you don't support HTTP over port 5060 :) If you can build SIP, why not HTTP as well? (I'm being sarcastic of course. HTTP 1.1 is not to be underestimated) -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 15 19:21: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 TAA17605 for ; Thu, 15 Jun 2000 19:21: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 0226B443C8; Thu, 15 Jun 2000 19:09:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 0475D44383 for ; Thu, 15 Jun 2000 19:09:31 -0400 (EDT) Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Fri, 16 Jun 2000 00:20:31 +0100 Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id XAA09457; Thu, 15 Jun 2000 23:38:45 +0100 Message-Id: <200006152238.XAA09457@csperkins.demon.co.uk> To: Henning Schulzrinne Cc: Billy Biggs , "Adam B. Roach" , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images In-Reply-To: Message from Henning Schulzrinne of "Thu, 15 Jun 2000 13:04:48 EDT." <39490CB0.52860D1F@cs.columbia.edu> Date: Thu, 15 Jun 2000 23:38:45 +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 --> Henning Schulzrinne writes: >Why couldn't an RTP-over-TCP stream be used here? Telling the client to >go fetch it seems strange, particularly since it also requires that you >somehow upload the image to another server or run a web server on your >PC/phone. Yeah, that's probably a better solution for the audio with accompanying video snapshot scenario... We probably have to think about how to include downloadable content for other scenarios, but I guess that's something for the SDP++ folks to worry about, not a SIP problem. 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 Jun 15 23:53: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 XAA23734 for ; Thu, 15 Jun 2000 23: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 AAC1B44395; Thu, 15 Jun 2000 23:41:38 -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 6F63444377 for ; Thu, 15 Jun 2000 23:41:34 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 20:52:59 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" , Billy Biggs Cc: Colin Perkins , "Adam B. Roach" , sip@lists.bell-labs.com Subject: RE: [SIP] Static Images Date: Thu, 15 Jun 2000 20:52:55 -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 Do you think that will require a new SDP profile (like RTP/AVP) or does an adequate "tcp" SDP profile already exist ? If this is a multiparty SIP conference you've got the problem of reliable multicast transport and so simple tcp may not cut it (there are other multicast transport protocols which address this problem). Cheers, Robert. -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Friday, June 16, 2000 1:05 AM To: Billy Biggs Cc: Colin Perkins; Adam B. Roach; sip@lists.bell-labs.com Subject: Re: [SIP] Static Images Why couldn't an RTP-over-TCP stream be used here? Telling the client to go fetch it seems strange, particularly since it also requires that you somehow upload the image to another server or run a web server on your PC/phone. -- 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 Jun 16 03:32: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 DAA07277 for ; Fri, 16 Jun 2000 03:32: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 45B5244377; Fri, 16 Jun 2000 03:21:12 -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 10E4844375 for ; Fri, 16 Jun 2000 03:21:09 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id CAA08988; Fri, 16 Jun 2000 02:32:28 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id CAA19057; Fri, 16 Jun 2000 02:32:28 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id CAA26150; Fri, 16 Jun 2000 02:32:27 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id CAA13522; Fri, 16 Jun 2000 02:32:27 -0500 (CDT) Message-Id: <200006160732.CAA13522@b04a24.exu.ericsson.se> Subject: Re: [SIP] Static Images To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Fri, 16 Jun 2000 02:32:26 -0500 (CDT) Cc: vektor@div8.net (Billy Biggs), C.Perkins@cs.ucl.ac.uk (Colin Perkins), sip@lists.bell-labs.com In-Reply-To: <39490CB0.52860D1F@cs.columbia.edu> from "Henning Schulzrinne" at Jun 15, 2000 01:04:48 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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: >Why couldn't an RTP-over-TCP stream be used here? Telling the client to >go fetch it seems strange, particularly since it also requires that you >somehow upload the image to another server or run a web server on your >PC/phone. If you're using TCP, I don't quite see what RTP gains you. I agree with Sean that HTTP may be a bit heavy. Anyway, I offered 5 scenarios, and everyone seems to have latched onto one. If I don't hear otherwise, I'll assume that the method of doing something special in the SDP to indicate a TCP connection of some sort (possibly with some protocol on top of it, like RTP or HTTP) is the preferred choice, and take this discussion to MMUSIC. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 16 03:40: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 DAA07323 for ; Fri, 16 Jun 2000 03:40: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 EA6E8443AC; Fri, 16 Jun 2000 03:27:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id A409844375 for ; Fri, 16 Jun 2000 03:27:04 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id NAA09410; Fri, 16 Jun 2000 13:06:41 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 16 Jun 2000 13:06:39 +0000 (IST) Received: from localhost (srinath@localhost) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id NAA00203; Fri, 16 Jun 2000 13:05:50 +0530 (IST) Date: Fri, 16 Jun 2000 13:05:50 +0530 (IST) From: A Srinath To: Loita Jahnsson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] sequential/parallell forking In-Reply-To: <3948B5BE.DE04E769@uab.ericsson.se> 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, 15 Jun 2000, Loita Jahnsson wrote: > Hi, > > On what basis does the proxy decide whether to fork > in parallell or use sequential forking? I think that it is an implementation issue, i.e. each proxy has a fixed way in which it handles all messages. If it is stateless then it has to be sequential. Srinath A Silicon Automation Systems Bangalore, India. > _______________________________________________ > 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 Jun 16 04:08: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 EAA07512 for ; Fri, 16 Jun 2000 04:08: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 156F144393; Fri, 16 Jun 2000 03:56: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 E156C44375 for ; Fri, 16 Jun 2000 03:56:39 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA14932; Fri, 16 Jun 2000 09:05:25 +0100 (BST) Message-ID: <3949DFC4.B3545188@ubiquity.net> Date: Fri, 16 Jun 2000 09:05:24 +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: A Srinath Cc: Loita Jahnsson , sip@lists.bell-labs.com Subject: Re: [SIP] sequential/parallell forking 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 A Srinath wrote: > > On Thu, 15 Jun 2000, Loita Jahnsson wrote: > > > Hi, > > > > On what basis does the proxy decide whether to fork > > in parallell or use sequential forking? > > I think that it is an implementation issue, i.e. each proxy has a fixed > way in which it handles all messages. If it is stateless then it has to be > sequential. Stateless proxies do not fork (12.3.7). Sequential forking means issuing one request and then waiting for a final response before issuing the next request. This necessitates the retention of state information. As previously mentioned a stateful proxy may fork in parallel or sequentially based on internal configuration policies. Its decision could be influenced by callee preferences, for example through a CPL script, and/or caller preferences through the Request-Disposition header. 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 Fri Jun 16 04:29: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 EAA07576 for ; Fri, 16 Jun 2000 04:29: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 1F29844399; Fri, 16 Jun 2000 04:18:08 -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 72CDE44375 for ; Fri, 16 Jun 2000 04:18:05 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id DAA18329; Fri, 16 Jun 2000 03:29:26 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id DAA26371; Fri, 16 Jun 2000 03:29:25 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id DAA27585; Fri, 16 Jun 2000 03:29:25 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id DAA13725; Fri, 16 Jun 2000 03:29:24 -0500 (CDT) Message-Id: <200006160829.DAA13725@b04a24.exu.ericsson.se> Subject: Re: [SIP] Proposal for providing additional error information to UACs To: oran@cisco.com (Dave Oran) Date: Fri, 16 Jun 2000 03:29:24 -0500 (CDT) Cc: eussean@exu.ericsson.se (Sean Olson), sip@lists.bell-labs.com In-Reply-To: from "Dave Oran" at Jun 08, 2000 10:52:24 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 body approach does seem themost flexible, but it also is the >heaviest-weight. The way I see this used it's likely to be a proxy which >inserts the information and I don't relish having to write proxy code that >tears apart and re-constructs a MIME multi-part body to add this >information. You don't have to, if people implementing multipart do it correctly. MIME multipart allows nesting (i.e. one of the parts of a MIME multipart body can be a MIME multipart body). So all your proxy needs to do is compose a two-part MIME multipart body; the first part is taken from the original body (regardless of its type), and the second part is your URI. But I agree that the exact purpose of a URI in the body would need to be specified as a header of some sort. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 16 04:34: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 EAA07652 for ; Fri, 16 Jun 2000 04:34: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 BF579443B6; Fri, 16 Jun 2000 04:22:58 -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 16CBB44375 for ; Fri, 16 Jun 2000 04:22:55 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA23758; Fri, 16 Jun 2000 09:31:56 +0100 (BST) Message-ID: <3949E5FB.34441D56@ubiquity.net> Date: Fri, 16 Jun 2000 09:31:55 +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: Loita Jahnsson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] proxy protocol conversion References: <3948B56D.E1821A57@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: > I kind of new in SIP design and have a couple of > basic questions regarding proxy protocol conversion. > > Assuming that "proxy protocol conversion" means > something like this: > > ---transport-1--> proxy ----transport-2--> > > For which cases are protocol conversion applicable > in a proxy: > > * when the proxy adds more data to the message, so it > cannot be stored within a UDP package when proxying > the message? > > * when an outbound proxy receives a UDP package from > a UAC, stating transport=tcp in the Request-URI? > > * when a proxy is configured to always go through > another proxy using TCP, disregarding any transport > parameters in the SIP message? > > * when a proxy has one client which only knowns UDP > on one side and a client who only knows TCP on the > other (ie the attempt to contact the called client > with UDP fails)? > > * ... ? > > Which of those (if applicable) scenarios was tested > at the 4th bakeoff? Unless I missed it "proxy protocol conversion" is not a term defined within the RFC. However the classification system for the 4th bakeoff did include the ability for a proxy to do UDP to TCP, and vice versa, conversion. AFAIK this simply means the proxy accepts a SIP message on one of the protocols and proxies it on using the other, for whatever reason. I know we did this in the advanced scenario testing, where the reason was that our proxy was configured to use TCP to contact the next downstream proxy. > If "proxy protocol conversions" refers to scenarios > like the ones mentioned above, what is it called when > you need to do this: > > caller-client ----request, transport1 ----> server > > caller-client <-- response, transport2 ---- same server :) > > (For example if the response for some reason would be > bigger than max UDP size). Again I don't know of a specific term for this behaviour within the RFC. 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 Fri Jun 16 04:58: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 EAA07765 for ; Fri, 16 Jun 2000 04:58: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 1BCBD443C0; Fri, 16 Jun 2000 04:45:55 -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 10CEA44375 for ; Fri, 16 Jun 2000 04:45:51 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA02498; Fri, 16 Jun 2000 09:54:56 +0100 (BST) Message-ID: <3949EB5F.70F93189@ubiquity.net> Date: Fri, 16 Jun 2000 09:54:55 +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: "Fox, Mike" Cc: Jonathan Rosenberg , sip Subject: Re: [SIP] RE: proposal for IMPP References: <613A6A6A3F09D3118F5C00508B2C24FE7F35E6@sd_exchange.nuera.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 "Fox, Mike" wrote: > > Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol > may be the right way. Call it SIP Control by Unified Methods. > > SOAP SCUM All joking aside, SOAP within SIP is already possible as it is just a text/html payload. As SOAP has been designed with HTTP as the base transport using SIP instead, with it's HTTP ancestry, is straight forward. Perhaps the flexibility and extensibility of SOAP could be an alternative to some of the more proprietary/out of SIP's solution space method/headers extensions. 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 Fri Jun 16 13:47: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 NAA18512 for ; Fri, 16 Jun 2000 13:47: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 15D2C4437C; Fri, 16 Jun 2000 13:35:17 -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 7530A44336 for ; Fri, 16 Jun 2000 13:35:13 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 10:46:36 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE7F3627@sd_exchange.nuera.com> From: "Fox, Mike" To: Neil Deason Cc: sip Date: Fri, 16 Jun 2000 10:46:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP->XML->SOAP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 believe (SIP -> XML) -> SOAP(like)HTTP is unstoppable. OSP and IMPP require XML awareness in SIP devices, so the door has already been opened for XML convergence of the SIP domain. HTTP is the Internet Application Protocol. The problems of HTTP using TCP can be fixed with SCTP (I hope!). Of course this will take some time (12+ months). Shouldn't this be the direction of SIP? Comments? Mike Fox > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Friday, June 16, 2000 1:55 AM > To: Fox, Mike > Cc: Jonathan Rosenberg; sip > Subject: Re: [SIP] RE: proposal for IMPP > > > "Fox, Mike" wrote: > > > > Why stop at XML for IMPP? Why not XML for SIP? Simple > Object Access Protocol > > may be the right way. Call it SIP Control by Unified Methods. > > > > SOAP SCUM > > All joking aside, SOAP within SIP is already possible as it is > just a > text/html payload. As SOAP has been designed with HTTP as the > base > transport using SIP instead, with it's HTTP ancestry, is straight > forward. > Perhaps the flexibility and extensibility of SOAP could be an > alternative > to some of the more proprietary/out of SIP's solution space > method/headers extensions. > > 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 16 14:37: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 OAA20361 for ; Fri, 16 Jun 2000 14:37: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 A985A4437E; Fri, 16 Jun 2000 14:25:15 -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 136B944336 for ; Fri, 16 Jun 2000 14:25:12 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id NAA25515; Fri, 16 Jun 2000 13:36:34 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA22283; Fri, 16 Jun 2000 13:36:33 -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 NAA23107; Fri, 16 Jun 2000 13:36:33 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id NAA02855; Fri, 16 Jun 2000 13:36:32 -0500 (CDT) Date: Fri, 16 Jun 2000 13:36:32 -0500 (CDT) Message-Id: <200006161836.NAA02855@b04a45.exu.ericsson.se> To: mfox@nuera.com Subject: Re: [SIP] SIP->XML->SOAP Cc: 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 X-BeenThere: sip@lists.bell-labs.com > I agree. I believe (SIP -> XML) -> SOAP(like)HTTP is unstoppable. OSP and > IMPP require XML awareness in SIP devices, so the door has already been > opened for XML convergence of the SIP domain. HTTP is the Internet > Application Protocol. The problems of HTTP using TCP can be fixed with SCTP > (I hope!). Of course this will take some time (12+ months). > > Shouldn't this be the direction of SIP? > Comments? > > > Mike Fox If you mean using XML as a common body format, I agree. If you mean SOAP, I think this is better solved with HTTP. SOAP is an interesting alternative for service execution in a SIP network. I don't think carrying it via SIP is necessary or really buys you anything in this case. But it certainly is a possibility. -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 16 14:43: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 OAA20606 for ; Fri, 16 Jun 2000 14:43: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 E011844399; Fri, 16 Jun 2000 14:31:18 -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 9E65F44389 for ; Fri, 16 Jun 2000 14:31:14 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 11:42:38 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE7F362C@sd_exchange.nuera.com> From: "Fox, Mike" To: Sean Olson , "Fox, Mike" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP->XML->SOAP Date: Fri, 16 Jun 2000 11:42:35 -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 SIP+XML is where SIP is at now. Additional objects are added and tagged by MIME headers. SIP->XML would converge the SIP methods and required parameters to XML and allows the introduction of a DTD or schema to define the syntax of a valid SIP message. Transport is UDP to the well known SIP port. Additional information objects could still use MIME tags and individual syntax, however many objects would converge to XML and reference their own dtd ( as MLPP does). The MIME tags are redundant(obsolete) if a xml dtd reference is used. (SIP->XML)->SOAP would change the transport to HTTP ( I know HTTP may need some fixing ie. TCP -> SCTP), and change SIP from a protocol to a set of object interfaces exposed by the SOAP schema. The SIP "methods" would become object interface methods. Events could be defined through event object interface methods. Device control can be defined similarly. Mike > -----Original Message----- > From: Sean Olson [mailto:eussean@exu.ericsson.se] > Sent: Friday, June 16, 2000 11:37 AM > To: mfox@nuera.com > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP->XML->SOAP > > > > I agree. I believe (SIP -> XML) -> SOAP(like)HTTP is > unstoppable. OSP and > > IMPP require XML awareness in SIP devices, so the door has > already been > > opened for XML convergence of the SIP domain. HTTP is the Internet > > Application Protocol. The problems of HTTP using TCP can be > fixed with SCTP > > (I hope!). Of course this will take some time (12+ months). > > > > Shouldn't this be the direction of SIP? > > Comments? > > > > > > Mike Fox > > If you mean using XML as a common body format, I agree. If > you mean SOAP, > I think this is better solved with HTTP. SOAP is an > interesting alternative > for service execution in a SIP network. I don't think > carrying it via SIP > is necessary or really buys you anything in this case. But it > certainly > is a possibility. > > -- > Sean Olson > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jun 17 00:54: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 AAA03717 for ; Sat, 17 Jun 2000 00:54: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 DC40C44375; Sat, 17 Jun 2000 00:43:14 -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 E0EAA44336 for ; Sat, 17 Jun 2000 00:43:11 -0400 (EDT) Received: from cisco.com ([161.44.109.7]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id AAA28407; Sat, 17 Jun 2000 00:54:29 -0400 (EDT) Message-ID: <394B04AF.6CCE8FBB@cisco.com> Date: Sat, 17 Jun 2000 00:55:11 -0400 From: Shailendra Bhatnagar Organization: Cisco Systems X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) 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] Tags 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 My understanding is that if initial INVITE is from A to B, B will append a tag to the To header of the final response ( assuming ofcourse that To header does not initially have a tag). Now, for the re-INVITE from B to A, A is not supposed to append a tag to the To header of the final response to this re-INVITE (although the To header of re-INVITE from B to A does may not have tag). My question is that if for some reason, a stateful proxy generates the final response to this re-INVITE from B to A, should it append a tag to the To header. Thanks, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jun 17 07: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 HAA17747 for ; Sat, 17 Jun 2000 07: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 9A43744351; Sat, 17 Jun 2000 07:14:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.192.45]) by lists.bell-labs.com (Postfix) with ESMTP id C93E844336 for ; Sat, 17 Jun 2000 07:14:22 -0400 (EDT) Received: from [193.118.192.194] by cundall.co.uk with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jun 2000 12:24:33 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: Date: Sat, 17 Jun 2000 12:25:08 +0100 To: sip@lists.bell-labs.com From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SIP] Re: "Static" Images Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 understand that the idea is a "low-data-rate" image transfer scheme (so Static is possibly the wrong word :). Agree it's a SDP issue rather than purely a SIP issue. In those cases where there's only a single group of items, one could use the same approach we used in PINT - having a fmtp line that indicates a URI and/or an "in-line" item carried in another numbered sub-part. This is kind of similar to the INFO/INVITE/... approach, and Colin's http suggestion, but allows more than one item and could be a set of URIs rather than just in-line (or a combination). Remember that PINT has defined extensions that may WELL be useful in a "normal" IP net conference. If it's a *really* low refresh rate, then why not Re-Invite using the same scheme? It doesn't have to be an INFO. You *may* not even need this - what's wrong with a URI pointing to a Progressive JPEG/Interlaced GIF/...? I had assumed that every ad-based service would have some of these wasting the end-users bandwidth. If, OTOH, it's a low but significant refresh rate, then it is a kind of animated image//video stream, so RTP-over-whatever seems appropriate. Final point - who said HTTP == HTTP/1.1? HTTP 1.0 is a doddle, and this kind of request is not exactly complex. -- All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd pay me for them" | |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jun 17 23: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 XAA25203 for ; Sat, 17 Jun 2000 23: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 C98F244340; Sat, 17 Jun 2000 23:36: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 DF8BF44336 for ; Sat, 17 Jun 2000 23:36:47 -0400 (EDT) Received: from dynamicsoft.com (1Cust47.tnt3.freehold.nj.da.uu.net [63.25.172.47]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00558; Sat, 17 Jun 2000 23:49:17 -0400 (EDT) Message-ID: <394B0817.4999E642@dynamicsoft.com> Date: Sat, 17 Jun 2000 01:09:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fox, Mike" Cc: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] SIP->XML->SOAP References: <613A6A6A3F09D3118F5C00508B2C24FE7F362C@sd_exchange.nuera.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 "Fox, Mike" wrote: > > SIP+XML is where SIP is at now. Additional objects are added and tagged by > MIME headers. > > SIP->XML would converge the SIP methods and required parameters to XML and > allows the introduction of a DTD or schema to define the syntax of a valid > SIP message. Why? SIP is already standardized. A syntax is already defined. There are well over 50 implementations (more likely around 100 by now). Any future versions of SIP need to be maximally compatible. So, for better or for worse, and NOT for debate, SIPs syntax is already done. Any discussions on migration to XML, binary, ASN.1 or the next flavor du jour are academic, fruitless, and a waste of space in my inbox, IMHO. -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 Sat Jun 17 23: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 XAA25218 for ; Sat, 17 Jun 2000 23: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 BBBA644358; Sat, 17 Jun 2000 23:37: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 0DE8244336 for ; Sat, 17 Jun 2000 23:37:33 -0400 (EDT) Received: from dynamicsoft.com (1Cust47.tnt3.freehold.nj.da.uu.net [63.25.172.47]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00622; Sat, 17 Jun 2000 23:50:23 -0400 (EDT) Message-ID: <394B1466.8C6D6236@dynamicsoft.com> Date: Sat, 17 Jun 2000 02:02:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Cc: Henning Schulzrinne , Billy Biggs , Colin Perkins , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006160732.CAA13522@b04a24.exu.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 "Adam B. Roach" wrote: > > Henning Schulzrinne writes: > >Why couldn't an RTP-over-TCP stream be used here? Telling the client to > >go fetch it seems strange, particularly since it also requires that you > >somehow upload the image to another server or run a web server on your > >PC/phone. > > If you're using TCP, I don't quite see what RTP gains you. I agree > with Sean that HTTP may be a bit heavy. > > Anyway, I offered 5 scenarios, and everyone seems to have latched onto > one. If I don't hear otherwise, I'll assume that the method of > doing something special in the SDP to indicate a TCP connection of > some sort (possibly with some protocol on top of it, like RTP or HTTP) > is the preferred choice, and take this discussion to MMUSIC. I think it depends on what the purpose is. If you want to include an image to be displayed before the call is even accepted (like a jpeg snapshot for new caller ID), I believe this to be very much a SIP thing, not SDP. You can think of it as a really long "subject" header - information for the purposes of determining what to do with the call. We have discussed these things on the list as well, and debated including the content in sip vs. indirection via a URL, and also whether it goes in a body or a header. There was no conclusion to this debate; it would be nice to finish it. If you want to do some kind of slow motion video after the call is set up, I'm unsure why this is anything different from very traditional video over RTP (UDP even). Why TCP? Sounds like you want a motion JPEG codec. -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 Sat Jun 17 23:52: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 XAA25229 for ; Sat, 17 Jun 2000 23:52: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 5513344364; Sat, 17 Jun 2000 23:39: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 8E97B44361 for ; Sat, 17 Jun 2000 23:39:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust47.tnt3.freehold.nj.da.uu.net [63.25.172.47]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00678; Sat, 17 Jun 2000 23:52:05 -0400 (EDT) Message-ID: <394B20F3.BA452E49@dynamicsoft.com> Date: Sat, 17 Jun 2000 02:55:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Loita Jahnsson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] proxy protocol conversion References: <3948B56D.E1821A57@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, > > I kind of new in SIP design and have a couple of > basic questions regarding proxy protocol conversion. > > Assuming that "proxy protocol conversion" means > something like this: > > ---transport-1--> proxy ----transport-2--> > > For which cases are protocol conversion applicable > in a proxy: > > * when the proxy adds more data to the message, so it > cannot be stored within a UDP package when proxying > the message? Generally, determination of the transport to use for outgoing requests will be driven by preferences set in the SRV records. In this case, they would not be dependent on a change in size of the message. Normal SIP procesing of a message will normally not make it much bigger. In any case, the maximum UDP size is 64k, which you are unlikely to ever see in SIP. > > * when an outbound proxy receives a UDP package from > a UAC, stating transport=tcp in the Request-URI? Yes, in this case the protocol goes out TCP. This is spelled out (along with the above) in Section 1.4.2 of the bis draft. This section applies independnt of the protocol the request came in on, so it may result in a "conversion" if the outgoing protocol selected was different from the incoming. > > * when a proxy is configured to always go through > another proxy using TCP, disregarding any transport > parameters in the SIP message? You can always do that, although its not specified to work this way. You'll run into troubles if the next hop doesn't support that protocol. > > * when a proxy has one client which only knowns UDP > on one side and a client who only knows TCP on the > other (ie the attempt to contact the called client > with UDP fails)? This would be determined through transport parameters in registered Contacts, so conversion might take place here, yes. > If "proxy protocol conversions" refers to scenarios > like the ones mentioned above, what is it called when > you need to do this: > > caller-client ----request, transport1 ----> server > > caller-client <-- response, transport2 ---- same server :) > > (For example if the response for some reason would be > bigger than max UDP size). This is not supported. You could try to do it by putting a different transport in the Via header than the one you actually used, but I don't recommend doing that, since its unlikely to work. In any case, it sounds like you want the server to dynamically change the tranpsort for the response if the response comes in and its big; having the client set the protocol in the Via won't help that. -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 Sat Jun 17 23:55: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 XAA25250 for ; Sat, 17 Jun 2000 23:55: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 B28C844361; Sat, 17 Jun 2000 23:39: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 5D9D844375 for ; Sat, 17 Jun 2000 23:39:30 -0400 (EDT) Received: from dynamicsoft.com (1Cust47.tnt3.freehold.nj.da.uu.net [63.25.172.47]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00698; Sat, 17 Jun 2000 23:52:31 -0400 (EDT) Message-ID: <394B2446.C6798225@dynamicsoft.com> Date: Sat, 17 Jun 2000 03:09:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Helpdesk MIS Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Handling multiple Transfer Target References: <4D0A8ECBDC8AD211BD0900A0C9EBC13301C23D1B@rambo.globespan.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 > Helpdesk MIS wrote: > > From: rafi > Hi, > > Is it possible for the transferor to inform the transferee > to try more than one transfer target serially or simultaneously? > Probably one way to do is to include more than one Transfer-to-Header > in the TRANSFER request message because transferee take decision > based on this field (section 4.6 of draft > draft-sparks-sip-cc-transfer-00.txt). > May be order of the of each name-addr / addr-spec in > Transfer-to-Header implies > their priority. Having more than one Transfer-to-Header header > is not allowed in the draft, draft-sparks-sip-cc-transfer-00.txt. I'm a bit reluctant to allow that. I'm not sure its needed. If you want the transferred party to try one address, then the next, then the next, etc., once each fails, you can do that without having multiple transfer-tos. Logic in the transferring party can simply send multiple transfer requests, one after a failure response from the previous. So, having multiple addresses is only useful for parallel transfers, but I doubt that this is useful. What happens if multiple acceptances come back? Does the transferred party speak to all, or just one? Was the TRANSFER successful if only some of the addresses in the transfer-to header yield successful results? Lots of complexity for no real value. -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 Sat Jun 17 23: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 XAA25261 for ; Sat, 17 Jun 2000 23:59: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 3F353443A1; Sat, 17 Jun 2000 23:43: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 2C82A4439B for ; Sat, 17 Jun 2000 23:43:31 -0400 (EDT) Received: from dynamicsoft.com (1Cust47.tnt3.freehold.nj.da.uu.net [63.25.172.47]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00710; Sat, 17 Jun 2000 23:52:38 -0400 (EDT) Message-ID: <394B2545.11499E73@dynamicsoft.com> Date: Sat, 17 Jun 2000 03:14:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Neil Deason , Hisham Khartabil , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Receiver-tagged Via header References: <394791E4.CD32B405@ericsson.fi> <39479540.D94316D3@ubiquity.net> <20000614103910.A24989@div8.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 Billy Biggs wrote: > > Neil Deason (ndeason@ubiquity.net): > > > Correct, this is noted towards the end of Appendix G - Changes To > > Be Made as "recieved-port for NAPT support in Via header field". > > Cute, I hadn't noticed that. > > The spec would have to be changed to suggest that clients always send > from the port that they intend to receive the message on, where possible. > That breaks stuff pretty bad. Exactly. This is a significant change from current behavior. I do not think we can do it, since it is not backwards compatible. Anyway, getting SIP through a NAT, with media and all working, is much harder than just this, and requires an ALG anyway. So, I'm not sure there is much gained in adding this port change. -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 Jun 18 00:33: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 AAA25443 for ; Sun, 18 Jun 2000 00:33: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 56DD244351; Sun, 18 Jun 2000 00:21: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 D1D7144336 for ; Sun, 18 Jun 2000 00:21:26 -0400 (EDT) Received: from dynamicsoft.com (1Cust47.tnt3.freehold.nj.da.uu.net [63.25.172.47]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00761; Sun, 18 Jun 2000 00:34:26 -0400 (EDT) Message-ID: <394C514B.983E1BA9@dynamicsoft.com> Date: Sun, 18 Jun 2000 00:34:19 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shailendra Bhatnagar Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Tags again References: <394B04AF.6CCE8FBB@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 Shailendra Bhatnagar wrote: > > My understanding is that if initial INVITE is from A to B, B will append > a tag to the To header of the final response ( assuming ofcourse that To > header does not initially have a tag). > > Now, for the re-INVITE from B to A, A is not supposed to append a tag > to the To header of the final response to this re-INVITE (although > the To header of re-INVITE from B to A does may not have tag). I think it is worth discussing whether or not A would/should append a tag in the To header of this final response. I'll note that there is no problem if the initial INVITE from A to B had a tag in the From field. The difficulty with not appending the tag in the response to re-INVITE is a loss of idempotency. This will come and bite you when you have devices that don't maintain call state (i.e., your proxy), which will insert the tag since they don't know this is a re-INVITE. It will also complicate recovery from crash/reboot cycles during a call. The difficulty in appending the tag to the response is, I believe, purely one of implementation. Most folks probably use some kind of key, hashed on various message fields, to index call state. This key would basically change as a result of this re-INVITE. Kind of ugly. I have been gradually reaching the conclusion that idempotency is a really important property, and thus I believe worth the implementation pain. Comments? -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 Jun 18 01:38: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 BAA00703 for ; Sun, 18 Jun 2000 01:38: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 9D3844433D; Sun, 18 Jun 2000 01: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 EFA5144336 for ; Sun, 18 Jun 2000 01:26:51 -0400 (EDT) Received: from dynamicsoft.com (1Cust47.tnt3.freehold.nj.da.uu.net [63.25.172.47]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA00801; Sun, 18 Jun 2000 01:39:46 -0400 (EDT) Message-ID: <394C609A.4F5AB0F6@dynamicsoft.com> Date: Sun, 18 Jun 2000 01:39:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Piotr S. Kossowski" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] n-way conference References: <39455323.F1579082@elka.pw.edu.pl> 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 Work on multiparty conferencing is in progress. There are several ways to do it with SIP now (dial up conference bridge, 3-way calling with end system mixing, multicast) which require no extensions; work is in progress on defining extensions for other models. Note that the 3-way model described in the call flows draft does extend to n-way, but the scalability is limited. For some drafts on the subject: http://www.softarmor.com/sipwg/drafts/draft-ietf-mmusic-sip-cc-01.txt (EXPIRED) http://search.ietf.org/internet-drafts/draft-campbell-sip-cc-framework-00.txt http://search.ietf.org/internet-drafts/draft-mark-sip-dmcs-00.txt -Jonathan R. "Piotr S. Kossowski" wrote: > > Hi, > > About n-way conferences: > > There is an example only 3-way conference > in draft-ietf-sip-call-flows-00.txt. > Did conisder anyone more participants (in any articles, drafts). > > Especialy, What's going with RTP streams then ? > (I think about difference between 2-way and 3-way or more > streaming) > > BR, > Piotr > > -- > All messages sent to P.Kossowski are delivered immediately also via SMS. > > _______________________________________________ > 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 Sun Jun 18 02:10: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 CAA07742 for ; Sun, 18 Jun 2000 02:10: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 456924434A; Sun, 18 Jun 2000 01:58:35 -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 0852B44336 for ; Sun, 18 Jun 2000 01:58:32 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FWC00D016GVNB@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 18 Jun 2000 06:10:07 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FWC00B116GVEB@firewall.mcit.com>; Sun, 18 Jun 2000 06:10:07 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0FWC00C0169XF9@pmismtp04.wcomnet.com>; Sun, 18 Jun 2000 06:05:57 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FWC00C0169WF5@pmismtp04.wcomnet.com>; Sun, 18 Jun 2000 06:05:57 +0000 (GMT) Received: from C25776A ([166.44.137.47]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FWC001B9689XW@pmismtp04.wcomnet.com>; Sun, 18 Jun 2000 06:05:47 +0000 (GMT) Date: Sun, 18 Jun 2000 07:09:04 -0500 From: Henry Sinnreich Subject: RE: [SIP] SIP->XML->SOAP In-reply-to: <394B0817.4999E642@dynamicsoft.com> To: "Fox, Mike" , Sean Olson Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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->XML would converge the SIP methods and required >parameters to XML and >> allows the introduction of a DTD or schema to define >the syntax of a valid >> SIP message. Do not forget that endangering the deployment of SIP as is, would set IP telephony back for a generation and leave the field for "softswitches" and other such nonsense. Nobody on this mailing list would then live to see true/open Internet communications, but just the old circuit switch central control model with its terrible signaling. Just using IP as a cheap wire. My two cents. Henry _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jun 18 04:14: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 EAA06269 for ; Sun, 18 Jun 2000 04: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 ACD1144351; Sun, 18 Jun 2000 04:02:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-208.dallas.net [209.44.42.208]) by lists.bell-labs.com (Postfix) with ESMTP id ADDE144336 for ; Sun, 18 Jun 2000 04:02:30 -0400 (EDT) Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id DAA08172; Sun, 18 Jun 2000 03:13:33 -0500 Date: Sun, 18 Jun 2000 03:13:33 -0500 From: "Brian F. G. Bidulock" To: Henry Sinnreich Cc: "Fox, Mike" , Sean Olson , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] SIP->XML->SOAP Message-ID: <20000618031333.B27268@inet.com> Reply-To: brian.bidulock@inet.com Mail-Followup-To: Henry Sinnreich , "Fox, Mike" , Sean Olson , Jonathan Rosenberg , sip@lists.bell-labs.com References: <394B0817.4999E642@dynamicsoft.com> 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 Henry.Sinnreich@WCom.com on Sun, Jun 18, 2000 at 07:09:04AM -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 Content-Transfer-Encoding: 8bit Henry, Don't lump Mike in with "those softswitch vendors" just because he mentioned XML, (as you could if he had mentioned ASN.1). Also, I believe he was talking about SIP's ``direction'' not the current situation. XML approaches have some strong arguments: it would take many IETF WG's away from defining new syntaxes and allow them to concentrate on the semantics. Combined with an XSL, message parsers and generators could be made to run of the specification instead of being specially developed. Bindings to application level frameworks (such as Java) could be possible in general. It's just running the thing (necessarily) over HTTP which doesn't make sense to me. --Brian Henry Sinnreich wrote: (07:09:04 -0500 Sun, 18 Jun 2000) > > >> SIP->XML would converge the SIP methods and required > >> parameters to XML and allows the introduction of a DTD or > >> schema to define the syntax of a valid SIP message. > > Do not forget that endangering the deployment of SIP as is, > would set IP telephony back for a generation and leave the > field for "softswitches" and other such nonsense. Nobody on > this mailing list would then live to see true/open Internet > communications, but just the old circuit switch central control > model with its terrible signaling. Just using IP as a cheap > wire. > > My two cents. > > Henry -- 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 Jun 18 11:45: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 LAA08571 for ; Sun, 18 Jun 2000 11:45: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 21DD74434D; Sun, 18 Jun 2000 11:33:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out4.prserv.net [32.97.166.34]) by lists.bell-labs.com (Postfix) with ESMTP id 1A2EE44336 for ; Sun, 18 Jun 2000 11:33:33 -0400 (EDT) Received: from cs.columbia.edu ([139.92.65.254]) by prserv.net (out4) with SMTP id <2000061815450323900lkeqse>; Sun, 18 Jun 2000 15:45:07 +0000 Message-ID: <394CE612.24398798@cs.columbia.edu> Date: Sun, 18 Jun 2000 11:09:06 -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: "Adam B. Roach" , Henning Schulzrinne , Billy Biggs , Colin Perkins , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006160732.CAA13522@b04a24.exu.ericsson.se> <394B1466.8C6D6236@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 > > If you want to include an image to be displayed before the call is even > accepted (like a jpeg snapshot for new caller ID), I believe this to be > very much a SIP thing, not SDP. You can think of it as a really long > "subject" header - information for the purposes of determining what to > do with the call. We have discussed these things on the list as well, > and debated including the content in sip vs. indirection via a URL, and > also whether it goes in a body or a header. There was no conclusion to > this debate; it would be nice to finish it. There is one additional argument (not sure whether this was made last time around...) for a URI header: body parts are very difficult to add by proxies, but it might be nice to allow a proxy to go into (say) an LDAP database or private photo collection and add this information. > > If you want to do some kind of slow motion video after the call is set > up, I'm unsure why this is anything different from very traditional > video over RTP (UDP even). Why TCP? Sounds like you want a motion JPEG > codec. > The only reason to use TCP here is that since delay isn't that important in this image transfer application, one might as well get the benefit of reliability. The only reason to use RTP rather than just "raw bits" is that you might want the encapsulation (e.g., for JPEG or H.261 frames) and might want to re-use existing fast-motion code [I don't see these as particularly compelling arguments]. As a side remark, one should probably weigh the advantage of having a separate mechanism vs. only using RTP/UDP in very low frame-rate mode. The latter gives you this frame-on-demand or one-frame-a-minute pretty much for free, without having to wait to upgrade everyone. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jun 18 23:14: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 XAA13917 for ; Sun, 18 Jun 2000 23:14: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 D650244348; Sun, 18 Jun 2000 23:02: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 7030244336 for ; Sun, 18 Jun 2000 23:02:18 -0400 (EDT) Received: from dynamicsoft.com (1Cust47.tnt3.freehold.nj.da.uu.net [63.25.172.47]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00678; Sun, 18 Jun 2000 23:15:05 -0400 (EDT) Message-ID: <394D902A.8F839823@dynamicsoft.com> Date: Sun, 18 Jun 2000 23:14:50 -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: "Adam B. Roach" , Henning Schulzrinne , Billy Biggs , Colin Perkins , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006160732.CAA13522@b04a24.exu.ericsson.se> <394B1466.8C6D6236@dynamicsoft.com> <394CE612.24398798@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: > > > > > If you want to include an image to be displayed before the call is even > > accepted (like a jpeg snapshot for new caller ID), I believe this to be > > very much a SIP thing, not SDP. You can think of it as a really long > > "subject" header - information for the purposes of determining what to > > do with the call. We have discussed these things on the list as well, > > and debated including the content in sip vs. indirection via a URL, and > > also whether it goes in a body or a header. There was no conclusion to > > this debate; it would be nice to finish it. > > There is one additional argument (not sure whether this was made last > time around...) for a URI header: body parts are very difficult to add > by proxies, but it might be nice to allow a proxy to go into (say) an > LDAP database or private photo collection and add this information. This point was made last time around. We had several candidate ways to include data by reference: 1. a body type of application/uri-list 2. a new header, URI, as you suggest for content included directly, there is clearly only one way, in the body with multipart MIME. I initially supported (1) for indirect references to content. This was because it would be nice to have the same basic encapsulation independent of whether the body is indirectly references or actually included. However, you are correct that practically speaking, this makes it very hard for manipulation by proxies and application servers. As you point out, adding something like a URL to a prestored picture of the caller, after doing proxy-authentication to verify the identity of the caller, would be a nice feature, and much harder if the proxy has to much with bodies. Related to that, APIs like CGI and servlets don't play that well with multipart, which then becomes mandatory for such services. So, I am basically saying that I have pretty much (although not 100% sure yet) changed my mind on this, and would prefer a header like URI: or something, as Henning proposes. Other comments? > > If you want to do some kind of slow motion video after the call is set > > up, I'm unsure why this is anything different from very traditional > > video over RTP (UDP even). Why TCP? Sounds like you want a motion JPEG > > codec. > > > The only reason to use TCP here is that since delay isn't that important > in this image transfer application, one might as well get the benefit of > reliability. The only reason to use RTP rather than just "raw bits" is > that you might want the encapsulation (e.g., for JPEG or H.261 frames) > and might want to re-use existing fast-motion code [I don't see these as > particularly compelling arguments]. As a side remark, one should > probably weigh the advantage of having a separate mechanism vs. only > using RTP/UDP in very low frame-rate mode. The latter gives you this > frame-on-demand or one-frame-a-minute pretty much for free, without > having to wait to upgrade everyone. I really don't see the need for having a completely separate way to support streaming media that is high latency, as opposed to low. If you want TCP, how about: m=video 21375 RTP/AVPT 31 where AVPT refers to a TCP encapsulating profile of RTP. You can then use a pitifully slow motion JPEG, and reuse the RTP encapsulations, code, codecs, etc. -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 Jun 18 23:22: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 XAA13944 for ; Sun, 18 Jun 2000 23:22: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 D95AA4435A; Sun, 18 Jun 2000 23:10:40 -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 155A744336 for ; Sun, 18 Jun 2000 23:10:38 -0400 (EDT) Received: (from shbhatna@localhost) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id XAA14855; Sun, 18 Jun 2000 23:22:14 -0400 (EDT) From: Shail Bhatnagar Message-Id: <200006190322.XAA14855@bounty.cisco.com> Subject: Re: [SIP] Tags again To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Sun, 18 Jun 2000 23:22:14 -0400 (EDT) Cc: sip@lists.bell-labs.com In-Reply-To: <394C514B.983E1BA9@dynamicsoft.com> from "Jonathan Rosenberg" at Jun 18, 2000 12:34:19 AM 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 X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, Precisely because of the stateful proxy case, I asked the question. However, I think on an earlier thread it was suggested that re-INVITE should not cause any tag to be appended ( I think even the bis version says this). As far as the hash key is concerned, in my humble opinion, lookup logic should not include tags. Tag comparison should be the state machine code. Thanks, Shail > > > > Shailendra Bhatnagar wrote: > > > > My understanding is that if initial INVITE is from A to B, B will append > > a tag to the To header of the final response ( assuming ofcourse that To > > header does not initially have a tag). > > > > Now, for the re-INVITE from B to A, A is not supposed to append a tag > > to the To header of the final response to this re-INVITE (although > > the To header of re-INVITE from B to A does may not have tag). > > I think it is worth discussing whether or not A would/should append a > tag in the To header of this final response. > > I'll note that there is no problem if the initial INVITE from A to B had > a tag in the From field. > > The difficulty with not appending the tag in the response to re-INVITE > is a loss of idempotency. This will come and bite you when you have > devices that don't maintain call state (i.e., your proxy), which will > insert the tag since they don't know this is a re-INVITE. It will also > complicate recovery from crash/reboot cycles during a call. The > difficulty in appending the tag to the response is, I believe, purely > one of implementation. Most folks probably use some kind of key, hashed > on various message fields, to index call state. This key would basically > change as a result of this re-INVITE. Kind of ugly. > > I have been gradually reaching the conclusion that idempotency is a > really important property, and thus I believe worth the implementation > pain. > > Comments? > > -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 Sun Jun 18 23:43: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 XAA14405 for ; Sun, 18 Jun 2000 23:43: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 19E9644352; Sun, 18 Jun 2000 23:31:47 -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 8B78B44336 for ; Sun, 18 Jun 2000 23:31:43 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Sun, 18 Jun 2000 20:43:41 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "Adam B. Roach" Cc: Henning Schulzrinne , Billy Biggs , Colin Perkins , sip@lists.bell-labs.com Subject: RE: [SIP] Static Images Date: Sun, 18 Jun 2000 20:43:40 -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 This discussion is not only limited to images but also the transferring of executable objects, scripts and just about any other non-streaming entity in a SIP session. I can foresee that some objects (perhaps call preference scripts or display objects) may be desired during call setup (as Jonathan mentioned) and others form part of the session content. For transferring content during call setup: Inline content has undesirable size limitations and deleterious effects on call-setup time. For referenced content: using HTTP to _fetch_ the content during call setup seems the way to go as no two-way session information needs to be exchanged (which defeats the purpose of SIP). The question is should the URL be in a MIME body or SIP header ? MIME seems the most flexible but also required multipart support in all proxies. Do we need both ? The same problem exists for file-based session content: If MIME multipart support is not mandatory on all proxies then we need to look at SDP. Transferring objects in SDP is somewhat limited unless we come up with a= extensions as someone suggested (from PINT). Otherwise, let's consider the case where each object transferred is separate and so requires a different SDP m= line (although not all at once). Now you cannot reuse PT values within the same SIP call (correct?) and so you are limited to 120 or so object transfers (if you use the static RTP payload range as well). Of course what we really need is SDPng but until then I think its is worthwhile in stretching the current SDP a= usage to perform object based transfer - this is a potentially huge application area of a SIP session. .... Just my thoughts. Robert. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Saturday, June 17, 2000 2:02 PM To: Adam B. Roach Cc: Henning Schulzrinne; Billy Biggs; Colin Perkins; sip@lists.bell-labs.com Subject: Re: [SIP] Static Images "Adam B. Roach" wrote: > > Henning Schulzrinne writes: > >Why couldn't an RTP-over-TCP stream be used here? Telling the client to > >go fetch it seems strange, particularly since it also requires that you > >somehow upload the image to another server or run a web server on your > >PC/phone. > > If you're using TCP, I don't quite see what RTP gains you. I agree > with Sean that HTTP may be a bit heavy. > > Anyway, I offered 5 scenarios, and everyone seems to have latched onto > one. If I don't hear otherwise, I'll assume that the method of > doing something special in the SDP to indicate a TCP connection of > some sort (possibly with some protocol on top of it, like RTP or HTTP) > is the preferred choice, and take this discussion to MMUSIC. I think it depends on what the purpose is. If you want to include an image to be displayed before the call is even accepted (like a jpeg snapshot for new caller ID), I believe this to be very much a SIP thing, not SDP. You can think of it as a really long "subject" header - information for the purposes of determining what to do with the call. We have discussed these things on the list as well, and debated including the content in sip vs. indirection via a URL, and also whether it goes in a body or a header. There was no conclusion to this debate; it would be nice to finish it. If you want to do some kind of slow motion video after the call is set up, I'm unsure why this is anything different from very traditional video over RTP (UDP even). Why TCP? Sounds like you want a motion JPEG codec. -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 Mon Jun 19 00:13: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 AAA14604 for ; Mon, 19 Jun 2000 00:13: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 973774435A; Mon, 19 Jun 2000 00:01:49 -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 A46A644336 for ; Mon, 19 Jun 2000 00:01:45 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Sun, 18 Jun 2000 21:13:44 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Request/Responses from other addresses Date: Sun, 18 Jun 2000 21:13:43 -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 Jonathan, It would be nice though if the source authentication could be provided at the IP layer through IPSEC AH or similar methods, such that the SIP UA could trust the source address if an SA exists without having to implement authentication itself (assuming hop-by-hop authentication). Is this a pipe-dream ? Can anyone see any obvious holes ? There are many issues to consider but one of them is: who is allowed to send BYE & re-INVITE requests for a call. I guess one answer is "anyone with an SA" but I was hoping thing we could narrow it down a bit. Robert. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, June 06, 2000 12:21 PM To: Fairlie-Cuninghame, Robert Cc: McMurry, Kathleen; Sean Olson; sip@lists.bell-labs.com Subject: Re: [SIP] Request/Responses from other addresses "Fairlie-Cuninghame, Robert" wrote: > > > > For security purposes, actually, you really do need to check that the > > > CANCEL came from the same place as the request being cancelled (see the > > > minutes of the security task force on this). CANCELs cannot usefully be > > > authenticated directly, since they may come from proxies. That aside, > > > CANCEL can come from anywhere. > > > > I take it then that this doesn't apply to BYE requests because they can be > authenticated directly? Yes. > Is there a weaker source address check you could > apply in the absence of authentication? I can't think of any infallible > ones. THere is no such thing as infallible security anyway. > Requests will not always come from the original source address and the > Contact address doesn't necessarily infer that the source of future requests > will be from that address... although it would help if we could assume that! In the case of mobility, the address definitely won't be the same. > > So I guess that without authentication, SIP is very vulnerable to someone > sniffing packets and then generating their own requests to re-INVITE the > call to themselves. Yes; but thats why we have 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 19 00:16: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 AAA14615 for ; Mon, 19 Jun 2000 00:16: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 4397644365; Mon, 19 Jun 2000 00:03: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 6912A44336 for ; Mon, 19 Jun 2000 00:03:12 -0400 (EDT) Received: from dynamicsoft.com (1Cust166.tnt1.freehold.nj.da.uu.net [63.17.113.166]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00750; Mon, 19 Jun 2000 00:16:22 -0400 (EDT) Message-ID: <394D9E86.5C85AF3D@dynamicsoft.com> Date: Mon, 19 Jun 2000 00:16:07 -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] Reliable provisional responses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, WG last call has pretty much ended on the reliable provisional responses draft. The only open issue seems to be whether prack should be cumulative or not. There was one note arguing against it, and I weakly argued in favor of it. To follow a recent trend I seem to be having regarding about-faces, I think I have changed my mind on this one too. Why? Cumulative prack is purely an optimization; you can always send N separate PRACKs instead of a single cumulative PRACK. The reduction in messaging is the only benefit; it is still possible to support multiple outstanding reliable provisional responses without cumulative PRACK. The primary drawback is complexity. One of the ones which concerns me is determining the set of outstanding reliable provisionals covered by prack. If people place the reliable provisional state machine objects into a hash table, indexed by, among other things, the rseq number, this makes it hard to match up transactions with PRACK. Finding the a set of things matching a rule, where those things are stored in a hash table, is a pain. So, given that (1) we have no specific application which really is a killer app for cumulative PRACK, (2) its a message reduction optimization for something which is probably not a common case, and (3) there are complexity issues that make an implementation difficult, I am proposing to remove this feature from the spec before submitting the version that will go to IESG. So, if you want to speak in favor of keeping this feature, speak NOW (well, within 3 days, say), or forever hold your peace.... -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 Jun 19 04:50: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 EAA27892 for ; Mon, 19 Jun 2000 04:50: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 CE0BA4435F; Mon, 19 Jun 2000 04:37:57 -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 00D7644336 for ; Mon, 19 Jun 2000 04:37:34 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA14344; Mon, 19 Jun 2000 09:45:04 +0100 (BST) Message-ID: <394DDD90.A82076DE@ubiquity.net> Date: Mon, 19 Jun 2000 09:45:04 +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: Sean Olson Cc: mfox@nuera.com, sip@lists.bell-labs.com Subject: Re: [SIP] SIP->XML->SOAP References: <200006161836.NAA02855@b04a45.exu.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 Sean Olson wrote: > > > I agree. I believe (SIP -> XML) -> SOAP(like)HTTP is unstoppable. OSP and > > IMPP require XML awareness in SIP devices, so the door has already been > > opened for XML convergence of the SIP domain. HTTP is the Internet > > Application Protocol. The problems of HTTP using TCP can be fixed with SCTP > > (I hope!). Of course this will take some time (12+ months). > > > > Shouldn't this be the direction of SIP? > > Comments? I fully agree with Jonathan about us being well past the time to define the basic syntax of SIP and Henry's point of what we would stand to lose if we did. However, no large scale disturbance of the protocol is necessary just to carry an XML payload encoded by the SOAP schema within a SIP message. > If you mean using XML as a common body format, I agree. If you mean SOAP, > I think this is better solved with HTTP. SOAP is an interesting alternative > for service execution in a SIP network. I don't think carrying it via SIP > is necessary or really buys you anything in this case. But it certainly > is a possibility. Within a SIP network how about something like this, say between a SIP Proxy (shown as the client) and an Application Services Broker (the server), for a trivial credit check service. Probably not a brilliant example but it shows the sort of thing SOAP could be used for, i.e. alleviating the need for lots of header/method extensions to SIP by providing a well defined way for such info to be encoded in the SOAP/XML payload. I have taken the liberty of introducing a new SIP method, SERVICE, to carry the SOAP/XML payload for simplicity, though even this might not be strictly necessary. C->S: SERVICE sip:application_service_broker.ubiquity.net SIP/2.0 To: sip:application_service_broker.ubiquity.net From: sip:proxy.ubiquity.net Call-ID:648324@193.195.52.30 CSeq: 1 SERVICE Via: SIP/2.0/UDP proxy.ubiquity.net Content-Type: text/xml Content-Length: nnnn sip:jo@ubiquity.net S->C: SIP/2.0 200 OK To: sip:application_service_broker.ubiquity.net From: sip:proxy.ubiquity.net Call-ID:648324@193.195.52.30 CSeq: 1 SERVICE Via: SIP/2.0/UDP proxy.ubiquity.net Content-Type: text/xml Content-Length: nnnn 34.5 I could extend this into a short Internet Draft if there is any interest in doing so. 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 Mon Jun 19 08:32: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 IAA02239 for ; Mon, 19 Jun 2000 08:32: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 E6E7E4435C; Mon, 19 Jun 2000 08:20:13 -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 9992944336 for ; Mon, 19 Jun 2000 08:20:09 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FWE00E01IT65W@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 19 Jun 2000 12:31:55 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FWE00LEPIT6TH@firewall.mcit.com>; Mon, 19 Jun 2000 12:31:54 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FWE00901IR22P@pmismtp03.wcomnet.com>; Mon, 19 Jun 2000 12:30:38 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FWE00901IR12M@pmismtp03.wcomnet.com>; Mon, 19 Jun 2000 12:30:38 +0000 (GMT) Received: from C25776A ([166.44.138.84]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FWE00651IQK6E@pmismtp03.wcomnet.com>; Mon, 19 Jun 2000 12:30:23 +0000 (GMT) Date: Mon, 19 Jun 2000 14:31:22 -0500 From: Henry Sinnreich In-reply-to: <394D902A.8F839823@dynamicsoft.com> To: Jonathan Rosenberg , Henning Schulzrinne Cc: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [SIP] SIP and SCTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 What is the URL for the I-D on SIP and SCTP? Sorry for the trouble, Henry _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 19 08:53: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 IAA03312 for ; Mon, 19 Jun 2000 08:53: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 2427944364; Mon, 19 Jun 2000 08:39:38 -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 1F10944336 for ; Mon, 19 Jun 2000 08:39:35 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FWE00201JPLXF@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 19 Jun 2000 12:51:21 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FWE00HFJJPKCZ@firewall.mcit.com>; Mon, 19 Jun 2000 12:51:21 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FWE00G01JNGX3@pmismtp03.wcomnet.com>; Mon, 19 Jun 2000 12:50:04 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FWE00G01JNDRG@pmismtp03.wcomnet.com>; Mon, 19 Jun 2000 12:50:04 +0000 (GMT) Received: from C25776A ([166.44.138.84]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FWE006MDJMW6E@pmismtp03.wcomnet.com>; Mon, 19 Jun 2000 12:49:51 +0000 (GMT) Date: Mon, 19 Jun 2000 14:50:48 -0500 From: Henry Sinnreich Subject: RE: [SIP] SIP->XML->SOAP In-reply-to: <394DDD90.A82076DE@ubiquity.net> To: Neil Deason , Sean Olson Cc: mfox@nuera.com, sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 could extend this into a short Internet Draft Would suggest to have such a draft and open it for discussion. Thanks, Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Neil Deason >Sent: Monday, June 19, 2000 3:45 AM >To: Sean Olson >Cc: mfox@nuera.com; sip@lists.bell-labs.com >Subject: Re: [SIP] SIP->XML->SOAP > > >Sean Olson wrote: >> >> > I agree. I believe (SIP -> XML) -> SOAP(like)HTTP >is unstoppable. OSP and >> > IMPP require XML awareness in SIP devices, so the >door has already been >> > opened for XML convergence of the SIP domain. HTTP >is the Internet >> > Application Protocol. The problems of HTTP using >TCP can be fixed with SCTP >> > (I hope!). Of course this will take some time (12+ months). >> > >> > Shouldn't this be the direction of SIP? >> > Comments? > >I fully agree with Jonathan about us being well past >the time to >define the basic syntax of SIP and Henry's point of >what we would >stand to lose if we did. However, no large scale disturbance of >the protocol is necessary just to carry an XML payload >encoded by >the SOAP schema within a SIP message. > >> If you mean using XML as a common body format, I >agree. If you mean SOAP, >> I think this is better solved with HTTP. SOAP is an >interesting alternative >> for service execution in a SIP network. I don't >think carrying it via SIP >> is necessary or really buys you anything in this >case. But it certainly >> is a possibility. > >Within a SIP network how about something like this, >say between a >SIP Proxy (shown as the client) and an Application Services >Broker (the server), for a trivial credit check >service. Probably >not a brilliant example but it shows the sort of thing >SOAP could >be used for, i.e. alleviating the need for lots of >header/method >extensions to SIP by providing a well defined way for such info >to be encoded in the SOAP/XML payload. I have taken the liberty >of introducing a new SIP method, SERVICE, to carry the SOAP/XML >payload for simplicity, though even this might not be strictly >necessary. > >C->S: > >SERVICE sip:application_service_broker.ubiquity.net SIP/2.0 >To: sip:application_service_broker.ubiquity.net >From: sip:proxy.ubiquity.net >Call-ID:648324@193.195.52.30 >CSeq: 1 SERVICE >Via: SIP/2.0/UDP proxy.ubiquity.net >Content-Type: text/xml >Content-Length: nnnn > > xmlns:SOAP-ENV="http://schemas.xmlsoap-org/soap/envelope" > SOAPENV:encodingStyle= > "http://schemas.xmlsoap.org/soap/encoding/"> > > > sip:jo@ubiquity.net > > > > >S->C: > >SIP/2.0 200 OK >To: sip:application_service_broker.ubiquity.net >From: sip:proxy.ubiquity.net >Call-ID:648324@193.195.52.30 >CSeq: 1 SERVICE >Via: SIP/2.0/UDP proxy.ubiquity.net >Content-Type: text/xml >Content-Length: nnnn > > xmlns:SOAP-ENV="http://schemas.xmlsoap-org/soap/envelope" > SOAP-ENV:encodingStyle= > "http://schemas.xmlsoap.org/soap/encoding/"> > > > 34.5 > > > > >I could extend this into a short Internet Draft if there is any >interest in doing so. >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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 19 10:37: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 KAA07652 for ; Mon, 19 Jun 2000 10:37: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 CC8BE4434D; Mon, 19 Jun 2000 10:24: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 3E57F44336 for ; Mon, 19 Jun 2000 10:24:54 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id JAA12622; Mon, 19 Jun 2000 09:36:36 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA05502; Mon, 19 Jun 2000 09:36:36 -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 JAA03344; Mon, 19 Jun 2000 09:36:35 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id JAA05759; Mon, 19 Jun 2000 09:36:35 -0500 (CDT) Date: Mon, 19 Jun 2000 09:36:35 -0500 (CDT) Message-Id: <200006191436.JAA05759@b04a45.exu.ericsson.se> To: shbhatna@cisco.com, jdrosen@dynamicsoft.com Subject: Re: [SIP] Tags again Cc: 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 X-BeenThere: sip@lists.bell-labs.com > I have been gradually reaching the conclusion that idempotency is a > really important property, and thus I believe worth the implementation > pain. > > Comments? > > -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 > I second that. Plus I think it's more of pain not to add a tag (a special case) in this event. -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 19 11:40: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 LAA11402 for ; Mon, 19 Jun 2000 11:40: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 1AE5944352; Mon, 19 Jun 2000 11:28: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 E886644336 for ; Mon, 19 Jun 2000 11:28:26 -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 LAA03135; Mon, 19 Jun 2000 11:41:37 -0400 (EDT) Message-ID: <394E3F23.63688DEA@dynamicsoft.com> Date: Mon, 19 Jun 2000 11:41:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Sinnreich Cc: Henning Schulzrinne , sip@lists.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: SIP and SCTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 written a preliminary draft on the subject, which I hope to send in shortly (next few days or so). -Jonathan R. Henry Sinnreich wrote: > > What is the URL for the I-D on SIP and SCTP? > > Sorry for the trouble, Henry -- 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 Jun 19 12:34: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 MAA13872 for ; Mon, 19 Jun 2000 12:34: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 489AE44344; Mon, 19 Jun 2000 12:22:19 -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 19A4544336 for ; Mon, 19 Jun 2000 12:22:16 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 09:34:03 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE7F365A@sd_exchange.nuera.com> From: "Fox, Mike" To: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: RE: [SIP] SIP->XML->SOAP Date: Mon, 19 Jun 2000 09:33: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 X-BeenThere: sip@lists.bell-labs.com As SOAP is defined. It runs over HTTP, sure you could run it over SIP, but why? Mapping SIP to XML alone is not compelling, but I think it is good for SIP. I believe, that the Software art is beyond lumping a protocol and its application functions together, as many CORBA, Java, C++, and OO programmers will understand. SOAP is a candidate infrastructure for a object oriented solution to session and device control. I respect that the chair does not like the idea. The work can be taken elsewhere. Best regards, 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 Jun 19 16:56: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 QAA23309 for ; Mon, 19 Jun 2000 16:56: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 1343B4434F; Mon, 19 Jun 2000 16:44:09 -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 1BCBE44344 for ; Mon, 19 Jun 2000 16:44:06 -0400 (EDT) Received: from dynamicsoft.com (dwillis5.directlink.net [63.64.250.86]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id CAA23859; Tue, 20 Jun 2000 02:58:17 -0500 Message-ID: <394E896A.A9198DF8@dynamicsoft.com> Date: Mon, 19 Jun 2000 15:58:18 -0500 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fox, Mike" Cc: Robert Sparks , SIP@lists.bell-labs.com Subject: Re: [SIP] comments on draft-sparks-sip-cc-transfer-00.txt References: <613A6A6A3F09D3118F5C00508B2C24FE7F3459@sd_exchange.nuera.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 "Fox, Mike" wrote: > I read the draft, and I am left wondering exactly what aspects (or features) > of call control the Transfer method adds which can not be accomplished using > existing SIP methods. The draft cites that: > Looking back over the SIP email there are additional points the author and > others make in favor of the Transfer method, but I am (as I'm sure others > are) unsure if these alone justify implementation of a new method. I believe > the draft, discussions, and group thinking would all benefit from a thorough > comparison of call control models and features made possible using the > Transfer method vs. existing SIP methods (such as BYE Also). I was hoping that somebody else would point out that there IS no existing SIP BYE Also method. That came from a draft which has expired and I believe is considered abandoned by the authors . . . -- 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 Jun 19 17:04: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 RAA23521 for ; Mon, 19 Jun 2000 17:04: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 8A7724435B; Mon, 19 Jun 2000 16:52:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out2.prserv.net [32.97.166.32]) by lists.bell-labs.com (Postfix) with ESMTP id 7596544344 for ; Mon, 19 Jun 2000 16:51:57 -0400 (EDT) Received: from cs.columbia.edu ([139.92.65.108]) by prserv.net (out2) with SMTP id <20000619210303229019ggqqe>; Mon, 19 Jun 2000 21:03:06 +0000 Message-ID: <394E7F61.BA727458@cs.columbia.edu> Date: Mon, 19 Jun 2000 16:15:29 -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: "'Jonathan Rosenberg'" , "Adam B. Roach" , Henning Schulzrinne , Billy Biggs , Colin Perkins , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images 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 problem with having proxies add body parts is (a) complexity, (b) that now all clients have to understand multipart, even if they have no interest in the information (I would guess that most current SIP clients don't understand multipart) and (c) that it doesn't work with signed requests. Headers containing a reference (http:, say) avoid these problems. The only drawback is that such references require http support in clients (which may be an issue for a very light-weight clients, but most of these are probably graphically challenged anyway) and requires that the information is available on a publically accessible web page. I suspect that most corporate users would have difficult uploading their likeness or other images to a web page, and not everyone wants to have their likeness framed by an advertisement from geocity or kin. These are, more or less, the arguments that were made the last time this topic came around, I believe. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 19 22:53: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 WAA29398 for ; Mon, 19 Jun 2000 22:53: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 CE31C44352; Mon, 19 Jun 2000 22:41:10 -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 E4F084433A for ; Mon, 19 Jun 2000 22:41:05 -0400 (EDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Jun 2000 19:45: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); Mon, 19 Jun 2000 19:53:56 -0700 Date: Mon, 19 Jun 2000 19:41:21 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDA61.049D16F0" Message-ID: <078292D50C98D2118D090008C7E9C6A6018A811C@STAY.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4397.0 content-class: urn:content-classes:message Thread-Topic: Questions on Figure 11 of RFC2543bis Thread-Index: Ab/aYfJyy1FMuft4TLuJkPgMWpsEYg== From: "Ajay Chitturi" To: X-OriginalArrivalTime: 20 Jun 2000 02:53:56.0959 (UTC) FILETIME=[C6FA0EF0:01BFDA62] Subject: [SIP] Questions on Figure 11 of RFC2543bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_01BFDA61.049D16F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In this diagram does "give up" mean the caller gave up and hung=20 up the call or that the state machine gave up ? Since there is another arrow from the "Calling" state showing=20 "7 INVITE sent", I assume the arrow to the right of "Calling" state=20 happens when the user hangs up. In this case shouldn't the state machine wait for the response to INVITE and send an ACK ? The arrow to the right of "Call Proceeding" state could happen if either the caller hangs up or the state machine hangs up. Is the timeout for when=20 the state machine will give up in this state specified in the draft or left=20 to the implementation. If the user hangs up, shouldn't the state machine wait for the response to INVITE and send an ACK ? Also section 4.2.4 states : A BYE request from either called or calling party terminates any=20 pending INVITE, but the INVITE request transaction MUST be completed=20 with a final response.=20 Does this mean that the ACK also needs to be sent after getting=20 the response ?=20 Thanks Ajay. ------_=_NextPart_001_01BFDA61.049D16F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Questions on Figure 11 of RFC2543bis

In this diagram does "give up" mean the = caller gave up and hung
up the call or that the state machine gave up = ?

Since there is another arrow from the = "Calling" state showing
"7 INVITE sent", I assume the arrow to the = right of "Calling" state
happens when the user hangs up. In this case = shouldn't the state machine
wait for the response to INVITE and send an ACK = ?

The arrow to the right of "Call Proceeding" = state could happen if either
the caller hangs up or the state machine hangs up. Is = the timeout for when
the state machine will give up in this state = specified in the draft or left
to the implementation. If the user hangs up, = shouldn't the state machine
wait for the response to INVITE and send an ACK = ?

Also section 4.2.4 states :
   A BYE request from either called or = calling party terminates any
   pending INVITE, but the INVITE request = transaction MUST be completed
   with a final response.

Does this mean that the ACK also needs to be sent = after getting
the response ?

Thanks
Ajay.

------_=_NextPart_001_01BFDA61.049D16F0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 19 22:55: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 WAA29413 for ; Mon, 19 Jun 2000 22:55: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 70DF14435A; Mon, 19 Jun 2000 22:41:13 -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 E073444336 for ; Mon, 19 Jun 2000 22:41:05 -0400 (EDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Jun 2000 19:45: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); Mon, 19 Jun 2000 19:53:57 -0700 Date: Mon, 19 Jun 2000 19:41:39 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDA61.0F2CC19C" Message-ID: <078292D50C98D2118D090008C7E9C6A6018A811B@STAY.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4397.0 content-class: urn:content-classes:message Thread-Topic: Questions on section 10.1.1 of RFC2543bis Thread-Index: Ab/aYf0FBcIRN0z/SdSKC7aSFbFBww== From: "Ajay Chitturi" To: X-OriginalArrivalTime: 20 Jun 2000 02:53:57.0334 (UTC) FILETIME=[C7334760:01BFDA62] Subject: [SIP] Questions on section 10.1.1 of RFC2543bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_01BFDA61.0F2CC19C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The following is a paragraph in section 10.1.1 of the RFC2543bis draft When a user agent server receives a request, it checks the Call-ID against those of in-progress calls. If the Call-ID was found, it compares the tag value of To with the user's tag and rejects the request if the two do not match. If the From header, including any tag value, matches the value for an existing call leg, the server compares the CSeq header field value. If less than or equal to the current sequence number, the request is a retransmission. Otherwise, it is a new request. If the From header does not match an existing call leg, a new call leg is created. Why is just the tag value of To compared (while the whole of From header is compared). Also could you please explain the scenario where the following happens: "If the From header does not match an existing call leg, a new call leg is created." Thanks Ajay. ------_=_NextPart_001_01BFDA61.0F2CC19C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Questions on section 10.1.1 of RFC2543bis

The following is a paragraph in section 10.1.1 of the = RFC2543bis draft

    When a user agent server receives a = request, it checks the Call-ID
    against those of in-progress = calls. If the Call-ID was found, it
    compares the tag value of To with = the user’s tag and rejects
    the request if the two do not = match. If the From header, including
    any tag value, matches the value = for an existing call leg, the
    server compares the CSeq header = field value. If less than or equal
    to the current sequence number, = the request is a retransmission.
    Otherwise, it is a new request. If = the From header does not match
    an existing call leg, a new call = leg is created.

Why is just the tag value of To compared (while the = whole of From
header is compared).

Also could you please explain the scenario where the = following
happens: "If the From header does not match an = existing call leg, a
new call leg is created."


Thanks
Ajay.

------_=_NextPart_001_01BFDA61.0F2CC19C-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 20 04:28: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 EAA15186 for ; Tue, 20 Jun 2000 04: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 9786C44354; Tue, 20 Jun 2000 04:16: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 D8CCA44336 for ; Tue, 20 Jun 2000 04:15:42 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA13092; Tue, 20 Jun 2000 09:25:03 +0100 (BST) From: "Jo Hornsby" To: "Ajay Chitturi" Cc: Subject: RE: [SIP] Questions on section 10.1.1 of RFC2543bis Date: Tue, 20 Jun 2000 09:25:02 +0100 Message-ID: <000e01bfda91$07b6d940$4e34c3c1@ubiquity.co.uk> 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 8.5, Build 4.71.2377.0 In-reply-to: <078292D50C98D2118D090008C7E9C6A6018A811B@STAY.platinum.corp.microsoft.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: 8bit > The following is a paragraph in section 10.1.1 of the RFC2543bis draft > When a user agent server receives a request, it checks the Call-ID > against those of in-progress calls. If the Call-ID was found, it > compares the tag value of To with the user’s tag and rejects > the request if the two do not match. If the From header, including > any tag value, matches the value for an existing call leg, the > server compares the CSeq header field value. If less than or equal > to the current sequence number, the request is a retransmission. > Otherwise, it is a new request. If the From header does not match > an existing call leg, a new call leg is created. > Why is just the tag value of To compared (while the whole of From > header is compared). Presumably because even if UACs are generating non-unique Call-IDs, they are far less likely to be non-unique within the callee's space (one would hope!). The reason the tag of the To is considered is to ensure that this Request really is for this user; if the tag does not match, then the callee's request probably forked, and the request is for some other destination (along another branch). > Also could you please explain the scenario where the following > happens: "If the From header does not match an existing call leg, a > new call leg is created." I guess this vaguely confirms my first paragraph. That's a relief. &:) - 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 Jun 20 05:23: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 FAA15649 for ; Tue, 20 Jun 2000 05:23: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 D2B6C44350; Tue, 20 Jun 2000 05:11:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id A1BD244336 for ; Tue, 20 Jun 2000 05:11:10 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id OAA22128 for ; Tue, 20 Jun 2000 14:51:32 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Tue, 20 Jun 2000 14:51:31 +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 OAA07479 for ; Tue, 20 Jun 2000 14:51:30 +0530 (IST) Message-ID: <00d901bfda98$ddf0e760$8c40000a@sasi.com> From: "rafi" To: Date: Tue, 20 Jun 2000 14:51:07 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01BFDAC6.F7784F60" 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] How to ping Prxoy Server ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_00D6_01BFDAC6.F7784F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Consider a UAC which uses a default proxy server (say proxy 1) whenever it has to send SIP request. It may so happen that though transport connection is available at server where proxy is suppose to run but proxy may not be responding due to some reason ( may be due to temporary failure). UAC keeps = retransmitting the request for a given number of time and when it decides to give up = it=20 sends a CANCEL message and then try other proxy server. Thus whenever a new SIP request is made UAC first tries default proxy server and = then everything=20 repeats once again. This may create some problem because it increase = the call set up time ( in worst case it may happen at every intermediate proxy = server). Is there=20 any method/way available in SIP using which status of proxy server can = be known in advance ?. This information helps the UAC in keeping track current active list of = default=20 proxy server(s). Thank You Rafi Assadi H.M. Silicon Automation Sysytems Bangalore, INDIA ------=_NextPart_000_00D6_01BFDAC6.F7784F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
      =    =20         Consider a  UAC which  = uses a=20 default proxy server
(say proxy 1) whenever it has to send = SIP request.=20 It may so happen
that though=20 transport connection is available at server where proxy is
suppose to run but proxy  may = not  be=20 responding due to
some reason ( may be due to temporary = failure). =20 UAC keeps retransmitting
 the request for a given = number of time and when it decides to give up it =
sends  a=20 CANCEL  message and then try = other proxy=20 server. Thus whenever
 a new SIP request is made UAC  = first tries=20 default proxy server  and  then everything 
 repeats once again. This may = create=20 some problem  because it = increase the call=20 set
 up time ( in worst case it may=20 happen at every intermediate proxy = server). Is=20 there
any method/way available in = SIP using which status of proxy server can be known = in advance=20 ?.
 This  information helps the UAC in keeping track current active list = of default=20
proxy server(s).
 
Thank You
Rafi Assadi H.M.
Silicon Automation = Sysytems
Bangalore, INDIA
 
 
------=_NextPart_000_00D6_01BFDAC6.F7784F60-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 20 06:26: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 GAA16073 for ; Tue, 20 Jun 2000 06:26: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 0D8FF44364; Tue, 20 Jun 2000 06:14:10 -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 452B944336 for ; Tue, 20 Jun 2000 06:14:07 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 03:26:19 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: sip@lists.bell-labs.com Date: Tue, 20 Jun 2000 03:26:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP URL telephone-subscriber 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 RFC2543bis now states that the user part may be a "telephone-subscriber" as defined in RFC2806 ( http://www.ietf.org/rfc/rfc2806.txt ). And that this is not discernable by BNF (hence the user=phone parameter). So is the following a valid SIP URL: sip:0w003585551234567; phone-context=+3585551234@gateway.com;user=phone Cheers, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 20 06:31: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 GAA16175 for ; Tue, 20 Jun 2000 06:31: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 6FD6D4436F; Tue, 20 Jun 2000 06:17:51 -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 E40994436B for ; Tue, 20 Jun 2000 06:17:47 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 03:30:00 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Tue, 20 Jun 2000 03:29: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 Please ignore the section Microsoft Outpatient 98 inserted in my last email: sip:0w003585551234567; phone-context=+3585551234@gateway.com;user=phone Cheers, Robert. _______________________________________________ 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 Jun 20 06:34: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 GAA16202 for ; Tue, 20 Jun 2000 06:34: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 5BE7A44376; Tue, 20 Jun 2000 06:22:10 -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 A812844336 for ; Tue, 20 Jun 2000 06:22:06 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 03:34:19 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Tue, 20 Jun 2000 03:34:15 -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 Argh. Sorry everyone for filling up your Inbox's. I also noticed it inserted a space into the URL. There weren't meant to be any spaces. sip:0w003585551234567;phone-context=+3585551234@gateway.com;user=phone Cheers, Robert. _______________________________________________ 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 Jun 20 06:47: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 GAA16500 for ; Tue, 20 Jun 2000 06:47: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 63A9244380; Tue, 20 Jun 2000 06:35:06 -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 9EA3D44336 for ; Tue, 20 Jun 2000 06:35:02 -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 GAA16462; Tue, 20 Jun 2000 06:46:51 -0400 (EDT) Message-Id: <200006201046.GAA16462@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: Tue, 20 Jun 2000 06:46:50 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-02.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 --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 : MIME media types for ISUP and QSIG Objects Author(s) : E. Zimmerer, A. Vemuri, L. Ong, M. Zonoun, M. Watson Filename : draft-ietf-sip-isup-mime-02.txt Pages : 6 Date : 19-Jun-00 This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048 [1]. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP between legacy systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-isup-mime-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-isup-mime-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000619125522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-isup-mime-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-isup-mime-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000619125522.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 Tue Jun 20 07:32: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 HAA17416 for ; Tue, 20 Jun 2000 07:32: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 3E74C44371; Tue, 20 Jun 2000 07:20:24 -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 B401844336 for ; Tue, 20 Jun 2000 07:20:18 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA16673; Tue, 20 Jun 2000 12:30:08 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Tue, 20 Jun 2000 12:03:15 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00062012261802.16272@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, 20 Jun 2000, Robert wrote: > RFC2543bis now states that the user part may be a "telephone-subscriber" as > defined in RFC2806 ( http://www.ietf.org/rfc/rfc2806.txt > ). And that this is not discernable by > BNF (hence the user=phone parameter). > > So is the following a valid SIP URL: > > sip:0w003585551234567;phone-context=+3585551234@gateway.com;user=phone > > Cheers, > > Robert. as i understand it this is not legal. there is a semi-colon in the user part. i think that all characters that appear in the userinfo section have to belong to the character set defined by user therefore the ; character needs to be escaped as follows: sip:0w003585551234567%3bphone-context=+3585551234@gateway.com;user=phone when this is parsed, the %3b should be unescaped back to ; to obtain the correct meaning. the bis does not make this clear in section 2 in the bnf. perhaps some explanatory text of the semantics of the bis is required within the explanation of telephone-subscriber to the effect of. "Any characters of the telephone-subscriber that do not exist in the character set of `user' MUST be escaped." 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 Jun 20 10: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 KAA24116 for ; Tue, 20 Jun 2000 10: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 684E544352; Tue, 20 Jun 2000 10:27:21 -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 0A93B44336 for ; Tue, 20 Jun 2000 10:27:18 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id JAA00727; Tue, 20 Jun 2000 09:39:02 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA19239; Tue, 20 Jun 2000 09:39:01 -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 JAA25689; Tue, 20 Jun 2000 09:39:00 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id JAA12331; Tue, 20 Jun 2000 09:39:00 -0500 (CDT) Date: Tue, 20 Jun 2000 09:39:00 -0500 (CDT) Message-Id: <200006201439.JAA12331@b04a45.exu.ericsson.se> To: sip@lists.bell-labs.com, rafi@sasi.com Subject: Re: [SIP] How to ping Prxoy Server ? 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 X-BeenThere: sip@lists.bell-labs.com > Is there > any method/way available in SIP using which status of proxy server can be known in advance ?. > This information helps the UAC in keeping track current active list of default > proxy server(s). > The OPTIONS method provides a very crude sort of ping for SIP. Combined with the Max-Forwards: header, you can ping various nodes along a call signalling path. But this may still not give you the information you desire; just because a proxy responds to an OPTIONS request, doesn't mean it is capable of handling calls. > Thank You > Rafi Assadi H.M. > Silicon Automation Sysytems > Bangalore, INDIA > -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 20 10:54: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 KAA24834 for ; Tue, 20 Jun 2000 10:54: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 CC20A44364; Tue, 20 Jun 2000 10:42:09 -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 BA59E44336 for ; Tue, 20 Jun 2000 10:42:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jun 20 10:52:05 EDT 2000 Received: by lists.bell-labs.com (Postfix) id EFB634434A; Tue, 20 Jun 2000 10:38:56 -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 A2E0C44349 for ; Tue, 20 Jun 2000 10:38:55 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA23190; Tue, 20 Jun 2000 09:38:52 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA23153; Tue, 20 Jun 2000 09:38:50 -0500 Message-ID: <394F81F2.D2B3886D@lucent.com> Date: Tue, 20 Jun 2000 09:38:42 -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: rafi Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] How to ping Prxoy Server ? References: <00d901bfda98$ddf0e760$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 a UAC which uses a default proxy server > (say proxy 1) whenever it has to send SIP request. It may so happen > that though transport connection is available at server where proxy is > suppose to run but proxy may not be responding due to > some reason ( may be due to temporary failure). UAC keeps > retransmitting the request for a given number of time and when it > decides to give up it sends a CANCEL message and then try other > proxy server. Thus whenever a new SIP request is made UAC first > tries default proxy server and then everything repeats once again. > This may create some problem because it increase the call set > up time ( in worst case it may happen at every intermediate proxy > server). Is there any method/way available in SIP using which status > of proxy server can be known in advance ?. This information helps > the UAC in keeping track current active list of default proxy > server(s). It appears that you are talking of some heart-beat mechanism; clearly, if you bind your UDP socket to the destination address, the second write should return ECONNREFUSED (see bis, Section 1.4.2). On TCP sockets, the connect() will fail. However, it appears that you are assuming that the transport is available between a UAC and the outbound proxy, just that the outbound proxy is "in a wierd state" (for the lack of a better description). SIP does not talk about any such heart-beat mechanisms to detect the health of a proxy from a UAC. You can build such a mechanism into your proxy and UAC, but it will only be useful within your domain. If all proxies in the world supported heart-beat across domains, I would presume that the resulting traffic would be something to contend with. Not to mention security. If a proxy in domain A wants to heart-beat a proxy in domain B, how does it authenticate itself? Is the heart-beat message encrypted? You run into a set formidable problems once you go down this path. Note that TCP provides a heart-beat mechanism via the SO_KEEPALIVE sock- et option. When this option is set for a TCP socket and no data has been exchanged across the socket (in either direction) for 2 hours, TCP sends out a probe to its peer, to which the peer must respond. However, this is of no help to your case unless your SIP transactions last for such a long duration. - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Tue Jun 20 11:44: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 LAA26770 for ; Tue, 20 Jun 2000 11:44: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 B2BD844374; Tue, 20 Jun 2000 11:32:38 -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 5D1914434F for ; Tue, 20 Jun 2000 11:32:33 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA05967; Tue, 20 Jun 2000 16:42:38 +0100 (BST) Message-ID: <394F90ED.B1A6EAEE@ubiquity.net> Date: Tue, 20 Jun 2000 16:42:37 +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 List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Max-Forwards + Proxies Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 6.26 of the bis draft if a proxy receives a request that has a zero value in the Max-Forwards header field it MUST NOT forward the request. Instead, for the OPTIONS or REGISTER methods, it MUST respond as the final recipient. For all other methods, the server returns 483 (Too many hops). How exactly should a Proxy respond as the final recipient to an OPTIONS? How should a proxy respond to a REGISTER if it is not responsible for registrations within the domain named in the Request-URI? In the case of other methods is sensible to always return 483? For example what if it was an INVITE and the Proxy knows from a location service a final response would have been 3XX/404. 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 Jun 20 12: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 MAA27484 for ; Tue, 20 Jun 2000 12:06: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 596684435B; Tue, 20 Jun 2000 11:54:09 -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 3D1E54434F for ; Tue, 20 Jun 2000 11:54:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jun 20 12:05:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1517D4434A; Tue, 20 Jun 2000 11:52:09 -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 A09AB44349 for ; Tue, 20 Jun 2000 11:52:08 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA20890; Tue, 20 Jun 2000 10:52:05 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA20885; Tue, 20 Jun 2000 10:52:04 -0500 Message-ID: <394F931C.B631C92C@lucent.com> Date: Tue, 20 Jun 2000 10:51:56 -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: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Statful proxy: Receiving Requests Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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: In the June 9th bis draft, Section 12.3.4 (Stateful Proxy: Receiving Requests) states: When a stateful proxy receives a request, it checks the To, From (including tags), Call-ID and CSeq against existing request records. I presume the To check does NOT include tags. Can someone corroborate this, please. Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Tue Jun 20 12:20: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 MAA27746 for ; Tue, 20 Jun 2000 12:20: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 9DAB144374; Tue, 20 Jun 2000 12:07:25 -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 31E8544352 for ; Tue, 20 Jun 2000 12:07:22 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id MAA02705; Tue, 20 Jun 2000 12:19:10 -0400 (EDT) Message-ID: <394F997E.CE8CA9B3@cisco.com> Date: Tue, 20 Jun 2000 12:19:10 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Statful proxy: Receiving Requests References: <394F931C.B631C92C@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 Vijay, I think it includes tags, since a brand new re-INVITE or BYE may have a tag in the To header. "Vijay K. Gurbani" wrote: > > Folks: > > In the June 9th bis draft, Section 12.3.4 (Stateful Proxy: Receiving > Requests) states: > > When a stateful proxy receives a request, it checks the To, > From (including tags), Call-ID and CSeq against existing > request records. > > I presume the To check does NOT include tags. Can someone corroborate > this, please. > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org > IN Architecture and Internet Software Group > 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 20 12:50: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 MAA28696 for ; Tue, 20 Jun 2000 12:50: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 6416944373; Tue, 20 Jun 2000 12:37:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from toto.oz.is (toto.oz.is [193.4.211.170]) by lists.bell-labs.com (Postfix) with ESMTP id 27F944434F for ; Tue, 20 Jun 2000 12:37:38 -0400 (EDT) Received: from kansas.intranet.oz.is (scarecrow.oz.is [193.4.211.95]) by toto.oz.is (8.9.3/8.9.3) with ESMTP id QAA15635 for ; Tue, 20 Jun 2000 16:54:35 GMT From: ozsip@oz.com Subject: Re: [SIP] proxy protocol conversion To: sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Tue, 20 Jun 2000 16:45:48 +0000 X-MIMETrack: Serialize by Router on OZ-ICE/OZ-Inc(Release 5.0.3 (Intl)|21 March 2000) at 20.06.2000 16:46:18 MIME-Version: 1.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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA28696 Hi. I would like to follow up on this. Let's assume we have two users, which both have clients which only support UDP. They have different home proxies, and those proxies are stateful, use TCP when possible and always insist on being included throughout any call going through them. Thus we have this setup with transport: Client A ------- UDP -------- Proxy A --------- TCP --------- Proxy B -------- UDP -------- Client B User A calls user B, and a call is successfully set up. Both proxy A and proxy B have include Record-Route headers in any proxied requests. Now let us assume that the code implementing the underlying session being established has a critical bug, and that when client A and B act on the agreed session description, they both crash violently. How will the proxies in-between ever discover that? After the ACK is sent by client A, the proxies never hear from the clients again! How is this handled? Best regards, Hörður K -- Hordur Kvaran Software Developer - OZ.COM Snorrabraut 54 - 105 Reykjavik - Iceland Tel: +354 535 0000 - Direct tel: +354 535 0013 Jonathan Rosenberg @lists.bell-labs.com on 17.06.2000 06:55:47 Sent by: sip-admin@lists.bell-labs.com To: Loita Jahnsson cc: sip@lists.bell-labs.com Subject: Re: [SIP] proxy protocol conversion Loita Jahnsson wrote: > > Hi, > > I kind of new in SIP design and have a couple of > basic questions regarding proxy protocol conversion. > > Assuming that "proxy protocol conversion" means > something like this: > > ---transport-1--> proxy ----transport-2--> > > For which cases are protocol conversion applicable > in a proxy: > > * when the proxy adds more data to the message, so it > cannot be stored within a UDP package when proxying > the message? Generally, determination of the transport to use for outgoing requests will be driven by preferences set in the SRV records. In this case, they would not be dependent on a change in size of the message. Normal SIP procesing of a message will normally not make it much bigger. In any case, the maximum UDP size is 64k, which you are unlikely to ever see in SIP. > > * when an outbound proxy receives a UDP package from > a UAC, stating transport=tcp in the Request-URI? Yes, in this case the protocol goes out TCP. This is spelled out (along with the above) in Section 1.4.2 of the bis draft. This section applies independnt of the protocol the request came in on, so it may result in a "conversion" if the outgoing protocol selected was different from the incoming. > > * when a proxy is configured to always go through > another proxy using TCP, disregarding any transport > parameters in the SIP message? You can always do that, although its not specified to work this way. You'll run into troubles if the next hop doesn't support that protocol. > > * when a proxy has one client which only knowns UDP > on one side and a client who only knows TCP on the > other (ie the attempt to contact the called client > with UDP fails)? This would be determined through transport parameters in registered Contacts, so conversion might take place here, yes. > If "proxy protocol conversions" refers to scenarios > like the ones mentioned above, what is it called when > you need to do this: > > caller-client ----request, transport1 ----> server > > caller-client <-- response, transport2 ---- same server :) > > (For example if the response for some reason would be > bigger than max UDP size). This is not supported. You could try to do it by putting a different transport in the Via header than the one you actually used, but I don't recommend doing that, since its unlikely to work. In any case, it sounds like you want the server to dynamically change the tranpsort for the response if the response comes in and its big; having the client set the protocol in the Via won't help that. -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 Tue Jun 20 20:40: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 UAA07000 for ; Tue, 20 Jun 2000 20: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 44E7C44381; Tue, 20 Jun 2000 20:27:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from turin.trillium.com (unknown [38.187.146.197]) by lists.bell-labs.com (Postfix) with ESMTP id 875E04433A for ; Tue, 20 Jun 2000 20:27:46 -0400 (EDT) Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 20 Jun 2000 17:52:45 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id RAA08974 for ; Tue, 20 Jun 2000 17:39:39 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 17:37:08 -0700 Message-ID: <8BBD33A986C5D311804000902719FF5D379919@aega.trillium.com> From: Aseem Agarwal To: "'sip@lists.bell-labs.com'" Cc: Srini Beereddy Date: Tue, 20 Jun 2000 17:37:07 -0700 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Question on "action" 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 Hi All, I have a question about the usage of "action" parameter in REGISTER request. According to the rfc2543bis [Sec 6.13] "It indicates whether the client wishes that the server proxy or redirect future requests intended for the client" Does this imply that a Network Server implementing a Registrar should also be able to function both as a proxy and a redirect server ? thanks, aseem _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 21 04:49: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 EAA24697 for ; Wed, 21 Jun 2000 04:49: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 76ABC4435A; Wed, 21 Jun 2000 04:36: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 9B5474433A for ; Wed, 21 Jun 2000 04:36:19 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA06351; Wed, 21 Jun 2000 09:45:33 +0100 (BST) From: "Jo Hornsby" To: Cc: Subject: RE: [SIP] proxy protocol conversion Date: Wed, 21 Jun 2000 09:45:32 +0100 Message-ID: <000301bfdb5d$0f558e90$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 In-Reply-To: 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 > Let's assume we have two users, which both have clients which > only support UDP. They have different home proxies, and those > proxies are stateful, use TCP when possible and always insist on > being included throughout any call going through them. > > Thus we have this setup with transport: > > Client A ------- UDP -------- Proxy A --------- TCP --------- Proxy B > -------- UDP -------- Client B > > User A calls user B, and a call is successfully set up. Both proxy > A and proxy B have include Record-Route headers in any proxied > requests. > > Now let us assume that the code implementing the underlying session > being established has a critical bug, and that when client A and B > act on the agreed session description, they both crash violently. > How will the proxies in-between ever discover that? After the ACK > is sent by client A, the proxies never hear from the clients again! > > How is this handled? I'm not massively confident that I'm understanding where there's a problem; is it because you are concerned that the TCP connection might persist unnecessarily indefinitely? Else I can't see where the "proxy protocol conversion" comes in? I guess the solution that jumps out at me is to have some sort of timer on a TCP connection, which causes it to be closed if there's been no activity for some period of time. If this is more a Call-Stateful issue, probably the best solution is for the proxies to mandate use of the "SIP Session Timer"; the draft on this is available from Henning's site. 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 Jun 21 04:56: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 EAA24758 for ; Wed, 21 Jun 2000 04:56: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 0C15444373; Wed, 21 Jun 2000 04:43:57 -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 A2D194433A for ; Wed, 21 Jun 2000 04:43:53 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA09258; Wed, 21 Jun 2000 09:53:58 +0100 (BST) From: "Jo Hornsby" To: "Aseem Agarwal" , Cc: "Srini Beereddy" Subject: RE: [SIP] Question on "action" parameter Date: Wed, 21 Jun 2000 09:53:58 +0100 Message-ID: <000401bfdb5e$3ca55460$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 In-Reply-To: <8BBD33A986C5D311804000902719FF5D379919@aega.trillium.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 > Hi All, > I have a question about the usage of "action" parameter in REGISTER > request. According to the rfc2543bis [Sec 6.13] > "It indicates whether the client wishes that the server proxy or redirect > future requests intended for the client" > > Does this imply that a Network Server implementing a Registrar should > also be able to function both as a proxy and a redirect server ? Not necessarily. If you look at the definition of a Registrar in section 1.3, you'll see that: "A registrar is a server that accepts REGISTER requests. A registrar is typically co-located with a proxy or redirect server and MAY offer location services." As you suggest, a Registrar is a logical role; the physical server may actually also look like a stateful proxy, in which case it will probably obey the action prescribed. However, in other cases a Registrar may be all that the physical server is. In this case, more-than-likely it's talking to some location server, which proxies/redirectservers also talk to. 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 Jun 21 09:43: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 JAA01474 for ; Wed, 21 Jun 2000 09:43: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 CEF8C44373; Wed, 21 Jun 2000 09:30:59 -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 702054435A for ; Wed, 21 Jun 2000 09:30:56 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FWI00501BEG8F@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 21 Jun 2000 13:42:16 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FWI00MLEBEGO7@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 21 Jun 2000 13:42:16 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FWI00D01BD0FH@dgismtp03.wcomnet.com> for sip@lists.bell-labs.com; Wed, 21 Jun 2000 13:41:24 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FWI00D01BCZF8@dgismtp03.wcomnet.com> for sip@lists.bell-labs.com; Wed, 21 Jun 2000 13:41:24 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FWI00C3JBCOK1@dgismtp03.wcomnet.com> for sip@lists.bell-labs.com; Wed, 21 Jun 2000 13:41:12 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Wed, 21 Jun 2000 13:42:03 +0000 Content-return: allowed Date: Wed, 21 Jun 2000 13:42:00 +0000 From: "McMurry, Kathleen" To: "'sip@lists.bell-labs.com'" Message-id: <75C79E507864D3118AFC00805FEAB7D85B398F@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_fJ1I5oc1mj29MOTO2zDmBg)" Subject: [SIP] tags in ACKs in rfc2543bis-00 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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. --Boundary_(ID_fJ1I5oc1mj29MOTO2zDmBg) Content-type: text/plain; charset=ISO-8859-1 I am confused about the new statement in Section 11.4 that states "A UAC copies the tag from the final response into the ACK, but it MUST NOT copy the tag into any subsequent requests unless the response was a 200-class response to an INVITE request." This seems to conflict with Section 4.2.2 which states "A proxy server receiving an ACK request after having send a 3xx, 4xx, 5xx, or 6xx response must make a determination about whether the ACK is for it, or for some user agent or proxy server further downstream. This determination is made by examining the tag in the To field." If the UAC doesn't copy the tag into the ACK, how is the proxy server supposed to make the determination that the ACK request is for it? Thanks, Kathleen McMurry --Boundary_(ID_fJ1I5oc1mj29MOTO2zDmBg) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable tags in ACKs in rfc2543bis-00

I am confused about = the new statement in Section 11.4 that states "A UAC copies the = tag from the final response into the ACK, but it MUST NOT copy the tag = into any subsequent requests unless the response was a 200-class = response to an INVITE request."

This seems to = conflict with Section 4.2.2 which states "A proxy server receiving = an ACK request after having send a 3xx, 4xx, 5xx, or 6xx response must = make a determination about whether the ACK is for it, or for some user = agent or proxy server further downstream.  This determination is = made by examining the tag in the To field."

If the UAC doesn't = copy the tag into the ACK, how is the proxy server supposed to make the = determination that the ACK request is for it?

Thanks,

Kathleen = McMurry

--Boundary_(ID_fJ1I5oc1mj29MOTO2zDmBg)-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 21 09: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 JAA02050 for ; Wed, 21 Jun 2000 09: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 852B64437D; Wed, 21 Jun 2000 09:46: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 869A64435A for ; Wed, 21 Jun 2000 09:46:13 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA18729; Wed, 21 Jun 2000 14:53:41 +0100 (BST) From: "Jo Hornsby" To: "McMurry, Kathleen" Cc: Subject: RE: [SIP] tags in ACKs in rfc2543bis-00 Date: Wed, 21 Jun 2000 14:53:39 +0100 Message-ID: <001101bfdb88$1a8ac340$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 In-Reply-To: <75C79E507864D3118AFC00805FEAB7D85B398F@ripexch001.mcit.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 > I am confused about the new statement in Section 11.4 that states "A > UAC copies the tag from the final response into the ACK, but it MUST > NOT copy the tag into any subsequent requests unless the response > was a 200-class response to an INVITE request." > > This seems to conflict with Section 4.2.2 which states "A proxy > server receiving an ACK request after having send a 3xx, 4xx, 5xx, > or 6xx response must make a determination about whether the ACK is > for it, or for some user agent or proxy server further downstream. > This determination is made by examining the tag in the To field." > > If the UAC doesn't copy the tag into the ACK, how is the proxy server > supposed to make the determination that the ACK request is for it? It does copy the tag into the ACK; it just doesn't copy the tag into any other requests. For instance, if the UA was to retry an INVITE (with a different CSeq, or something) after having received a non-2xx final response, it would be wrong for it to update the To header to include a tag that was in the response; only if the INVITE succeeds should the To header be updated. 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 Jun 21 11:40: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 LAA04365 for ; Wed, 21 Jun 2000 11:40: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 74E2C44373; Wed, 21 Jun 2000 11:28:18 -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 D6F2B4435A for ; Wed, 21 Jun 2000 11:28:02 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA24879; Wed, 21 Jun 2000 16:37:58 +0100 (BST) Message-ID: <3950E19D.EDA3F0E9@ubiquity.net> Date: Wed, 21 Jun 2000 16:39:09 +0100 From: Phil Hoffer Organization: Ubiquity Software Corporation 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] PGP Authentication Scheme Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, Section 15.1.1 of the rfc2543bis draft is missing information, and a BNF entry with respect to pgp-pubalgolrithm. Presumably, pgp-pubalgolrithm should be included in the BNF for pgp-params in section 15.1.1 Also some text about the parameter is required, e.g. what is the default value of pgp-pubalgolrithm if it is omitted from WWW-Authenticate header. Is it assumed to be RSA? Hope that helps Regards -- Phil Hoffer Ubiquity Software Corporation Software Developer Ubiquity House Tel: +44 (0) 1633-765600 Langstone Park Fax: +44 (0) 1633-765601 Newport NP18 2LH URL: http://www.ubiquity.net mailto:phoffer@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 Jun 21 13:00: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 NAA08434 for ; Wed, 21 Jun 2000 13:00: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 E4C7444382; Wed, 21 Jun 2000 12:47:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 260A844339 for ; Wed, 21 Jun 2000 12:47:13 -0400 (EDT) Received: by webmail.speedventures.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 18:54:54 +0200 Message-ID: <2160ABC55998D311821900508B2C14BB269D71@webmail.speedventures.com> From: =?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?= To: "'sip@lists.bell-labs.com'" Date: Wed, 21 Jun 2000 18:54:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Announcement of SIP Forum Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 NAA08434 Hi, I just wanted to invite those interested to participate in the SIP Forum work. SIP Forum was announced yesterday at the Voice on the net Europe conference to be a natural meeting place for those companies and individuals working with SIP. The forum will NOT do any technical work, all such ideas should be forwarded to the IETF, so there will be no overlap between the organizations. SIP Forum will spread information on how to utilize SIP as a tool for service creation, how to deploy SIP in real networks etc. It will also list available products making use of SIP. If you have such products available for purchase right now, please let the SIP forum webmaster know about them. The organization is an open non profit Swedish association, open to anyone that can contribute on the SIP information sharing, on a not so very technical level. More information is found at http://www.sipforum.com Welcome! Jörgen Björkner, Chairman of SIP Forum _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 21 13:47: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 NAA09734 for ; Wed, 21 Jun 2000 13:47: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 9B4EA4437C; Wed, 21 Jun 2000 13:35:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhost.ttimail.com (216-86-19-4.caprock.net [216.86.19.4]) by lists.bell-labs.com (Postfix) with ESMTP id 5580444339 for ; Wed, 21 Jun 2000 13:34:58 -0400 (EDT) Received: by mailhost.tti.net with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 12:46:53 -0500 Message-ID: From: Kevin Summers To: =?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?= , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Announcement of SIP Forum Date: Wed, 21 Jun 2000 12:46:52 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA09734 Interesting...there is nothing at www.sipforum.com .... however, a site much like what you describe is at www.sipforum.org. -----Original Message----- From: Jörgen Björkner [mailto:Jorgen.Bjorkner@hotsip.com] Sent: Wednesday, June 21, 2000 11:55 AM To: 'sip@lists.bell-labs.com' Subject: [SIP] Announcement of SIP Forum Hi, I just wanted to invite those interested to participate in the SIP Forum work. SIP Forum was announced yesterday at the Voice on the net Europe conference to be a natural meeting place for those companies and individuals working with SIP. The forum will NOT do any technical work, all such ideas should be forwarded to the IETF, so there will be no overlap between the organizations. SIP Forum will spread information on how to utilize SIP as a tool for service creation, how to deploy SIP in real networks etc. It will also list available products making use of SIP. If you have such products available for purchase right now, please let the SIP forum webmaster know about them. The organization is an open non profit Swedish association, open to anyone that can contribute on the SIP information sharing, on a not so very technical level. More information is found at http://www.sipforum.com Welcome! Jörgen Björkner, Chairman of SIP Forum _______________________________________________ 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 Jun 21 17:56: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 RAA13705 for ; Wed, 21 Jun 2000 17:56: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 DAD1C44355; Wed, 21 Jun 2000 17:44: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 DB09D44339 for ; Wed, 21 Jun 2000 17:44: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 RAA28507; Wed, 21 Jun 2000 17:56:13 -0400 (EDT) Message-ID: <395139FD.45921C74@cs.columbia.edu> Date: Wed, 21 Jun 2000 17:56: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: =?iso-8859-1?Q?J=F6rgen=20Bj=F6rkner?= Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Announcement of SIP Forum References: <2160ABC55998D311821900508B2C14BB269D71@webmail.speedventures.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 One of the ideas that was discussed at the Telia dinner in Stockholm was whether there was a need for a basic SIP certification program. There are obvious pluses and minuses for this, but my concern is that if this is a real need, I can think of a few organizations (looking for post-H.323 work...) that I would rather *not* see doing this. -- 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 Jun 21 19:01: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 TAA14506 for ; Wed, 21 Jun 2000 19:01: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 A9EDE44384; Wed, 21 Jun 2000 18:48:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by lists.bell-labs.com (Postfix) with ESMTP id D4B6944339 for ; Wed, 21 Jun 2000 18:48:43 -0400 (EDT) Received: from MATT.ascend.com (ts013d29.den-co.concentric.net [207.155.170.137]) by renown.cnchost.com id TAA00069; Wed, 21 Jun 2000 19:00:47 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-Id: <4.3.1.2.20000621090116.00bc5190@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 21 Jun 2000 13:31:39 -0700 To: Henry Sinnreich From: Matt Holdrege Subject: RE: [SIP] SIP->XML->SOAP Cc: sip@lists.bell-labs.com In-Reply-To: References: <394B0817.4999E642@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 07:09 AM 6/18/00 -0500, Henry Sinnreich wrote: > >> SIP->XML would converge the SIP methods and required > >parameters to XML and > >> allows the introduction of a DTD or schema to define > >the syntax of a valid > >> SIP message. > >Do not forget that endangering the deployment of SIP as is, >would set IP telephony back for a generation and leave the field >for "softswitches" and other such nonsense. Nobody on this >mailing list would then live to see true/open Internet >communications, but just the old circuit switch central control >model with its terrible signaling. Just using IP as a cheap >wire. Henry, This is the first time I recall seeing "softswitches" being denigrated on an IETF list. I would hope you realize that they are an enabler to get the circuit switched world to migrate to open communications? Saying that Softswitches will preserve the circuit switched world with it's "terrible signalling" is a bit short-sighted. You should also realize that SIP is doing quite well in the area of market acceptance. The more people buy into SIP the more evolution will be required. Change is inevitable even though we must try to manage it well. XML is one such change that seems (to me) to be inevitable. So it would be better to try and manage the interactions with SIP and XML here in the IETF rather than elsewhere. Besides, it's part of the openess that we all should encourage. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 21 22:04: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 WAA17432 for ; Wed, 21 Jun 2000 22: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 8C92844382; Wed, 21 Jun 2000 21:52:03 -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 6865644339 for ; Wed, 21 Jun 2000 21:52:00 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id WAA09646; Wed, 21 Jun 2000 22:04:08 -0400 (EDT) Message-ID: <066201bfdbee$979b73f0$3102a8c0@broadsoft.com> From: "Brett Tate" To: "SIPbell-labs" Date: Wed, 21 Jun 2000 22:07:18 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_065F_01BFDBCD.106FE350" 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] Hold & then re-INVITE without media Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_065F_01BFDBCD.106FE350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A -- Invite (hold media) --> B <-- 200 (hold media) -- B --- Ack --------------------> B After A requests B to hold, how can A without providing media request=20 that B stop holding and provide media? I just wanted to verify that the following should work unless B=20 has also pushed the hold button. A -- Invite -------------------> B <-- 200 (media) --------- B --- Ack (media) --------> B ------=_NextPart_000_065F_01BFDBCD.106FE350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A -- Invite (hold media) --> B
  <-- 200 (hold media) --   = B
   --- Ack --------------------> =20 B
 
After A requests B to hold, how can A without = providing media=20 request
that B stop holding and = provide=20 media?
 
I just wanted to verify that the following should = work unless=20 B
has also pushed the hold button.
 
A -- Invite -------------------> B
  <-- 200 (media) ---------   = B
   --- Ack (media) -------->  = B
 
 
------=_NextPart_000_065F_01BFDBCD.106FE350-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 22 01:11: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 BAA20494 for ; Thu, 22 Jun 2000 01:11: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 1E45A44387; Thu, 22 Jun 2000 00:54:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 1BA0E44339 for ; Thu, 22 Jun 2000 00:54:29 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id KAA25459 for ; Thu, 22 Jun 2000 10:35:07 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 22 Jun 2000 10:35:07 +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 KAA03323 for ; Thu, 22 Jun 2000 10:35:04 +0530 (IST) Message-ID: <007301bfdc07$57a6e360$8c40000a@sasi.com> From: "rafi" To: Date: Thu, 22 Jun 2000 10:34:27 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01BFDC35.712CC4C0" 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] Phone user in Buddy 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 This is a multi-part message in MIME format. ------=_NextPart_000_0070_01BFDC35.712CC4C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Can I have phone user in my buddy list ?.=20 Thus, is it possible for a gateway to act as PA? In that case gateway may need some support from PSTN world.=20 Thank You Rafi Assadi H.M Silicon Automation Systems Bangalore, INDIA ------=_NextPart_000_0070_01BFDC35.712CC4C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
 
     Can I have = phone user in=20 my buddy list ?.
Thus,  is it possible for a = gateway to act as=20 PA?
In that case  gateway may need = some support=20 from
PSTN world.
 
 
Thank You
Rafi Assadi H.M
Silicon Automation Systems
Bangalore, = INDIA
------=_NextPart_000_0070_01BFDC35.712CC4C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 22 02:55: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 CAA22049 for ; Thu, 22 Jun 2000 02:55: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 D14B34436F; Thu, 22 Jun 2000 02:42:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 356FF44339 for ; Thu, 22 Jun 2000 02:42:16 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id MAA00045 for ; Thu, 22 Jun 2000 12:22:55 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 22 Jun 2000 12:22:54 +0000 (IST) Received: from localhost (srinath@localhost) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id MAA04951 for ; Thu, 22 Jun 2000 12:22:52 +0530 (IST) Date: Thu, 22 Jun 2000 12:22:51 +0530 (IST) From: A Srinath To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Caller receives responses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 have a doubt regarding the number of responses that a caller may receive after having sent an INVITE request. Section 11.3 of RFC 2543 says Multiple responses may arrive at a UAC for a single INVITE request due to a forking proxy. But the algorithm outlined in section 12.4 ensures that only one response is sent by the proxy upstream. If this behavior is followed by the proxy then how does a UAC receive multiple responses, or section 11.3 means all responses including provisional? Regards, Srinath A Silicon Automation Systems Phone: 5276100, 5276108 extn 4220 #1309, 10th Main, HAL III Stage Bangalore 560 008, India _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 22 05:22: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 FAA24064 for ; Thu, 22 Jun 2000 05:22: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 C01AC44382; Thu, 22 Jun 2000 05:09:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from insynergy.com (unknown [63.74.114.149]) by lists.bell-labs.com (Postfix) with ESMTP id 3197644339 for ; Thu, 22 Jun 2000 05:09:55 -0400 (EDT) Received: from FEIDY [212.87.204.214] by insynergy.com with ESMTP (SMTPD32-5.05) id ACA18750116; Thu, 22 Jun 2000 05:30:09 -0400 Message-ID: <006601bfdc2b$387417a0$0ac8c880@FEIDY> From: "Fernando Orus" To: Date: Thu, 22 Jun 2000 11:20:39 +0200 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] Sending 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 Hi all, I haven't found anything related to sending DTMFs in the documentation I've read about SIP. Are you expected to send DTMFs in band within the audio stream? Thanks in advance, Fernando Orus _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 22 05:28: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 FAA24128 for ; Thu, 22 Jun 2000 05:28: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 AF06A44388; Thu, 22 Jun 2000 05:16: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 546BB44384 for ; Thu, 22 Jun 2000 05:16:05 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA05063; Thu, 22 Jun 2000 10:25:51 +0100 (BST) From: "Jo Hornsby" To: "A Srinath" , Subject: RE: [SIP] Caller receives responses Date: Thu, 22 Jun 2000 10:25:50 +0100 Message-ID: <001a01bfdc2b$daf3f9f0$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 In-Reply-To: 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 > I have a doubt regarding the number of responses that a caller may > receive after having sent an INVITE request. > > Section 11.3 of RFC 2543 says > Multiple responses may arrive at a UAC for a single INVITE request > due to a forking proxy. > > But the algorithm outlined in section 12.4 ensures that only one > response is sent by the proxy upstream. Not quite. The problem with the code in section 12.4 is that it doesn't tell the whole story (else proxy-implementors would be getting a free ride, eh? (:&). It waits until either the request is CANCELled, a 2xx response is received (on any branch), or non-2xx final responses are received on all branches; you don't get to see what happens after that. If you read the text following the code, you'll see under the 2xx entry that "The proxy MUST forward the response upstream towards the client". Now I would guess that most proxies CANCEL outstanding branches once they've seen a 2xx (even though it's only a "MAY"); however, this does not preclude a 2xx and CANCEL "crossing on the wire". Furthermore, in certain conditions, a client may see multiple non-2xx class responses to a request as the result of a downstream forking proxy being naughty. (This scenario is documented in section 4.2.2.) Therefore, you cannot assume that a request will result in at most one final response. The multiple non-2xx class case may be reasonably unlikely, but the multiple 2xx case is most definitely a reality. > If this behavior is followed by the proxy then how does a UAC > receive multiple responses, or section 11.3 means all responses > including provisional? My feeling that 11.3 is leaning more towards "Multiple final responses". Of course, multiple (in the sense that they're from different servers) provisional (non-100) is also possible, and probably desirable in the face of Session Progress. Me -- I'm just glad I pulled the proxy straw. &:) 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 Jun 22 05:46: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 FAA24324 for ; Thu, 22 Jun 2000 05:46: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 2D7AB4438E; Thu, 22 Jun 2000 05:33:50 -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 CF39844383 for ; Thu, 22 Jun 2000 05:33:45 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA10245; Thu, 22 Jun 2000 10:44:03 +0100 (BST) Message-ID: <3951DFE3.CEBFA142@ubiquity.net> Date: Thu, 22 Jun 2000 10:44:03 +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: Fernando Orus Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Sending DTMF References: <006601bfdc2b$387417a0$0ac8c880@FEIDY> 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 Fernando Orus wrote: > > Hi all, > I haven't found anything related to sending DTMFs in the documentation I've > read about SIP. Are you expected to send DTMFs in band within the audio > stream? > Thanks in advance, > Fernando Orus There is no definitive agreed answer, but the basic options are that dtmf signalling gets sent in a SIP INFO message (draft-culpepper-sip-info-event-00.txt) or is carried encoded within the RTP stream (RFC 2833). Look back at the list archives for a discussion of their relative merits, both methods could even coexist. 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 Jun 22 05:53: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 FAA24520 for ; Thu, 22 Jun 2000 05:53: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 DAC1E44386; Thu, 22 Jun 2000 05:39:46 -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 5412544339 for ; Thu, 22 Jun 2000 05:39:43 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 02:52:13 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Gethin Liddell'" , sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Thu, 22 Jun 2000 02:52: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 Gethin, telephone-subscriber can also contain escaped private prefixes - is there any overlap in the character set that must be escaped for a SIP user field and those that can be escaped for a private prefix ? I couldn't see any at first glance - in fact the semi-colon is the only character I could find that needs to be escaped (if you ignore possibility of quoted string in the future-extension field). Robert. -----Original Message----- From: Gethin Liddell [mailto:gethin@ubiquity.net] Sent: Tuesday, June 20, 2000 7:03 PM To: Fairlie-Cuninghame, Robert; sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. On Tue, 20 Jun 2000, Robert wrote: > RFC2543bis now states that the user part may be a "telephone-subscriber" as > defined in RFC2806 ( http://www.ietf.org/rfc/rfc2806.txt > ). And that this is not discernable by > BNF (hence the user=phone parameter). > > So is the following a valid SIP URL: > > sip:0w003585551234567;phone-context=+3585551234@gateway.com;user=phone > > Cheers, > > Robert. as i understand it this is not legal. there is a semi-colon in the user part. i think that all characters that appear in the userinfo section have to belong to the character set defined by user therefore the ; character needs to be escaped as follows: sip:0w003585551234567%3bphone-context=+3585551234@gateway.com;user=phone when this is parsed, the %3b should be unescaped back to ; to obtain the correct meaning. the bis does not make this clear in section 2 in the bnf. perhaps some explanatory text of the semantics of the bis is required within the explanation of telephone-subscriber to the effect of. "Any characters of the telephone-subscriber that do not exist in the character set of `user' MUST be escaped." 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 22 05:55: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 FAA24534 for ; Thu, 22 Jun 2000 05: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 D002544378; Thu, 22 Jun 2000 04:37:21 -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 ACD5644339 for ; Thu, 22 Jun 2000 04:37:16 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA23300; Thu, 22 Jun 2000 09:47:27 +0100 (BST) Message-ID: <3951D29D.BFA3E6C4@ubiquity.net> Date: Thu, 22 Jun 2000 09:47:26 +0100 From: Michael Doyle Organization: Ubiquity Software Corporation X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip-implementors@cs.columbia.edu, sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Launch of www.sipcenter.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 UBIQUITY SOFTWARE LAUNCHES WWW.SIPCENTER.COM WITH CO-SPONSORSHIP FROM SUN MICROSYSTEMS AND TELECOM TECHNOLOGIES SIP Center - an independent portal dedicated to the acceleration of the commercial development of Session Initiation Protocol software. VON, Stockholm, Sweden, June 20th, 2000 - Ubiquity Software Corporation, a major developer of 'End to End' SIP Service Solutions, today announced the launch of the new web site: http://www.sipcenter.com - a portal dedicated to the development and deployment of SIP (Session Initiation Protocol) based products. Ubiquity's co-sponsors, Sun Microsystems and telecom technologies, will be assisting with promotion, next generation technologies and services. The SIP Center web site, designed for both technical and commercial use, is an open and independent site where SIP ideas and views can be exchanged. With a unique Test Bed Area, SIP software developers can access to SIP software for interoperability testing 24hrs a day, 7 days a week, 365 days a year. There are no membership fees or joining process and all companies are invited to participate in the exchange of ideas and news items related to the SIP community. Interactive forums have been setup to facilitiate rapid exchange of information. The SIP Center is actively seeking sponsorship from other companies and organisations. -- Michael Doyle Ubiquity Software Corporation Chief Technology Officer Ubiquity House Tel: +44 (0) 1633-765600 Langstone Park Fax: +44 (0) 1633-765601 Newport NP18 2LH URL: 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 Jun 22 07:06: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 HAA25622 for ; Thu, 22 Jun 2000 07:06: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 4838544383; Thu, 22 Jun 2000 06:49:08 -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 2F57044339 for ; Thu, 22 Jun 2000 06:49:01 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA07858; Thu, 22 Jun 2000 11:59:05 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Thu, 22 Jun 2000 11:01:48 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00062211545801.21137@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 Hi, Sorry, not 100% sure what you mean here. Yes, private-prefix (rfc 2806 - TelURI) does allow characters that will need to be escaped when printed/sent or what ever because of the escaping defined in rfc 2396 (Generic URI). Examples of these characters are `"', `#', `<' and `>' because they are used as delimiters else where. (in fact `%' also cannot exist in its own right as it is defined as being the escape character delimiter). However, as far as the Tel URI rfc (2806) is concerend, the character @ (for example) will not have to be escaped. This, of course, will not be valid in the sipurl as it is used to separate the `userinfo' and `hostinfo' elements and will need to be escaped. For example, if the phone-context is actually stored as: "Context1@Context2" then the tel url will have to look like: tel:+12345;phone-context=%22Context1@Context2%22 however, it would NOT be valid to just enter this as a sip url as follows: sip:+12345;phone-context=%22Context1@Context2%22@company.com;user=phone for the obvious problem of the @. this would need to be translated to: sip:+12345;phone-context=%22Context1%40Context2%22@company.com;user=phone as for other characters that need to be escaped? The tel URI set of escaped characters will be a subset of the characters that need to be escaped for the `user' definition. So as long as the escaping is done to the more restrictive `user' element, all will be OK. This property is explaind in the rfc 2543 (and bis) in section 2: "Note that reserved characters have to be escaped and that the set of characters reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding." As for the future-extension and the quoted string, this could still not exist in its original format. i.e. the quotes and any other characters that are not valid URI characters (as defined in rfc 2396) within the quotes will have to be escaped. HTH gethin On Thu, 22 Jun 2000, Fairlie-Cuninghame, Robert wrote: > Hi Gethin, > > telephone-subscriber can also contain escaped private prefixes - is there > any overlap in the character set that must be escaped for a SIP user field > and those that can be escaped for a private prefix ? I couldn't see any at > first glance - in fact the semi-colon is the only character I could find > that needs to be escaped (if you ignore possibility of quoted string in the > future-extension field). > > Robert. > > -----Original Message----- > From: Gethin Liddell [mailto:gethin@ubiquity.net] > Sent: Tuesday, June 20, 2000 7:03 PM > To: Fairlie-Cuninghame, Robert; sip@lists.bell-labs.com > Subject: RE: [SIP] SIP URL telephone-subscriber syntax. > > > On Tue, 20 Jun 2000, Robert wrote: > > RFC2543bis now states that the user part may be a "telephone-subscriber" > as > > defined in RFC2806 ( http://www.ietf.org/rfc/rfc2806.txt > > ). And that this is not discernable > by > > BNF (hence the user=phone parameter). > > > > So is the following a valid SIP URL: > > > > sip:0w003585551234567;phone-context=+3585551234@gateway.com;user=phone > > > > Cheers, > > > > Robert. > > as i understand it this is not legal. there is a semi-colon > in the user part. i think that all characters that appear in the > userinfo section have to belong to the character set defined by user > > therefore the ; character needs to be escaped as follows: > > sip:0w003585551234567%3bphone-context=+3585551234@gateway.com;user=phone > > when this is parsed, the %3b should be unescaped back to ; to obtain > the correct meaning. > > the bis does not make this clear in section 2 in the bnf. perhaps some > explanatory text of the semantics of the bis is required within the > explanation of telephone-subscriber to the effect of. > > "Any characters of the telephone-subscriber that do not exist in the > character set of `user' MUST be escaped." > > 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 -- 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 Jun 22 10:09: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 KAA06424 for ; Thu, 22 Jun 2000 10:09: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 EC0B54437F; Thu, 22 Jun 2000 09:56:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from giasmd01.vsnl.net.in (giasmd01.vsnl.net.in [202.54.6.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3EA544339 for ; Thu, 22 Jun 2000 09:56:39 -0400 (EDT) Received: from josetel (m36.chn.vsnl.net.in [202.54.35.80]) by giasmd01.vsnl.net.in (8.9.3/8.9.3) with SMTP id TAA29231; Thu, 22 Jun 2000 19:44:42 +0530 (IST) Message-ID: <00a701bfdc2e$28fc1a40$a164a8c0@josetel> From: "Jose Cherian. P." To: "Gethin Liddell" , "Fairlie-Cuninghame, Robert" , References: <00062211545801.21137@gethin> Subject: Re: [SIP] SIP URL telephone-subscriber syntax. Date: Thu, 22 Jun 2000 19:42:09 +1000 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 Hi I am new to SIP Is there any open SIP stack available for SIP? pls help thanks in advance.. Jose Cherian. P. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 22 10:33: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 KAA06860 for ; Thu, 22 Jun 2000 10:33: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 3A41144389; Thu, 22 Jun 2000 10:21:12 -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 5E65944384 for ; Thu, 22 Jun 2000 10:21:08 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA18143; Thu, 22 Jun 2000 10:32:59 -0400 (EDT) Message-ID: <3952239A.150B2E8D@cisco.com> Date: Thu, 22 Jun 2000 10:32:58 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: A Srinath , sip@lists.bell-labs.com Subject: Re: [SIP] Caller receives responses References: <001a01bfdc2b$daf3f9f0$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 While we are here, I would like to hear what proxy implementors think about receiving multiple final respones on a single branch. Is it reasonable to simply drop final responses received after the first one ?? I guess, dropping 200 response is not good, but it is very unlikely that a 200 response is received on a branch after a non-200 final response. If the proxy decides to forward all 200 responses upstream, regardless of the state of the branch and transaction, the branch state gets kind of messy. Also, it was suggested on this list that proxies should not drop final responses which do not append a tag to the To header. If a proxy tries to be lenient and does this, it complicates matters even more. Comments ?? Shail Jo Hornsby wrote: > > > I have a doubt regarding the number of responses that a caller may > > receive after having sent an INVITE request. > > > > Section 11.3 of RFC 2543 says > > Multiple responses may arrive at a UAC for a single INVITE request > > due to a forking proxy. > > > > But the algorithm outlined in section 12.4 ensures that only one > > response is sent by the proxy upstream. > > Not quite. The problem with the code in section 12.4 is that it > doesn't tell the whole story (else proxy-implementors would be > getting a free ride, eh? (:&). It waits until either the request > is CANCELled, a 2xx response is received (on any branch), or non-2xx > final responses are received on all branches; you don't get to > see what happens after that. > > If you read the text following the code, you'll see under the 2xx > entry that "The proxy MUST forward the response upstream towards > the client". Now I would guess that most proxies CANCEL outstanding > branches once they've seen a 2xx (even though it's only a "MAY"); > however, this does not preclude a 2xx and CANCEL "crossing on the > wire". > > Furthermore, in certain conditions, a client may see multiple > non-2xx class responses to a request as the result of a downstream > forking proxy being naughty. (This scenario is documented in section > 4.2.2.) > > Therefore, you cannot assume that a request will result in at > most one final response. The multiple non-2xx class case may be > reasonably unlikely, but the multiple 2xx case is most definitely > a reality. > > > If this behavior is followed by the proxy then how does a UAC > > receive multiple responses, or section 11.3 means all responses > > including provisional? > > My feeling that 11.3 is leaning more towards "Multiple final > responses". > > Of course, multiple (in the sense that they're from different > servers) provisional (non-100) is also possible, and probably > desirable in the face of Session Progress. > > Me -- I'm just glad I pulled the proxy straw. &:) > > 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 Jun 22 10:59: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 KAA07358 for ; Thu, 22 Jun 2000 10:59: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 514F744397; Thu, 22 Jun 2000 10:46:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by lists.bell-labs.com (Postfix) with ESMTP id 581E544339 for ; Thu, 22 Jun 2000 10:46:21 -0400 (EDT) Received: from gmd.de ([141.12.156.87]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id QAA28385 for ; Thu, 22 Jun 2000 16:58:18 +0200 (MET DST) Message-ID: <39522A74.4114118@gmd.de> Date: Thu, 22 Jun 2000 17:02:12 +0200 From: Rolf Reinema Organization: GMD-TKT X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,en-US,en-GB,de,de-AT,de-DE,de-CH,ja MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------D7B33844336F1C00A7DE6729" Subject: [SIP] subscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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. --------------D7B33844336F1C00A7DE6729 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe --------------D7B33844336F1C00A7DE6729 Content-Type: text/x-vcard; charset=us-ascii; name="reinema.vcf" Content-Description: Card for Rolf Reinema Content-Disposition: attachment; filename="reinema.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Reinema;Rolf tel;fax:+49 6151 / 869 - 224 tel;home:+49 6157 / 88 202 tel;work:+49 6151 / 869 - 358 x-mozilla-html:FALSE url:http://tkt.gmd.de org:GMD-TKT adr:;;Rheinstrasse 75;Darmstadt;;D-64295;Germany version:2.1 email;internet:reinema@gmd.de fn:Rolf Reinema end:vcard --------------D7B33844336F1C00A7DE6729-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 22 11:09: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 LAA07771 for ; Thu, 22 Jun 2000 11:09: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 3DC21443B1; Thu, 22 Jun 2000 10:52:36 -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 675E4443AD for ; Thu, 22 Jun 2000 10:52:32 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA14796; Thu, 22 Jun 2000 16:02:27 +0100 (BST) From: "Jo Hornsby" To: Cc: "A Srinath" , Subject: RE: [SIP] Caller receives responses Date: Thu, 22 Jun 2000 16:02:27 +0100 Message-ID: <000701bfdc5a$e1972690$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <3952239A.150B2E8D@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 > While we are here, I would like to hear what proxy implementors think > about receiving multiple final respones on a single branch. Is it > reasonable to simply drop final responses received after the first > one ?? If you have state, and the response is not 2xx, then maybe so. The reason I say this is because I would guess that if this situation has arisen, then it's probably due to some server responding in a very tardy fashion; if this is the case, then it's not so unlikely that any proxies along the route have dropped transaction state, and thus they'll be forwarded the response statelessly. One reason against this behaviour is that I guess you could still be pending results on some branches when you receive a different final response on a branch that was marked as done. This probably would tend to indicate that a downstream server is very ill, however. Of course, if the response is to an INVITE, you really should ACK if it's non-2xx class... > I guess, dropping 200 response is not good, but it is very > unlikely that a 200 response is received on a branch after a non-200 > final response. I don't see that it's any less likely than receiving any other different response. > If the proxy decides to forward all 200 responses > upstream, regardless of the state of the branch and transaction, the > branch state gets kind of messy. How so? If the proxy still has state on the transaction, then the branch will either be done or it won't. Forwarding 2xx class upstream in a stateless fashion doesn't really complicate this; you just set the boolean unconditionally. &:) > Also, it was suggested on this list that proxies should not drop > final responses which do not append a tag to the To header. If a proxy > tries to be lenient and does this, it complicates matters even more. I can see ambiguity arising with ACKs...is there anything else? - 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 Jun 22 11:21: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 LAA08313 for ; Thu, 22 Jun 2000 11:21: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 068344437F; Thu, 22 Jun 2000 11:08:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id 9459844339 for ; Thu, 22 Jun 2000 11:08:14 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id RAA19417 for ; Thu, 22 Jun 2000 17:19:51 +0200 From: Satish.Yadav@amns.alcatel.fr Received: from amns.alcatel.fr (dnsamns.amns.alcatel.fr [159.217.103.207]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with SMTP id RAA06142 for ; Thu, 22 Jun 2000 17:19:34 +0200 (MET DST) Received: from POP3 Client by amns.alcatel.fr (ccMail Link to SMTP R8.10.00) id AA961689169; Thu, 22 Jun 2000 21:53:49 +0530 Message-Id: <0006229616.AA961689169@amns.alcatel.fr> X-Mailer: ccMail Link to SMTP R8.10.00 Date: Thu, 22 Jun 2000 20:48:49 +0530 To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Description: "cc:Mail Note Part" Subject: [SIP] unsubscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 LAA08313 -----Original Message----- From: ozsip@oz.com [mailto:ozsip@oz.com ] Sent: 20 June 2000 21:16 To: sip@lists.bell-labs.com Subject: Re: [SIP] proxy protocol conversion Hi. I would like to follow up on this. Let's assume we have two users, which both have clients which only support UDP. They have different home proxies, and those proxies are stateful, use TCP when possible and always insist on being included throughout any call going through them. Thus we have this setup with transport: Client A ------- UDP -------- Proxy A --------- TCP --------- Proxy B -------- UDP -------- Client B User A calls user B, and a call is successfully set up. Both proxy A and proxy B have include Record-Route headers in any proxied requests. Now let us assume that the code implementing the underlying session being established has a critical bug, and that when client A and B act on the agreed session description, they both crash violently. How will the proxies in-between ever discover that? After the ACK is sent by client A, the proxies never hear from the clients again! How is this handled? Best regards, Hörður K -- Hordur Kvaran Software Developer - OZ.COM Snorrabraut 54 - 105 Reykjavik - Iceland Tel: +354 535 0000 - Direct tel: +354 535 0013 Jonathan Rosenberg @lists.bell-labs.com on 17.06.2000 06:55:47 Sent by: sip-admin@lists.bell-labs.com To: Loita Jahnsson cc: sip@lists.bell-labs.com Subject: Re: [SIP] proxy protocol conversion Loita Jahnsson wrote: > > Hi, > > I kind of new in SIP design and have a couple of > basic questions regarding proxy protocol conversion. > > Assuming that "proxy protocol conversion" means > something like this: > > ---transport-1--> proxy ----transport-2--> > > For which cases are protocol conversion applicable > in a proxy: > > * when the proxy adds more data to the message, so it > cannot be stored within a UDP package when proxying > the message? Generally, determination of the transport to use for outgoing requests will be driven by preferences set in the SRV records. In this case, they would not be dependent on a change in size of the message. Normal SIP procesing of a message will normally not make it much bigger. In any case, the maximum UDP size is 64k, which you are unlikely to ever see in SIP. > > * when an outbound proxy receives a UDP package from > a UAC, stating transport=tcp in the Request-URI? Yes, in this case the protocol goes out TCP. This is spelled out (along with the above) in Section 1.4.2 of the bis draft. This section applies independnt of the protocol the request came in on, so it may result in a "conversion" if the outgoing protocol selected was different from the incoming. > > * when a proxy is configured to always go through > another proxy using TCP, disregarding any transport > parameters in the SIP message? You can always do that, although its not specified to work this way. You'll run into troubles if the next hop doesn't support that protocol. > > * when a proxy has one client which only knowns UDP > on one side and a client who only knows TCP on the > other (ie the attempt to contact the called client > with UDP fails)? This would be determined through transport parameters in registered Contacts, so conversion might take place here, yes. > If "proxy protocol conversions" refers to scenarios > like the ones mentioned above, what is it called when > you need to do this: > > caller-client ----request, transport1 ----> server > > caller-client <-- response, transport2 ---- same server :) > > (For example if the response for some reason would be > bigger than max UDP size). This is not supported. You could try to do it by putting a different transport in the Via header than the one you actually used, but I don't recommend doing that, since its unlikely to work. In any case, it sounds like you want the server to dynamically change the tranpsort for the response if the response comes in and its big; having the client set the protocol in the Via won't help that. -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 Thu Jun 22 11:32: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 LAA08527 for ; Thu, 22 Jun 2000 11:32: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 2FF14443B9; Thu, 22 Jun 2000 11:12:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 33A01443B5 for ; Thu, 22 Jun 2000 11:12:22 -0400 (EDT) Received: by webmail.speedventures.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 17:20:08 +0200 Message-ID: <2160ABC55998D311821900508B2C14BB269D72@webmail.speedventures.com> From: =?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?= To: "'Kevin Summers '" , =?iso-8859-1?Q?J=F6rg?= =?iso-8859-1?Q?en_Bj=F6rkner?= , "''sip@lists.bell-labs.com' '" Subject: RE: [SIP] Announcement of SIP Forum Date: Thu, 22 Jun 2000 17:20:03 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08527 Hi, yes of course you are right, it is www.sipforum.org. It should be an alias for www.sipforum.com point there, but it is appearantly not working. Thanks! /Jörgen -----Original Message----- From: Kevin Summers To: Jörgen Björkner; 'sip@lists.bell-labs.com' Sent: 2000-06-21 19:46 Subject: RE: [SIP] Announcement of SIP Forum Interesting...there is nothing at www.sipforum.com .... however, a site much like what you describe is at www.sipforum.org. -----Original Message----- From: Jörgen Björkner [mailto:Jorgen.Bjorkner@hotsip.com] Sent: Wednesday, June 21, 2000 11:55 AM To: 'sip@lists.bell-labs.com' Subject: [SIP] Announcement of SIP Forum Hi, I just wanted to invite those interested to participate in the SIP Forum work. SIP Forum was announced yesterday at the Voice on the net Europe conference to be a natural meeting place for those companies and individuals working with SIP. The forum will NOT do any technical work, all such ideas should be forwarded to the IETF, so there will be no overlap between the organizations. SIP Forum will spread information on how to utilize SIP as a tool for service creation, how to deploy SIP in real networks etc. It will also list available products making use of SIP. If you have such products available for purchase right now, please let the SIP forum webmaster know about them. The organization is an open non profit Swedish association, open to anyone that can contribute on the SIP information sharing, on a not so very technical level. More information is found at http://www.sipforum.com Welcome! Jörgen Björkner, Chairman of SIP Forum _______________________________________________ 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 Jun 22 11:36: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 LAA08600 for ; Thu, 22 Jun 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 D392C443C7; Thu, 22 Jun 2000 11:21:53 -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 7A26F443AE for ; Thu, 22 Jun 2000 11:21:50 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 22 11:33:43 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 161AF44348; Thu, 22 Jun 2000 11:20:34 -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 B9C8C44347 for ; Thu, 22 Jun 2000 11:20:33 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA01960; Thu, 22 Jun 2000 10:20:31 -0500 Cc: Gethin Liddell , "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA01944; Thu, 22 Jun 2000 10:20:28 -0500 Message-ID: <39522EB3.B4187DC8@lucent.com> Date: Thu, 22 Jun 2000 10:20:19 -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: "Jose Cherian. P." Original-CC: Gethin Liddell , "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: <00062211545801.21137@gethin> <00a701bfdc2e$28fc1a40$a164a8c0@josetel> 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 "Jose Cherian. P." wrote: > > Hi > > I am new to SIP > Is there any open SIP stack available for SIP? > > pls help > thanks in advance.. Jose: See http://www.cs.columbia.edu/sip/implementations.html for more info. - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Thu Jun 22 11:41: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 LAA08726 for ; Thu, 22 Jun 2000 11:41: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 EB293443CE; Thu, 22 Jun 2000 11:23:20 -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 5C49D443AE for ; Thu, 22 Jun 2000 11:23:17 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 22 Jun 2000 10:31:32 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 10:34:39 -0500 Message-ID: <2E532B03F035D3119AF40000F80932C32073E8@crchy28d.us.nortel.com> From: "William Lee" To: "'Fernando Orus'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Sending DTMF Date: Thu, 22 Jun 2000 10:34:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDC5F.608FF356" 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 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_01BFDC5F.608FF356 Content-Type: text/plain Fernando: Take a look at: draft-choudhuri-sip-info-digit-00.txt It discusses transporting DTMF digits mid-session using the SIP INFO method with an alternate extensible payload description. William Lee williaml@nortenetworks.com > -----Original Message----- > From: Fernando Orus [SMTP:forus@insynergy.com] > Sent: Thursday, June 22, 2000 4:21 AM > To: sip > Subject: [SIP] Sending DTMF > > Hi all, > I haven't found anything related to sending DTMFs in the documentation > I've > read about SIP. Are you expected to send DTMFs in band within the audio > stream? > Thanks in advance, > Fernando Orus > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFDC5F.608FF356 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [SIP] Sending DTMF

Fernando:

Take a look at: = draft-choudhuri-sip-info-digit-00.txt

It discusses = transporting DTMF digits mid-session using the SIP INFO method with = an
alternate = extensible payload description.

William Lee
williaml@nortenetworks.com

    -----Original Message-----
    From:   Fernando Orus [SMTP:forus@insynergy.com]
    Sent:   Thursday, June 22, 2000 4:21 AM
    To:     sip
    Subject:       = [SIP] Sending DTMF

    Hi all,
    I haven't found anything related to = sending DTMFs in the documentation I've
    read about SIP. Are you expected to = send DTMFs in band within the audio
    stream?
    Thanks in advance,
    Fernando Orus



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

------_=_NextPart_001_01BFDC5F.608FF356-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 22 12:17: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 MAA09182 for ; Thu, 22 Jun 2000 12:17: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 7437D44394; Thu, 22 Jun 2000 12:05: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 F37A044384 for ; Thu, 22 Jun 2000 12:05:00 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id MAA07869; Thu, 22 Jun 2000 12:16:54 -0400 (EDT) Message-ID: <39523BF6.7E7E648D@cisco.com> Date: Thu, 22 Jun 2000 12:16:54 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: A Srinath , sip@lists.bell-labs.com Subject: Re: [SIP] Caller receives responses References: <000701bfdc5a$e1972690$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 I am not sure if a proxy should forward a retransmitted 200 OK to a non-INVITE request. Request retransmission by the upstream ua/proxy will take care of it. The first 200 OK may have already reached the upstream guy. Jo Hornsby wrote: > > > While we are here, I would like to hear what proxy implementors think > > about receiving multiple final respones on a single branch. Is it > > reasonable to simply drop final responses received after the first > > one ?? > > If you have state, and the response is not 2xx, then maybe so. > > The reason I say this is because I would guess that if this situation > has arisen, then it's probably due to some server responding in a > very tardy fashion; if this is the case, then it's not so unlikely > that any proxies along the route have dropped transaction state, and > thus they'll be forwarded the response statelessly. > > One reason against this behaviour is that I guess you could still > be pending results on some branches when you receive a different > final response on a branch that was marked as done. This probably > would tend to indicate that a downstream server is very ill, however. > > Of course, if the response is to an INVITE, you really should ACK > if it's non-2xx class... > > > I guess, dropping 200 response is not good, but it is very > > unlikely that a 200 response is received on a branch after a non-200 > > final response. > > I don't see that it's any less likely than receiving any other > different response. > > > If the proxy decides to forward all 200 responses > > upstream, regardless of the state of the branch and transaction, the > > branch state gets kind of messy. > > How so? If the proxy still has state on the transaction, then the > branch will either be done or it won't. Forwarding 2xx class > upstream in a stateless fashion doesn't really complicate this; > you just set the boolean unconditionally. &:) > > > Also, it was suggested on this list that proxies should not drop > > final responses which do not append a tag to the To header. If a proxy > > tries to be lenient and does this, it complicates matters even more. > > I can see ambiguity arising with ACKs...is there anything else? > > - 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 Jun 22 12:37: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 MAA09698 for ; Thu, 22 Jun 2000 12:37: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 CED1B443A7; Thu, 22 Jun 2000 12:24: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 94FD54439D for ; Thu, 22 Jun 2000 12:24:30 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA18891; Thu, 22 Jun 2000 17:34:36 +0100 (BST) From: "Jo Hornsby" To: Cc: "A Srinath" , Subject: RE: [SIP] Caller receives responses Date: Thu, 22 Jun 2000 17:34:36 +0100 Message-ID: <000a01bfdc67$c0bdf540$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <39523BF6.7E7E648D@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 > I am not sure if a proxy should forward a retransmitted 200 OK to > a non-INVITE request. Request retransmission by the upstream ua/proxy > will take care of it. The first 200 OK may have already reached > the upstream guy. Interesting point -- I'd missed that. (Although I guess all it implies is that there will be some extra message transmissions.) So I guess we look to the tag to distinguish response retransmissions? But if the tag is missing... Oh dear. - 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 Jun 22 13:03: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 NAA10397 for ; Thu, 22 Jun 2000 13:03: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 ADADA443CA; Thu, 22 Jun 2000 12:39:09 -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 6C252443C5 for ; Thu, 22 Jun 2000 12:39:06 -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 MAA21591; Thu, 22 Jun 2000 12:52:35 -0400 (EDT) Message-ID: <39524453.6CEE67EF@dynamicsoft.com> Date: Thu, 22 Jun 2000 12:52:35 -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 Subject: Re: [SIP] Hold & then re-INVITE without media References: <066201bfdbee$979b73f0$3102a8c0@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: > > A -- Invite (hold media) --> B > <-- 200 (hold media) -- B > --- Ack --------------------> B > > After A requests B to hold, how can A without providing media request > that B stop holding and provide media? I'm having a bit of trouble parsing that sentence; I think you are asking how to take someone off hold? Simply send a re-INVITE with the connection address non-zero once more. > > I just wanted to verify that the following should work unless B > has also pushed the hold button. > > A -- Invite -------------------> B > <-- 200 (media) --------- B > --- Ack (media) --------> B Assuming (media) means non-zero address, yes. Note that hold is not necessarily bi-directional, if A sends an INVITE to B with a zero IP address, B won't send media to A, and is "on hold", but B is not obligated to return zero in the response. -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 Jun 22 14:21: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 OAA12253 for ; Thu, 22 Jun 2000 14:21: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 836E444375; Thu, 22 Jun 2000 14:08:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by lists.bell-labs.com (Postfix) with ESMTP id C0EC14433F for ; Thu, 22 Jun 2000 14:08:33 -0400 (EDT) Received: from ss8networks.com (gw-ss8networks.storm.ca [209.87.234.122]) by valiant.cnchost.com id OAA06417; Thu, 22 Jun 2000 14:20:46 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <3952587E.3930A139@ss8networks.com> Date: Thu, 22 Jun 2000 14:18:38 -0400 From: Dave Walker Organization: SS8 Networks Inc X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Announcement of SIP Forum References: <2160ABC55998D311821900508B2C14BB269D71@webmail.speedventures.com> <395139FD.45921C74@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 In case anyone is not aware of it, I believe that this type of certification program is currently being considered by the SIP Working Group in the Softswitch Consortium (which is *not* looking for post-H.323 work!). Dave Walker SS8 Networks Ottawa, Canada Henning Schulzrinne wrote: > > One of the ideas that was discussed at the Telia dinner in Stockholm was > whether there was a need for a basic SIP certification program. There > are obvious pluses and minuses for this, but my concern is that if this > is a real need, I can think of a few organizations (looking for > post-H.323 work...) that I would rather *not* see doing this. > -- > 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 Jun 22 14: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 OAA12566 for ; Thu, 22 Jun 2000 14:35: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 B2E1F44392; Thu, 22 Jun 2000 14:22:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by lists.bell-labs.com (Postfix) with ESMTP id 0F4BE44336 for ; Thu, 22 Jun 2000 14:22:52 -0400 (EDT) Received: from ss8networks.com (gw-ss8networks.storm.ca [209.87.234.122]) by valiant.cnchost.com id OAA15816; Thu, 22 Jun 2000 14:35:04 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <39525BD8.83A61C9E@ss8networks.com> Date: Thu, 22 Jun 2000 14:32:56 -0400 From: Dave Walker Organization: SS8 Networks Inc X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: Re: [SIP] Hold & then re-INVITE without media References: <066201bfdbee$979b73f0$3102a8c0@broadsoft.com> <39524453.6CEE67EF@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 If it were bi-directional, then how would you get to hear how wonderful company X is when someone you phoned there puts you on hold? In other words, MOH doesn't work very well with bi-directional hold. On the other hand, it'd be nice for my app to automatically switch over to my own MOH when I'm on hold. But then maybe I'd miss important information from the far end (like "there are approximately 20 people before you in the queue", or like "press pound or else I'm going to drop your call" - pound to be sent in an INFO of course). Dave Walker (who enjoys being on hold) Jonathan Rosenberg wrote: > [snip] > > Note that hold is not necessarily bi-directional, if A sends an INVITE > to B with a zero IP address, B won't send media to A, and is "on hold", > but B is not obligated to return zero in the response. > > -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 Jun 22 14:36: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 OAA12598 for ; Thu, 22 Jun 2000 14:36: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 00AEA443A0; Thu, 22 Jun 2000 14:23: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 D8D924439D for ; Thu, 22 Jun 2000 14:22: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 OAA22167; Thu, 22 Jun 2000 14:32:42 -0400 (EDT) Message-ID: <39525B55.FD8B7F11@dynamicsoft.com> Date: Thu, 22 Jun 2000 14:30:45 -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: Shail Bhatnagar Cc: Jo Hornsby , A Srinath , sip@lists.bell-labs.com Subject: Re: [SIP] Caller receives responses References: <000701bfdc5a$e1972690$4e34c3c1@ubiquity.co.uk> <39523BF6.7E7E648D@cisco.com> 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 Shail Bhatnagar wrote: > > I am not sure if a proxy should forward a retransmitted 200 OK to > a non-INVITE request. Request retransmission by the upstream ua/proxy > will take care of it. The first 200 OK may have already reached > the upstream guy. No, it should not. Responses to non-INVITEs are only retransmitted upon request retransmissions. See 10.4.1 for details. --- 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 Thu Jun 22 14:43: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 OAA12788 for ; Thu, 22 Jun 2000 14:43: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 36C94443CD; Thu, 22 Jun 2000 14:27:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by lists.bell-labs.com (Postfix) with ESMTP id B6B32443C9 for ; Thu, 22 Jun 2000 14:27:47 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA20696 for ; Thu, 22 Jun 2000 14:29:59 -0500 From: rhboivie@us.ibm.com Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id OAA43024 for ; Thu, 22 Jun 2000 14:39:56 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256906.0066876F ; Thu, 22 Jun 2000 14:39:53 -0400 X-Lotus-FromDomain: IBMUS To: sip@lists.bell-labs.com Message-ID: <85256906.00664710.00@d54mta04.raleigh.ibm.com> Date: Thu, 22 Jun 2000 14:37:57 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Announcement of Small Group Multicast (SGM) BoF Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 people on this list might be interested in the "Small Group Multicast" (SGM) BoF that will be held at the IETF in Pittsburgh. The idea here is to develop a multicast solution that can support very large numbers (eg tens of thousands or millions) of relatively small multicast groups (e.g. up to 10 or 20 or 40 members) so that we can make multicast practical for important classes of applications such as IP telephony, videoconferencing, "collaborative" applications, networked games etc. I'm including the note that went out on the IETF-announce list earlier in the week. Note that there's a mailing list you can subscribe to (instructions below) if you're interested in this. Thanks. Rick Boivie rhboivie@us.ibm.com ---------------------- Forwarded by Rick Boivie/Hawthorne/IBM on 06/22/2000 11:32 AM --------------------------- "David Oran" @cnri.reston.va.us on 06/19/2000 02:27:49 PM Sent by: scoya@cnri.reston.va.us To: IETF-Announce: ; cc: Subject: Small Group Multicast (SGM) BoF (CORRECTED) This is a corrected version of the previous announcement. Small Group Multicast (SGM) BoF ----------------------------- A number of people in the Internet community have been advocating that the IETF consider standardizing a method for handling multicast to small groups, where "small" is generally understood to be in the range of 3-10 or possibly up to 20 or so participants. The rationale for this is twofold: 1) there are alleged to be a number of very important applications which have a small numbers of participants per group (e.g. classic audio and video conferencing, collaboration tools, etc.) with an extremely large number of such groups simultaneously active on the Internet. 2) Existing IP multicast methods, including newer specialized schemes like Source Specific Multicast (SSM) are generally thought to have scaling problems when there are a very large nubmer of groups, because of per-group state in all the intermediate routers. Because of the range of possible approaches to this problem and the potential widespread impact on portions of the IP protocol suite, router implementation, operational practices, etc. of the Internet, the BoF is being jointly hosted by the Routing and Internet areas, and will be chaired by Randy Bush of the OPS area. The BoF's goals are to: a) assess interest in forming a Working Group on Small Group Multicast b) produce a crisp problem statement which could be used as the basis for a Working Group Charter c) reach consensus on a set of constraints on the solution space (see below) d) examine existing work for possible solutions (see below) In order to have a technically sound and deployable solution, it is particularly important the scope of changes to the Internet architecture, protocols, host & router implementations, and operational management be understood and hopefully minimized. Some of these possible constraints include: - Host API (e.g. sockets interface) changes allowed? - Host protocol implementation changes allowed? - IP packet header changes allowed? If so, effect on router forwarding speed? - New routing protocols needed? Modifications to existing multicast and/or unicast routing protocols? Changes to or new group membership and rendezvous protocols? - Incremental deployment possible? Impact on deployed infrastructure? Is the new capability worth the level of disruption, if any? - need to re-use existing congestion control and security mechanisms? In order to stimulate discussion in advance of the BoF, we will use an existing mailing list set up by the folks who have been working on a set of approaches to SGM which are collectively known as explicit multicast, or "xcast". The mailing list is: xcast@public.alcatel.com and may be subscribed to by via xcast-request@public.alcatel.com A detailed agenda will be provided in the next couple of weeks after initial discussion on the mailing list. An initial reading list for people interested in the discussion follows: 1) "Connectionless Multicast", draft-ooms-cl-multicast-02.txt 2) "Small Group Multicast", http://www.icair.org/main_projects_infrast_sgm.html http://www.ietf.org/internet-drafts/draft-boivie-sgm-00.txt 3) "Multiple Destination option on IPv6", draft-imai-mdo6-01.txt 4) "Distributed Core Multicast: a routing protocol for many small groups with application to mobile IP telephony" draft-blazevic-dcm-mobility-00.txt(Expired) 5) "Distributed Core Multicast(DCM): a multicast routing protocol for many groups with few receivers", In ACM SIGCOMM Computer Communication Review, October 1999, Vol.29, No.5, pp.6-21 6) "Datagram Routing for Internet Multicasting", L. Aguilar, Sigcomm84, March 1984 7) "IPv4 option for Sender Directed Multi-Destination Delivery", C. Graff, RFC1770 8) "Explicit Multicast(xcast) proposed working group" http://www.alcatel.com/xcast _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 22 14:47: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 OAA12862 for ; Thu, 22 Jun 2000 14:47: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 3DD28443C2; Thu, 22 Jun 2000 14:32: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 E61F1443AB for ; Thu, 22 Jun 2000 14:32:14 -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 OAA22285; Thu, 22 Jun 2000 14:45:52 -0400 (EDT) Message-ID: <39525EDE.F69759C9@dynamicsoft.com> Date: Thu, 22 Jun 2000 14:45:50 -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] Phone user in Buddy List ? References: <007301bfdc07$57a6e360$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 It is theoretically possible, but gateways have no useful way to determine the on-hook/off-hook status of a phone. Presuming you exposed some entity that could know this (for example if a 5e had an IP interface and would accept SUBSCRIBE), then you could do it. It would all depend on there being sufficient naming/routing information to get a SUBSCRIBE request to that 5E. I suspect that ENUM would be helpful here... -Jonathan R. > rafi wrote: > > Hi, > > > Can I have phone user in my buddy list ?. > Thus, is it possible for a gateway to act as PA? > In that case gateway may need some support from > PSTN world. > > > Thank You > Rafi Assadi H.M > Silicon Automation Systems > Bangalore, INDIA -- 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 Jun 22 16: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 QAA15436 for ; Thu, 22 Jun 2000 16:56: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 3775E44393; Thu, 22 Jun 2000 16:43:56 -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 A225844339 for ; Thu, 22 Jun 2000 16:43:52 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id QAA36813; Thu, 22 Jun 2000 16:56:01 -0400 (EDT) Message-ID: <070a01bfdc8c$b7d1b7d0$3102a8c0@broadsoft.com> From: "Brett Tate" To: "Jonathan Rosenberg" Cc: "SIPbell-labs" References: <066201bfdbee$979b73f0$3102a8c0@broadsoft.com> <39524453.6CEE67EF@dynamicsoft.com> Subject: Re: [SIP] Hold & then re-INVITE without media Date: Thu, 22 Jun 2000 16:59:11 -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 Thanks for the response. A rewording of the question is presented within the following text. ----- Original Message ----- From: Jonathan Rosenberg To: Brett Tate Cc: SIPbell-labs Sent: Thursday, June 22, 2000 12:52 PM Subject: Re: [SIP] Hold & then re-INVITE without media > > > > Brett Tate wrote: > > > > A -- Invite (hold media) --> B > > <-- 200 (hold media) -- B > > --- Ack --------------------> B > > > > After A requests B to hold, how can A without providing media request > > that B stop holding and provide media? > > I'm having a bit of trouble parsing that sentence; I think you are > asking how to take someone off hold? Simply send a re-INVITE with the > connection address non-zero once more. > > > > > I just wanted to verify that the following should work unless B > > has also pushed the hold button. > > > > A -- Invite -------------------> B > > <-- 200 (media) --------- B > > --- Ack (media) --------> B > > Assuming (media) means non-zero address, yes. I think you already answered my question, but maybe this will provide some clarity. For the following question, assume A originally sent the INVITE containing an SDP with connection address 0.0.0.0 to B; B replied with 200; A replied with an ACK. Can an INVITE without SDP indicate to B that A is no longer "holding B" and will provide the complete SDP in the ACK? A --------------- Invite (no SDP) ----------------------------> B <-- 200 (SDP with connection address not 0.0.0.0) --- --- Ack (SDP with connection address not 0.0.0.0) --> > > Note that hold is not necessarily bi-directional, if A sends an INVITE > to B with a zero IP address, B won't send media to A, and is "on hold", > but B is not obligated to return zero in the response. > > -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 Jun 22 17: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 RAA15901 for ; Thu, 22 Jun 2000 17:22: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 1A7A3443A0; Thu, 22 Jun 2000 17:09: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 B8CC944336 for ; Thu, 22 Jun 2000 17:09: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 RAA23510; Thu, 22 Jun 2000 17:19:08 -0400 (EDT) Message-ID: <395282CA.E16D3DED@dynamicsoft.com> Date: Thu, 22 Jun 2000 17:19:06 -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 List Subject: Re: [SIP] Max-Forwards + Proxies References: <394F90ED.B1A6EAEE@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 Actually, this is in RFC2543 also. I don't like this, in fact. I believe method-based special handling of headers is confusing, and I would prefer that the response always be 483, for any method. I guess the objective (for OPTIONS at least), is to query a proxy for capabilities. But, its not really clear that this means the same thing as a user agent. For REGISTER, its not likely to do anything useful, except result in the request being rejected, as it probably can't be accepted locally at some intermediate proxy. Anyone object to having this sentence stricken? -Jonathan R. Neil Deason wrote: > > According to 6.26 of the bis draft if a proxy receives a request > that has a zero value in the Max-Forwards header field it MUST > NOT forward the request. Instead, for the OPTIONS or REGISTER > methods, it MUST respond as the final recipient. For all other > methods, the server returns 483 (Too many hops). > > How exactly should a Proxy respond as the final recipient to an > OPTIONS? > > How should a proxy respond to a REGISTER if it is not responsible > for registrations within the domain named in the Request-URI? > > In the case of other methods is sensible to always return 483? > For example what if it was an INVITE and the Proxy knows from a > location service a final response would have been 3XX/404. > > 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 -- 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 Jun 22 17:29: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 RAA16028 for ; Thu, 22 Jun 2000 17:29: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 9ECD1443B4; Thu, 22 Jun 2000 17:15: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 2DC06443A6 for ; Thu, 22 Jun 2000 17:15:34 -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 RAA23584; Thu, 22 Jun 2000 17:29:15 -0400 (EDT) Message-ID: <39528528.37004AEE@dynamicsoft.com> Date: Thu, 22 Jun 2000 17:29:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ajay Chitturi Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Questions on Figure 11 of RFC2543bis References: <078292D50C98D2118D090008C7E9C6A6018A811C@STAY.platinum.corp.microsoft.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 > Ajay Chitturi wrote: > > In this diagram does "give up" mean the caller gave up and hung > up the call or that the state machine gave up ? I believe it means that the caller gives up. > > Since there is another arrow from the "Calling" state showing > "7 INVITE sent", I assume the arrow to the right of "Calling" state > happens when the user hangs up. In this case shouldn't the state > machine > wait for the response to INVITE and send an ACK ? I believe it should. This is reflected in the server state machine on the pages following. In fact, hanging up has no effect on the transaction at all (its termination should be sped up, since the far side will send a final response to the INVITE). > > The arrow to the right of "Call Proceeding" state could happen if > either > the caller hangs up or the state machine hangs up. Is the timeout for > when > the state machine will give up in this state specified in the draft or > left > to the implementation. If the user hangs up, shouldn't the state > machine > wait for the response to INVITE and send an ACK ? I don't think you can usefully distinguish between the "state machine" giving up, and the user giving up. In any case, yes, you should wait for the response and send the ACK. Of course, from a UI perspective, the call is hung up and that should be reflected; the transaction kind of hangs around (much like TCP state for closed connections) to clean up. > > Also section 4.2.4 states : > A BYE request from either called or calling party terminates any > pending INVITE, but the INVITE request transaction MUST be > completed > with a final response. > > Does this mean that the ACK also needs to be sent after getting > the response ? Once again, yes. Transactions are independent entities that should always complete by themselves. -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 Jun 22 18:02: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 SAA16535 for ; Thu, 22 Jun 2000 18:02: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 BD684443AB; Thu, 22 Jun 2000 17:50: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 4579244336 for ; Thu, 22 Jun 2000 17:50:07 -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 SAA23881; Thu, 22 Jun 2000 18:00:02 -0400 (EDT) Message-ID: <39528C60.7F0BE88D@dynamicsoft.com> Date: Thu, 22 Jun 2000 18:00:00 -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: Ajay Chitturi , sip@lists.bell-labs.com Subject: Re: [SIP] Questions on section 10.1.1 of RFC2543bis References: <000e01bfda91$07b6d940$4e34c3c1@ubiquity.co.uk> 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 Jo Hornsby wrote: > > > The following is a paragraph in section 10.1.1 of the RFC2543bis draft > > When a user agent server receives a request, it checks the Call-ID > > against those of in-progress calls. If the Call-ID was found, it > > compares the tag value of To with the user’s tag and rejects > > the request if the two do not match. If the From header, including > > any tag value, matches the value for an existing call leg, the > > server compares the CSeq header field value. If less than or equal > > to the current sequence number, the request is a retransmission. > > Otherwise, it is a new request. If the From header does not match > > an existing call leg, a new call leg is created. > > Why is just the tag value of To compared (while the whole of From > > header is compared). > > Presumably because even if UACs are generating non-unique Call-IDs, > they are far less likely to be non-unique within the callee's space > (one would hope!). No; nothing like that. I actually think the complete To field should be included in the comparison, so as to make this consistent with the definition of a call leg (which does include To). In practice it will never make a difference, since, as you point out, Call-ID are unique anyway. > > > Also could you please explain the scenario where the following > > happens: "If the From header does not match an existing call leg, a > > new call leg is created." > > I guess this vaguely confirms my first paragraph. That's a relief. &:) No, this case is to support multiparty conferences, so that someone else can join in on a call.... some more definition work is needed for this as part of the call control work. -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 Jun 22 18:08: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 SAA16582 for ; Thu, 22 Jun 2000 18:08: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 AA2AA443C0; Thu, 22 Jun 2000 17:55:51 -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 819D1443BC for ; Thu, 22 Jun 2000 17:55:48 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 22 18:07:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6516944348; Thu, 22 Jun 2000 17:53:57 -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 1608244347 for ; Thu, 22 Jun 2000 17:53:57 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA27651; Thu, 22 Jun 2000 16:53:54 -0500 Cc: Neil Deason , Sip List Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA27613; Thu, 22 Jun 2000 16:53:50 -0500 Message-ID: <39528AE5.9F6B8F0@lucent.com> Date: Thu, 22 Jun 2000 16:53:41 -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: Jonathan Rosenberg Original-CC: Neil Deason , Sip List Subject: Re: [SIP] Max-Forwards + Proxies References: <394F90ED.B1A6EAEE@ubiquity.net> <395282CA.E16D3DED@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: > > Actually, this is in RFC2543 also. > > I don't like this, in fact. I believe method-based special handling of > headers is confusing, and I would prefer that the response always be > 483, for any method. I guess the objective (for OPTIONS at least), is > to query a proxy for capabilities. ^^^^^ Is it? How does a proxy know that this OPTIONS request is destined for it, and not for proxying downstream? The RFC (and the bis updates) state that "Proxy and redirect servers simply forward the request with- out indicating their capabilities." I simply assumed that a proxy will forward the request downstream and not respond upstream with _it's_ capability set. > Anyone object to having this sentence stricken? Not me, for one. Anything stricken is good :-) - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Thu Jun 22 18:12: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 SAA16603 for ; Thu, 22 Jun 2000 18:12: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 C670D443D9; Thu, 22 Jun 2000 17:58:53 -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 ESMTP id BC4AF443CE for ; Thu, 22 Jun 2000 17:58:48 -0400 (EDT) Received: by DFSSL.dns.microsoft.com with Internet Mail Service (5.5.2652.35) id ; Thu, 22 Jun 2000 15:03:08 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A60976FC2B@STAY.platinum.corp.microsoft.com> From: Ajay Chitturi To: "'Jonathan Rosenberg'" , Jo Hornsby Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Questions on section 10.1.1 of RFC2543bis Date: Thu, 22 Jun 2000 15:04:08 -0700 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 If someone else wants to join a conference, wouldn't that be a new Call-Id ? > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > No, this case is to support multiparty conferences, so that > someone else > can join in on a call.... some more definition work is needed for this > as part of the call control work. > > -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 Jun 22 18:15: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 SAA16633 for ; Thu, 22 Jun 2000 18:15: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 649C9443DF; Thu, 22 Jun 2000 18:01:43 -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 7FD83443C9 for ; Thu, 22 Jun 2000 18: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 SAA23977; Thu, 22 Jun 2000 18:15:11 -0400 (EDT) Message-ID: <39528FED.49D46042@dynamicsoft.com> Date: Thu, 22 Jun 2000 18:15:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com, rafi@sasi.com Subject: Re: [SIP] How to ping Prxoy Server ? References: <200006201439.JAA12331@b04a45.exu.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 A UA could also cache the fact that there was a failure; next time it tries to contact that host, it can continue using the backup address. I will note that rfc2543bis does actually forbid this behavior, though: From 1.4.2: > A client MAY cache a successful DNS query result. A successful query is one which contained records > in the answer, and a server was contacted at one of the addresses from the answer. When the client wishes > to send a request to the same host, it MUST start the search as if it had just received this answer from the > name server. The client MUST follow the procedures in RFC1035 [16] regarding DNS cache invalidation > when the DNS time-to-live expires. I don't remember why we made it a MUST to start the search from scratch.... Henning? -Jonathan R. Sean Olson wrote: > > > > > Is there > > any method/way available in SIP using which status of proxy server can be known in advance ?. > > This information helps the UAC in keeping track current active list of default > > proxy server(s). > > > > The OPTIONS method provides a very crude sort of ping for SIP. > Combined with the Max-Forwards: header, you can ping various nodes along > a call signalling path. But this may still not give you the information > you desire; just because a proxy responds to an OPTIONS request, doesn't > mean it is capable of handling calls. > > > Thank You > > Rafi Assadi H.M. > > Silicon Automation Sysytems > > Bangalore, INDIA > > > > -- > Sean Olson > > _______________________________________________ > 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 Jun 22 18:22: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 SAA16682 for ; Thu, 22 Jun 2000 18:22: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 3E96E443E4; Thu, 22 Jun 2000 18:09: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 2A61944336 for ; Thu, 22 Jun 2000 18:09:03 -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 SAA24006; Thu, 22 Jun 2000 18:18:59 -0400 (EDT) Message-ID: <395290D0.C8F608E4@dynamicsoft.com> Date: Thu, 22 Jun 2000 18:18:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ajay Chitturi Cc: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] Questions on section 10.1.1 of RFC2543bis References: <078292D50C98D2118D090008C7E9C6A60976FC2B@STAY.platinum.corp.microsoft.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 the original call control specification, fully distributed multiparty conferencing used the Call-ID to identify the entire conference. For other conferencing models, like dialup conference bridges, the call-ID is not used, but rather the request URI. In any case, fully distributed multiparty conferencing is still being worked out, so this may or may not still be the case. -Jonathan R. Ajay Chitturi wrote: > > If someone else wants to join a conference, wouldn't that be a new Call-Id ? > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > No, this case is to support multiparty conferences, so that > > someone else > > can join in on a call.... some more definition work is needed for this > > as part of the call control work. > > > > -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 > > -- 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 Jun 22 18: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 SAA16728 for ; Thu, 22 Jun 2000 18: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 B417D443E7; Thu, 22 Jun 2000 18:09: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 B2D35443E6 for ; Thu, 22 Jun 2000 18:09: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 SAA24028; Thu, 22 Jun 2000 18:23:22 -0400 (EDT) Message-ID: <395291D7.7B2FA4A1@dynamicsoft.com> Date: Thu, 22 Jun 2000 18:23:19 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: dmalhotra@hss.hns.com Cc: rafi , sip@lists.bell-labs.com Subject: Re: [SIP] [SIP]: Caching of Final Response(s) References: <652568F9.00368A14.00@sandesh.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 Also note that caching these results is a SHOULD; a proxy that is beginning to run out of memory, or is under attack, can simply elect to stop caching the results to get itself out of trouble. The caching is an optimziation, after all. -Jonathan R. dmalhotra@hss.hns.com wrote: > > Hi Rafi, > In scenario 1, you are right that if multiple responses are > cached then the server > may go out of buffer space but I have a point here that all the calls do not > appear simultaneously > generally they have some pattern and even if it is not there then the > implementation can put a limit > on the number of simultaneous calls for which it will support caching. After > that it may not support the caching and > may release the call or whatever specific action it wants to take. > As far as the scenario 2 is concerned, > You have probably missed one point that server is going to keep > this info maximum upto 10*T2 seconds. > T2 being 4 seconds so worst case it is 40 seconds. > Regards > Dhiraj Malhotra > > "rafi" on 06/09/2000 12:08:53 PM > > To: sip@lists.bell-labs.com > cc: (bcc: Dhiraj Malhotra/HSS) > > Subject: [SIP] [SIP]: Caching of Final Response(s) > > Hi, > > Consider the following paragraph in RFC 2543, > section 10.4.1 > > ....... the server sends a final response, it cannot > be sure the client has received the response, and thus > SHOULD cache the results for at least 10*T2 seconds > to avoid having to, for example, contact the user or location > server again upon receiving a request retransmission. > > Now consider the following scenarios. > > Scenario 1 : Consider a UAS supporting many calls > (each call's media stream may terminate > at different IP address). If server caches the > final response then in worst case server may be > caching all the responses almost at same time. This > caching > may cause the server run out of buffer space thereby > preventing the server from serving new requests. > > Scenario 2: Consider a misbehaved client which is sending request in > such way that each time it sends a request it challenges > the > server to send final response. Client can quickly > make the server run out of buffer space and bring down > its > operation. > > Any comment are welcome. > > Thank You > > Rafi Assadi H.M. > Silicon Automation Systems > Bangalore, INDIA. > > _______________________________________________ > 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 Thu Jun 22 19:12: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 TAA17165 for ; Thu, 22 Jun 2000 19:12: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 CECD744393; Thu, 22 Jun 2000 18:59:55 -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 5C12544336 for ; Thu, 22 Jun 2000 18:59:52 -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 SAA19659; Thu, 22 Jun 2000 18:12:06 -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 SAA03870; Thu, 22 Jun 2000 18:12:05 -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 SAA08233; Thu, 22 Jun 2000 18:12:05 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id SAA19957; Thu, 22 Jun 2000 18:12:04 -0500 (CDT) Date: Thu, 22 Jun 2000 18:12:04 -0500 (CDT) Message-Id: <200006222312.SAA19957@b04a45.exu.ericsson.se> To: jdrosen@dynamicsoft.com, vkg@lucent.com Subject: Re: [SIP] Max-Forwards + Proxies Cc: ndeason@ubiquity.net, 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 X-BeenThere: sip@lists.bell-labs.com > Jonathan Rosenberg wrote: > > > > Actually, this is in RFC2543 also. > > > > I don't like this, in fact. I believe method-based special handling of > > headers is confusing, and I would prefer that the response always be > > 483, for any method. I guess the objective (for OPTIONS at least), is > > to query a proxy for capabilities. > ^^^^^ > Is it? How does a proxy know that this OPTIONS request is destined for > it, and not for proxying downstream? The RFC (and the bis updates) > state that "Proxy and redirect servers simply forward the request with- > out indicating their capabilities." I simply assumed that a proxy will > forward the request downstream and not respond upstream with _it's_ > capability set. This is the point of the Max-Forwards: header usage in connection with the OPTIONS method. > > > Anyone object to having this sentence stricken? > Not me, for one. Anything stricken is good :-) > It is nice to be able to specify that an OPTIONS/REGISTER be directed to a particular node, at least for certain diagnostic purposes. I will probably continue to support this behavior, even if it becomes "non-standard". But I wouldn't mind if no one else implements it. sean > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org > IN Architecture and Internet Software Group > 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 Fri Jun 23 01:24: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 BAA24795 for ; Fri, 23 Jun 2000 01:24: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 06A3944354; Fri, 23 Jun 2000 01:11: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 7581144336 for ; Fri, 23 Jun 2000 01:11:20 -0400 (EDT) Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA24937; Fri, 23 Jun 2000 01:25:00 -0400 (EDT) Message-ID: <3952F4AF.D670A50E@dynamicsoft.com> Date: Fri, 23 Jun 2000 01:25:03 -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 Subject: Re: [SIP] Hold & then re-INVITE without media References: <066201bfdbee$979b73f0$3102a8c0@broadsoft.com> <39524453.6CEE67EF@dynamicsoft.com> <070a01bfdc8c$b7d1b7d0$3102a8c0@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: > > I think you already answered my question, but maybe this > will provide some clarity. > > For the following question, assume A originally > sent the INVITE containing an SDP > with connection address 0.0.0.0 to B; B replied with 200; > A replied with an ACK. Can an INVITE without SDP > indicate to B that A is no longer "holding B" and will > provide the complete SDP in the ACK? > > A --------------- Invite (no SDP) ----------------------------> B > <-- 200 (SDP with connection address not 0.0.0.0) --- > --- Ack (SDP with connection address not 0.0.0.0) --> This should work. This behavior (no SDP in INVITE, but SDP in ACK) is allowed, actually. Its main use is for the first INVITE, for interop with H.323v1 amongst other things. However, if you can do something in a first INVITE, it is allowed in a re-INVITE, so there you 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 Jun 23 01:25: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 BAA25032 for ; Fri, 23 Jun 2000 01: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 423584437E; Fri, 23 Jun 2000 01:11: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 A27764436F for ; Fri, 23 Jun 2000 01:11:46 -0400 (EDT) Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA24929; Fri, 23 Jun 2000 01:21:38 -0400 (EDT) Message-ID: <3952F3E5.982D5382@dynamicsoft.com> Date: Fri, 23 Jun 2000 01:21:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: vkg@lucent.com, ndeason@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.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 Sean Olson wrote: > > It is nice to be able to specify that an OPTIONS/REGISTER be directed > to a particular node, at least for certain diagnostic purposes. I will > probably continue to support this behavior, even if it becomes > "non-standard". But I wouldn't mind if no one else implements it. I'm assuming by diagnostic you refer to the ability to tell if the proxy is alive. You can still do that with the consistent behavior I am proposing. It works exactly like traceroute; you set max-forwards to some number, and the proxy who gets it when its zero returns an error. If you get no response, you know that this particular device is down. The difference is whether the Supported, Accept, Allow headers are there. Allow and Accept don't make sense for proxies anyway. Just trying to simplify things... special cases are annoying. -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 Jun 23 01: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 BAA27738 for ; Fri, 23 Jun 2000 01: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 0906144354; Fri, 23 Jun 2000 01:36: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 B1EED44336 for ; Fri, 23 Jun 2000 01:36:24 -0400 (EDT) Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA24991; Fri, 23 Jun 2000 01:46:13 -0400 (EDT) Message-ID: <3952F9A9.FCBD0CC8@dynamicsoft.com> Date: Fri, 23 Jun 2000 01:46:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Shail Bhatnagar , Jo Hornsby , A Srinath , sip@lists.bell-labs.com Subject: Re: [SIP] Caller receives responses References: <000701bfdc5a$e1972690$4e34c3c1@ubiquity.co.uk> <39523BF6.7E7E648D@cisco.com> <39525B55.FD8B7F11@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 Igor is correct. Handling of non-INVITE is much simpler. You can (and MUST) only ever return a single response upstream. This is in contrast to INVITE where you can (and SHOULD/MUST (not sure which)) forward all 200 OKs you receive. Forwarding multiple 200 OK for non-INVITE doesn't work because of the lack of ACK; reliability of responses for non-INVITE is guaranteed by request retransmissions. So, when a request retransmission arrives, which response do you send? No way to know, and thus no way to guarantee reliability. For INVITE, each final response has its own retransmissions and its own acknowledgement with ACK. As a result, reliability for multiple 200 OK for INVITE works. Shail writes: > While we are here, I would like to hear what proxy implementors think > about receiving multiple final respones on a single branch. Is it > reasonable to simply drop final responses received after the first > one ?? I guess, dropping 200 response is not good, but it is very > unlikely that a 200 response is received on a branch after a non-200 > final response. If the proxy decides to forward all 200 responses > upstream, regardless of the state of the branch and transaction, the > branch state gets kind of messy. Here is the scenario where you could get a 200 OK after a non-200 OK response. Proxy A sends INVITE to B. B forks, and then times out, never getting any responses. So, it sends CANCEL and also sends a 408 response upstream. Now, after that CANCEL, a 200 OK arrives. Its then forwarded upstream also. Voila. A now gets a 408 followed by 200 OK. As Jo has pointed out, forwarding the additional 200 OK upstream is not hard. -Jonathan R. Igor Slepchin wrote: > > Shail Bhatnagar wrote: > > > > I am not sure if a proxy should forward a retransmitted 200 OK to > > a non-INVITE request. Request retransmission by the upstream ua/proxy > > will take care of it. The first 200 OK may have already reached > > the upstream guy. > > No, it should not. Responses to non-INVITEs are only retransmitted upon > request retransmissions. See 10.4.1 for details. > > --- > Igor Slepchin > > _______________________________________________ > 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 Jun 23 03: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 DAA05126 for ; Fri, 23 Jun 2000 03: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 F0BE74436E; Fri, 23 Jun 2000 03:36: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 2447844336 for ; Fri, 23 Jun 2000 03:36:29 -0400 (EDT) Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA25104; Fri, 23 Jun 2000 03:50:09 -0400 (EDT) Message-ID: <395316B3.DA6F3901@dynamicsoft.com> Date: Fri, 23 Jun 2000 03:50:11 -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: "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: <00062211545801.21137@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: > > However, as far as the Tel URI rfc (2806) is concerend, the character @ > (for example) will not have to be escaped. This, of course, will not be > valid in the sipurl as it is used to separate the `userinfo' and > `hostinfo' elements and will need to be escaped. > > For example, if the phone-context is actually stored as: > > "Context1@Context2" > > then the tel url will have to look like: > > tel:+12345;phone-context=%22Context1@Context2%22 > > however, it would NOT be valid to just enter this as a sip url as > follows: > > sip:+12345;phone-context=%22Context1@Context2%22@company.com;user=phone > > for the obvious problem of the @. this would need to be translated to: > > sip:+12345;phone-context=%22Context1%40Context2%22@company.com;user=phone Hmm. I wonder if the actual translation would be: sip:+12345;phone-context=%2522Context1%40Context2%2522@company.com;user=phone The difference is that here, I have treated the subscriber portion of the tel URL as an opaque entity. When placing this into the user portion of the SIP URL, I need to escape code reserved characters AND the % itself. Effectively, I re-encoded the string, so that the two % signs already there are treated as normal %, and thus escape encoded as %25. Which way to do it depends on whether you assume that the SIP entity has knowledge of the structure of the tel URL subscriber syntax, in which case it would know that this would have already had its % url-encoded, and thus there is no need to redo that encoding, or whether it is treated as a random username that happens to have some bad characters in it. I tend to think the right answer is probably what Gethin has suggested. In either case we should clarify this 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 Fri Jun 23 04:06: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 EAA05261 for ; Fri, 23 Jun 2000 04:06: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 AFD9A44381; Fri, 23 Jun 2000 03:53: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 2DD5644336 for ; Fri, 23 Jun 2000 03:53:38 -0400 (EDT) Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA25122; Fri, 23 Jun 2000 03:58:19 -0400 (EDT) Message-ID: <3953189E.4125273D@dynamicsoft.com> Date: Fri, 23 Jun 2000 03:58:22 -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: "Fairlie-Cuninghame, Robert" , "Adam B. Roach" , Henning Schulzrinne , Billy Biggs , Colin Perkins , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <394E7F61.BA727458@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 So, in the interests of coming to consensus, let me propose that: 1. inline content MAY be included, possibly using multipart. This would obviously include MIME types like application/URI-list which are themselves indirect references 2. we define a new header, called URI or something, which contains indirect references to content that is to be displayed. The header is totally optional to process at UAS. It cannot be used for content that is critical for processing the request properly. We also RECOMMEND that proxies use the URI header when inserting content. A UA inserting content can use either, but indirect references are RECOMMENDED for content over 500 bytes (or some other number). In this way, if a UAC sends content inline using multipart, and the UAS doesn't support it, the 415 response will indicate that multipart isn't supported. The UAC can then resubmit the request using the URI header. This keeps things open and flexible, but makes concrete recommendations to guide implementors (i.e, supporting the URI header would be your first choice). -Jonathan R. Henning Schulzrinne wrote: > > The problem with having proxies add body parts is (a) complexity, (b) > that now all clients have to understand multipart, even if they have no > interest in the information (I would guess that most current SIP clients > don't understand multipart) and (c) that it doesn't work with signed > requests. Headers containing a reference (http:, say) avoid these > problems. The only drawback is that such references require http support > in clients (which may be an issue for a very light-weight clients, but > most of these are probably graphically challenged anyway) and requires > that the information is available on a publically accessible web page. I > suspect that most corporate users would have difficult uploading their > likeness or other images to a web page, and not everyone wants to have > their likeness framed by an advertisement from geocity or kin. These > are, more or less, the arguments that were made the last time this topic > came around, I believe. -- 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 Jun 23 04:11: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 EAA05341 for ; Fri, 23 Jun 2000 04:11: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 4C00344393; Fri, 23 Jun 2000 03:58: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 3973C44388 for ; Fri, 23 Jun 2000 03:58:19 -0400 (EDT) Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA25137; Fri, 23 Jun 2000 04:11:11 -0400 (EDT) Message-ID: <39531BA2.8DE38F94@dynamicsoft.com> Date: Fri, 23 Jun 2000 04:11:14 -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: ozsip@oz.com, sip@lists.bell-labs.com Subject: Re: [SIP] proxy protocol conversion References: <000301bfdb5d$0f558e90$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: > > > Let's assume we have two users, which both have clients which > > only support UDP. They have different home proxies, and those > > proxies are stateful, use TCP when possible and always insist on > > being included throughout any call going through them. > > > > Thus we have this setup with transport: > > > > Client A ------- UDP -------- Proxy A --------- TCP --------- Proxy B > > -------- UDP -------- Client B > > > > User A calls user B, and a call is successfully set up. Both proxy > > A and proxy B have include Record-Route headers in any proxied > > requests. > > > > Now let us assume that the code implementing the underlying session > > being established has a critical bug, and that when client A and B > > act on the agreed session description, they both crash violently. > > How will the proxies in-between ever discover that? After the ACK > > is sent by client A, the proxies never hear from the clients again! > > > > How is this handled? > > I'm not massively confident that I'm understanding where there's > a problem; is it because you are concerned that the TCP connection > might persist unnecessarily indefinitely? Else I can't see where > the "proxy protocol conversion" comes in? I guess the solution > that jumps out at me is to have some sort of timer on a TCP connection, > which causes it to be closed if there's been no activity for some > period of time. Persistence of TCP connections is totally independent of determination of whether the UAC and UAS are still in the session set up with the INVITE. Session timer is used exclusively for the latter; how long to keep a TCP connection open for is a matter of policy. However, I have a draft pending shortly which discusses some issues with TCP connection management. -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 Jun 23 04:14: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 EAA05357 for ; Fri, 23 Jun 2000 04:14: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 016E0443AA; Fri, 23 Jun 2000 03:59:49 -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 8EA134439F for ; Fri, 23 Jun 2000 03:59:45 -0400 (EDT) Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA25142; Fri, 23 Jun 2000 04:12:53 -0400 (EDT) Message-ID: <39531C07.8EFC10E6@dynamicsoft.com> Date: Fri, 23 Jun 2000 04: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: Shail Bhatnagar Cc: vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Statful proxy: Receiving Requests References: <394F931C.B631C92C@lucent.com> <394F997E.CE8CA9B3@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 Yes, Shail is correct. -Jonathan R. Shail Bhatnagar wrote: > > Vijay, I think it includes tags, since a brand new re-INVITE or BYE > may have a tag in the To header. > > "Vijay K. Gurbani" wrote: > > > > Folks: > > > > In the June 9th bis draft, Section 12.3.4 (Stateful Proxy: Receiving > > Requests) states: > > > > When a stateful proxy receives a request, it checks the To, > > From (including tags), Call-ID and CSeq against existing > > request records. > > > > I presume the To check does NOT include tags. Can someone corroborate > > this, please. > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org > > IN Architecture and Internet Software Group > > 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 > > _______________________________________________ > 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 Jun 23 04: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 EAA05402 for ; Fri, 23 Jun 2000 04:20: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 71160443A2; Fri, 23 Jun 2000 04:07:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.barak.net.il (mail.barak.net.il [206.49.94.213]) by lists.bell-labs.com (Postfix) with ESMTP id 5429444336 for ; Fri, 23 Jun 2000 04:07:15 -0400 (EDT) Received: from ntagranov ([212.150.198.2]) by mail.barak.net.il (8.9.3/8.9.1) with SMTP id LAA02459; Fri, 23 Jun 2000 11:19:29 +0300 (IDT) From: "Alexander Agranov" To: Cc: Date: Fri, 23 Jun 2000 11:21:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" 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.2314.1300 Subject: [SIP] H323 Fast Connect to SIP interworking Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 Session 5.2.1 in draft-singh-sip-h323-01, that describes interworking of H323 Fast Connect with SIP says that there is "one-to-one mapping between H.323 and SIP call establishment messages". Nevertheless let's have a look at the scenario when H.323 Fast Start message contains set of more than one alternative channels: H.323 terminal GW SIP UA 128.59.21.152 128.59.19.194 | | | | SETUP | | |---------------------------->| | | destination:hgs@cs.columbia.edu | | fastStart={g711Ulaw,Tx}, | | | {{g711Ulaw,Rx,128.59.21.152:10000}, | | {g711Alaw,Rx,128.59.21.152:10000}} | | | | | | INVITE | | |===========================>| | | To:hgs@cs.columbia.edu | | | c=IN IP4 128.59.21.152 | | | m=audio 10000 RTP/AVP 0 8 | | | | | | 200 OK | | |<===========================| | | c=IN IP4 128.59.19.194 | | | m=audio 8000 RTP/AVP 0 8 | ???????? In this case (according to 8.1.1) IWF should generate INVITE SIP request with SDP that contains multiple payloads. Now it's my understanding of RFC2543 that SIP UA may respond to such INVITE with "200 OK" that also contains SDP with multiple payloads. But we can't acknowledge both FastConnect alternative channels, can we? So GW will need to acknowledge only one of the channels and issue reINVITE to SIP UA (like in H323v1), right? This situation is applicable even when FastConnect contains only one channel, since RFC2543 states that "200 OK" message's "list of codecs may or may not be a subset of" INVITE message codecs. Please correct me if I'm wrong. Best regards, Alex Agranov --- ComGates Ltd. Tel: +972 (9) 9500-404, Ext: 228 Mobile: +972 (54) 928435 Fax: +972 (9) 9500-385 E-mail: sagranov@comgates.co.il _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 04:31: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 EAA05516 for ; Fri, 23 Jun 2000 04: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 747C2443B9; Fri, 23 Jun 2000 04:18:21 -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 88AE14434A for ; Fri, 23 Jun 2000 04:18:14 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA10651; Fri, 23 Jun 2000 09:28:13 +0100 (BST) Message-ID: <39531F9E.7F64A4DB@ubiquity.net> Date: Fri, 23 Jun 2000 09:28:14 +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: vkg@lucent.com Cc: Jonathan Rosenberg , Sip List Subject: Re: [SIP] Max-Forwards + Proxies References: <394F90ED.B1A6EAEE@ubiquity.net> <395282CA.E16D3DED@dynamicsoft.com> <39528AE5.9F6B8F0@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 "Vijay K. Gurbani" wrote: > > Jonathan Rosenberg wrote: > > > > Actually, this is in RFC2543 also. > > > > I don't like this, in fact. I believe method-based special handling of > > headers is confusing, and I would prefer that the response always be > > 483, for any method. I guess the objective (for OPTIONS at least), is > > to query a proxy for capabilities. > ^^^^^ > Is it? How does a proxy know that this OPTIONS request is destined for > it, and not for proxying downstream? Because the case we were discussing is where the Max-Forwards header field of the OPTIONS request contains a zero. > The RFC (and the bis updates) > state that "Proxy and redirect servers simply forward the request with- > out indicating their capabilities." I simply assumed that a proxy will > forward the request downstream and not respond upstream with _it's_ > capability set. Yes, this is the normal behaviour when Max-Forwards doesn't come in to play. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > > Anyone object to having this sentence stricken? > > Not me, for one. Anything stricken is good :-) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 04: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 EAA05556 for ; Fri, 23 Jun 2000 04: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 2B16D44390; Fri, 23 Jun 2000 04:25: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 9500B4433D for ; Fri, 23 Jun 2000 04:24:58 -0400 (EDT) Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA25181; Fri, 23 Jun 2000 04:38:43 -0400 (EDT) Message-ID: <39532216.21464233@dynamicsoft.com> Date: Fri, 23 Jun 2000 04:38:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip , sigtran@standards.nortelnetworks.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP and SCTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, I've just submitted a draft on using SCTP for SIP transport. It defines how to do it (its very easy) and some of the benefits. Its mostly to encourage implementation experience and experimentation; my own belief is that much experimentation is needed before we can make concrete statements about its applicability to SIP. Comments welcome, of course, particularly from the SCTP experts. Until it appears in the archives, you can grab a copy from: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-sctp-00.txt 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 Fri Jun 23 04:52: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 EAA05641 for ; Fri, 23 Jun 2000 04:52: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 8EE2B44386; Fri, 23 Jun 2000 04:39: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 918B044336 for ; Fri, 23 Jun 2000 04:38:58 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA16743; Fri, 23 Jun 2000 09:48:24 +0100 (BST) Message-ID: <39532457.C5EF0266@ubiquity.net> Date: Fri, 23 Jun 2000 09:48:23 +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: Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@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: > > Sean Olson wrote: > > > > It is nice to be able to specify that an OPTIONS/REGISTER be directed > > to a particular node, at least for certain diagnostic purposes. I will > > probably continue to support this behavior, even if it becomes > > "non-standard". But I wouldn't mind if no one else implements it. > > I'm assuming by diagnostic you refer to the ability to tell if the proxy > is alive. You can still do that with the consistent behavior I am > proposing. It works exactly like traceroute; you set max-forwards to > some number, and the proxy who gets it when its zero returns an error. > If you get no response, you know that this particular device is down. > The difference is whether the Supported, Accept, Allow headers are > there. Allow and Accept don't make sense for proxies anyway. Also the Supported header which might be useful SHOULD be included in the response according to 6.40. > Just trying to simplify things... special cases are annoying. I agree that simplification would be good in this area. There doesn't seem to be any loss in saying that the standard response from a proxy/gateway recipient to any request containing Max-Forwards: 0 is 483. 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 Fri Jun 23 05:48: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 FAA05941 for ; Fri, 23 Jun 2000 05:48: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 A7AAD44363; Fri, 23 Jun 2000 05:35:41 -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 8991244336 for ; Fri, 23 Jun 2000 05:35:37 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA05819; Fri, 23 Jun 2000 10:45:35 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , "Igor Slepchin" Cc: "Shail Bhatnagar" , "A Srinath" , Subject: RE: [SIP] Caller receives responses Date: Fri, 23 Jun 2000 10:45:34 +0100 Message-ID: <000d01bfdcf7$c6f4fb80$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <3952F9A9.FCBD0CC8@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 > Igor is correct. Handling of non-INVITE is much simpler. You can (and > MUST) only ever return a single response upstream. Is this explicitly documented anywhere -- have I missed it? The only forking documentation I'm aware of is 12.4, and that's specific to INVITEs. If you fork REGISTERs (I'm not sure why you'd do this -- perhaps towards some sort of redundancy?), are there any potential problems with only returning one 200? The only other request I can possibly see problems with (because you might get a response from a UA that ultimately you wouldn't have been interested in) is OPTIONS. (Of course, unknown methods are forwarded like OPTIONS.) This has actually raised another point. Upon re-reading of 12.4, I note that 6xx MUST be forwarded if a 2xx has not been seen. Is this true regardless of whether-or-not a different 6xx has already be forwarded? - 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 Jun 23 06:06: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 GAA06040 for ; Fri, 23 Jun 2000 06:06: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 BB5C44436F; Fri, 23 Jun 2000 05:53:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 2384144336 for ; Fri, 23 Jun 2000 05:53:55 -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.10.1/8.10.1/WIREfire-1.9) with ESMTP id e5NA6Cs03024 for ; Fri, 23 Jun 2000 12:06:13 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Fri, 23 Jun 2000 12:06:11 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 23 Jun 2000 10:06:11 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Fri, 23 Jun 2000 12:06:09 +0200 Message-ID: <9CC6CC2973F2D211B3580008C70DB2D2017589C4@eatvint903> From: "Catalin Gheorghiu (ETR)" To: sip@lists.bell-labs.com Date: Fri, 23 Jun 2000 12:06:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 23 Jun 2000 10:06:11.0380 (UTC) FILETIME=[A855E740:01BFDCFA] Subject: [SIP] Coco/R-MGCP/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, My name is Catalin and I work for ERICSSON Romania. Now I am working to implement a parser for the MGCP protocol (and later for the SIP protocol). I am using the Coco/R parser for this, but I am actually a beginner in doing this kind of things. The Coco/R is a nice tool, but sometimes I need to ask questions, to get some hints. Is anyone having experience in using the Coco/R parser for MGCP/SIP protocols ? Thank you. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 06:07: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 GAA06051 for ; Fri, 23 Jun 2000 06:07: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 8960B4439A; Fri, 23 Jun 2000 05:55:01 -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 CA3D544394 for ; Fri, 23 Jun 2000 05:54:57 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA12544; Fri, 23 Jun 2000 11:05:22 +0100 (BST) Message-ID: <39533662.AEAED0C8@ubiquity.net> Date: Fri, 23 Jun 2000 11:05:22 +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: Dave Walker Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Announcement of SIP Forum References: <2160ABC55998D311821900508B2C14BB269D71@webmail.speedventures.com> <395139FD.45921C74@cs.columbia.edu> <3952587E.3930A139@ss8networks.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 Dave Walker wrote: > > In case anyone is not aware of it, I believe that this type > of certification program is currently being considered by the > SIP Working Group in the Softswitch Consortium (which is *not* > looking for post-H.323 work!). Personally I wouldn't be in favour of this consortium, or any other membership charging forum, seeking such a role. The problems of such groups having influence over protocols has been demonstrated by the recent criticisms of the WAP Forum. Let's keep the focus for SIP within the truly open environment of the IETF. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > Henning Schulzrinne wrote: > > > > One of the ideas that was discussed at the Telia dinner in Stockholm was > > whether there was a need for a basic SIP certification program. There > > are obvious pluses and minuses for this, but my concern is that if this > > is a real need, I can think of a few organizations (looking for > > post-H.323 work...) that I would rather *not* see doing this. > > -- > > 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 Jun 23 08:00: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 IAA07633 for ; Fri, 23 Jun 2000 08:00: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 3D5B844389; Fri, 23 Jun 2000 07:47:45 -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 AAFBF44336 for ; Fri, 23 Jun 2000 07:47:42 -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 22E011E002 for ; Fri, 23 Jun 2000 07:59:58 -0400 (EDT) Received: from alliance.research.att.com (localhost [127.0.0.1]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id HAA01748; Fri, 23 Jun 2000 07:59:57 -0400 (EDT) Message-Id: <200006231159.HAA01748@alliance.research.att.com> To: sip@lists.bell-labs.com Cc: gopal@research.att.com In-reply-to: Your message of "Thu, 22 Jun 2000 17:58:51 EDT." <20000622215851.8946A443D5@lists.bell-labs.com> Date: Fri, 23 Jun 2000 07:59:57 -0400 From: Gopal Subject: [SIP] > 12. Re: Questions on section 10.1.1 of RFC2543bis (Jonathan Rosenberg) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Return-Path: > Delivered-To: sip@lists.bell-labs.com > Message-ID: <39528C60.7F0BE88D@dynamicsoft.com> > Date: Thu, 22 Jun 2000 18:00:00 -0400 > From: Jonathan Rosenberg > Organization: dynamicsoft > MIME-Version: 1.0 > To: Jo Hornsby > Cc: Ajay Chitturi , > sip@lists.bell-labs.com > Subject: Re: [SIP] Questions on section 10.1.1 of RFC2543bis > References: <000e01bfda91$07b6d940$4e34c3c1@ubiquity.co.uk> > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > > > > Jo Hornsby wrote: > > > > > The following is a paragraph in section 10.1.1 of the RFC2543bis draft > > > When a user agent server receives a request, it checks the Call-ID > > > against those of in-progress calls. If the Call-ID was found, it > > > compares the tag value of To with the users tag and rejects > > > the request if the two do not match. If the From header, including --- snipped 4 lines ---- > > > Why is just the tag value of To compared (while the whole of From > > > header is compared). > No; nothing like that. I actually think the complete To field should be > included in the comparison, so as to make this consistent with the > definition of a call leg (which does include To). In practice it will There is another potential problem though with comparing tag value of To. Consider the foll. scenario when a UAC talks directly to a UAS (no proxy) UAC UAS INVITE (no tag value for To)----------->Generate new Tag value for To (lost)X <------ 100 Trying (MAY include tag in To) (lost)X <------ 180 Ringing (MAY include tag in To) (timeout. Retransmit INVITE) INVITE ((no tag value for To)---------->Rejected since Tag value of To does not match 10.1.1 of RFC2543bis I think (wrongfully) suggests the above behavior. Ideally, re-transmission of the INVITE should trigger the 180 response from the UAS. I think the tag value of To should be compared only if the To field in the incoming message has a tag. Sec. 6.23 actually states that tag values of 2 URIs are compared only if both URIs have tags. How about changing the sentence to "If the Call-ID was found, it compares the tag value of To (if present) with the users tag and rejects the request if the two do not match." -gopal _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 08:38: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 IAA08507 for ; Fri, 23 Jun 2000 08:38: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 D3A0B44392; Fri, 23 Jun 2000 08:26:24 -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 B87C844336 for ; Fri, 23 Jun 2000 08:26:20 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA28853; Fri, 23 Jun 2000 13:36:48 +0100 (BST) Message-ID: <39535A2F.C9CC6AF9@ubiquity.net> Date: Fri, 23 Jun 2000 13:38:07 +0100 From: Phil Hoffer Organization: Ubiquity Software Corporation 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] PGP Authentication Scheme - REPOST Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, Section 15.1.1 of the rfc2543bis draft is missing information, and a BNF entry with respect to pgp-pubalgolrithm. Presumably, pgp-pubalgolrithm should be included in the BNF for pgp-params in section 15.1.1 Also some text about the parameter is required, e.g. what is the default value of pgp-pubalgolrithm if it is omitted from WWW-Authenticate header. Is it assumed to be RSA? Hope that helps Regards -- Phil Hoffer Ubiquity Software Corporation Software Developer Ubiquity House Tel: +44 (0) 1633-765600 Langstone Park Fax: +44 (0) 1633-765601 Newport NP18 2LH URL: http://www.ubiquity.net mailto:phoffer@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 Jun 23 08:57: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 IAA08842 for ; Fri, 23 Jun 2000 08:57: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 AC8C7443A6; Fri, 23 Jun 2000 08:45:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by lists.bell-labs.com (Postfix) with ESMTP id 148BA44336 for ; Fri, 23 Jun 2000 08:45:08 -0400 (EDT) Received: from ss8networks.com (gw-ss8networks.storm.ca [209.87.234.122]) by devonshire.cnchost.com id IAA05284; Fri, 23 Jun 2000 08:57:21 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <39535E29.CC7CCFD6@ss8networks.com> Date: Fri, 23 Jun 2000 08:55:05 -0400 From: Dave Walker Organization: SS8 Networks Inc X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Announcement of SIP Forum References: <2160ABC55998D311821900508B2C14BB269D71@webmail.speedventures.com> <395139FD.45921C74@cs.columbia.edu> <3952587E.3930A139@ss8networks.com> <39533662.AEAED0C8@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 Well, I don't know about the WAP Forum, but I would think that a certification program should certainly be open to non-members if it's run by a forum that charges for membership. I'd be surprised if a certification program could be run without costs that have to be covered somehow (volunteer organizations aren't too reliable in the long term). And remember, the reason people will want such a certification for their products is to make money. And it takes money to make money. (or it used to!) I also note that SIP Forum indicates that it will be charging a fee to organizations (didn't see how much), and while it's free to individuals, it is typically organizations that have more of a motivation for acquiring certification. Regards, Dave Walker SS8 Networks Ottawa, Canada Neil Deason wrote: > > Dave Walker wrote: > > > > In case anyone is not aware of it, I believe that this type > > of certification program is currently being considered by the > > SIP Working Group in the Softswitch Consortium (which is *not* > > looking for post-H.323 work!). > > Personally I wouldn't be in favour of this > consortium, or any other membership charging > forum, seeking such a role. The problems of > such groups having influence over protocols > has been demonstrated by the recent criticisms > of the WAP Forum. Let's keep the focus for SIP > within the truly open environment of the IETF. > > 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 Fri Jun 23 09:37: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 JAA09980 for ; Fri, 23 Jun 2000 09: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 38C1A443A9; Fri, 23 Jun 2000 09:25:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.pulver.com (unknown [192.246.69.133]) by lists.bell-labs.com (Postfix) with ESMTP id 7677344336 for ; Fri, 23 Jun 2000 09:25:11 -0400 (EDT) Received: from cs.columbia.edu (slip-32-102-64-216.ca.us.prserv.net [32.102.64.216]) by mail.pulver.com (8.9.2/8.9.2) with ESMTP id JAA29659; Fri, 23 Jun 2000 09:36:44 -0400 (EDT) Message-ID: <3953690F.A1160ABC@cs.columbia.edu> Date: Fri, 23 Jun 2000 09:41:35 -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: "Fairlie-Cuninghame, Robert" , "Adam B. Roach" , Henning Schulzrinne , Billy Biggs , Colin Perkins , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <394E7F61.BA727458@cs.columbia.edu> <3953189E.4125273D@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 This sounds find (I'll incorporate it), but I do wonder if one wouldn't want to be more specific in the purpose of the header, rather than just "URI". For the 'visual caller id', something like '*-Info' (with a suitable value of *, TBD) seems more evocative. I don't want to follow the INFO tradition of dumping everything into one header. This may be relevant, for example, as to whether the UA uses this information to update some kind of address book. Jonathan Rosenberg wrote: > > So, in the interests of coming to consensus, let me propose that: > > 1. inline content MAY be included, possibly using multipart. This would > obviously include MIME types like application/URI-list which are > themselves indirect references > 2. we define a new header, called URI or something, which contains > indirect references to content that is to be displayed. The header is > totally optional to process at UAS. It cannot be used for content that > is critical for processing the request properly. > > We also RECOMMEND that proxies use the URI header when inserting > content. A UA inserting content can use either, but indirect references > are RECOMMENDED for content over 500 bytes (or some other number). In > this way, if a UAC sends content inline using multipart, and the UAS > doesn't support it, the 415 response will indicate that multipart isn't > supported. The UAC can then resubmit the request using the URI header. > > This keeps things open and flexible, but makes concrete recommendations > to guide implementors (i.e, supporting the URI header would be your > first choice). > > -Jonathan R. > > Henning Schulzrinne wrote: > > > > The problem with having proxies add body parts is (a) complexity, (b) > > that now all clients have to understand multipart, even if they have no > > interest in the information (I would guess that most current SIP clients > > don't understand multipart) and (c) that it doesn't work with signed > > requests. Headers containing a reference (http:, say) avoid these > > problems. The only drawback is that such references require http support > > in clients (which may be an issue for a very light-weight clients, but > > most of these are probably graphically challenged anyway) and requires > > that the information is available on a publically accessible web page. I > > suspect that most corporate users would have difficult uploading their > > likeness or other images to a web page, and not everyone wants to have > > their likeness framed by an advertisement from geocity or kin. These > > are, more or less, the arguments that were made the last time this topic > > came around, I believe. > > -- > 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 Jun 23 10:15: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 KAA11257 for ; Fri, 23 Jun 2000 10:15: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 376FE443B1; Fri, 23 Jun 2000 10: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 DA7BF44336 for ; Fri, 23 Jun 2000 10:02: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 KAA26222; Fri, 23 Jun 2000 10:15:30 -0400 (EDT) Message-ID: <39537106.877D1CAA@dynamicsoft.com> Date: Fri, 23 Jun 2000 10:15:34 -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: Igor Slepchin , Shail Bhatnagar , A Srinath , sip@lists.bell-labs.com Subject: Re: [SIP] Caller receives responses References: <000d01bfdcf7$c6f4fb80$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: > > > Igor is correct. Handling of non-INVITE is much simpler. You can (and > > MUST) only ever return a single response upstream. > > Is this explicitly documented anywhere -- have I missed it? The > only forking documentation I'm aware of is 12.4, and that's specific > to INVITEs. Hmmm; I somehow thought the code handled this case as well, but perhaps not. The behavior is more or less identical, excepting you forward only one 200 OK response upstream if more than one come. > > If you fork REGISTERs (I'm not sure why you'd do this -- perhaps > towards some sort of redundancy?), are there any potential > problems with only returning one 200? If all registrars receiving the REGISTER are identical (in the sense that they maintain a shared database of registrations), receiving only one 200 OK is just fine, and the right thing. If they were different, it would anyway be confusing... if the responses contained different Contacts, which ones are actually in place in which servers? > This has actually raised another point. Upon re-reading of 12.4, > I note that 6xx MUST be forwarded if a 2xx has not been seen. Is > this true regardless of whether-or-not a different 6xx has already > be forwarded? No; you forward a single 600 only. -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 Jun 23 10:26: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 KAA11412 for ; Fri, 23 Jun 2000 10:26: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 5C418443B5; Fri, 23 Jun 2000 10:13:20 -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 D82F844336 for ; Fri, 23 Jun 2000 10:13:16 -0400 (EDT) Received: from cisalpino.cs.columbia.edu (cisalpino.cs.columbia.edu [128.59.19.194]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA17178; Fri, 23 Jun 2000 10:25:33 -0400 (EDT) Received: from localhost (kns10@localhost) by cisalpino.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA06776; Fri, 23 Jun 2000 10:25:33 -0400 (EDT) Date: Fri, 23 Jun 2000 10:25:33 -0400 (EDT) From: Kundan Singh To: sip-h323@eGroups.com Cc: sip@lists.bell-labs.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Re: [sip-h323] H323 Fast Connect to SIP interworking Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 method is to send the updated SDP in ACK to SIP UA. After receiving the 200 OK from SIP UA, the IWF recalculates the capability sets and operating modes in both directions and sends ACK to SIP UA. IWF may send a reINVITE to SIP UA to inform about the updated modes, instead of changing the session description in ACK. As far as call establishment is concerned, there can be a one-to-one mapping between SIP and H.323 messages with fast connect (in simple case). Regards Kundan > Session 5.2.1 in draft-singh-sip-h323-01, that describes interworking > of H323 Fast Connect with SIP says that there is "one-to-one mapping > between H.323 and SIP call establishment messages". > > Nevertheless let's have a look at the scenario when H.323 Fast Start > message contains set of more than one alternative channels: > > H.323 terminal GW SIP UA > 128.59.21.152 128.59.19.194 > | | | > | SETUP | | > |---------------------------->| | > | destination:hgs@cs.columbia.edu | > | fastStart={g711Ulaw,Tx}, | | > | {{g711Ulaw,Rx,128.59.21.152:10000}, | > | {g711Alaw,Rx,128.59.21.152:10000}} | > | | | > | | INVITE | > | |===========================>| > | | To:hgs@cs.columbia.edu | > | | c=IN IP4 128.59.21.152 | > | | m=audio 10000 RTP/AVP 0 8 | > | | | > | | 200 OK | > | |<===========================| > | | c=IN IP4 128.59.19.194 | > | | m=audio 8000 RTP/AVP 0 8 | > ???????? > > In this case (according to 8.1.1) IWF should generate INVITE > SIP request with SDP that contains multiple payloads. > > Now it's my understanding of RFC2543 that SIP UA may respond > to such INVITE with "200 OK" that also contains SDP with > multiple payloads. > > But we can't acknowledge both FastConnect alternative channels, > can we? > > So GW will need to acknowledge only one of the channels and > issue reINVITE to SIP UA (like in H323v1), right? > > This situation is applicable even when FastConnect contains > only one channel, since RFC2543 states that "200 OK" message's > "list of codecs may or may not be a subset of" INVITE message > codecs. > > Please correct me if I'm wrong. > > Best regards, > Alex Agranov > --- > ComGates Ltd. > Tel: +972 (9) 9500-404, Ext: 228 > Mobile: +972 (54) 928435 > Fax: +972 (9) 9500-385 > E-mail: sagranov@comgates.co.il > > > > > ------------------------------------------------------------------------ > Act NOW before June 30 to win $5,000! > Start grading businesses in your area to win. > http://click.egroups.com/1/5524/7/_/302437/_/961748376/ > ------------------------------------------------------------------------ > > To Post a message, send it to: sip-h323@eGroups.com > > To Unsubscribe, send a blank message to: sip-h323-unsubscribe@eGroups.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 Jun 23 10:46: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 KAA12077 for ; Fri, 23 Jun 2000 10: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 287C5443BC; Fri, 23 Jun 2000 10:33:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.pulver.com (unknown [192.246.69.133]) by lists.bell-labs.com (Postfix) with ESMTP id 677AE44336 for ; Fri, 23 Jun 2000 10:33:11 -0400 (EDT) Received: from cs.columbia.edu (slip-32-102-64-216.ca.us.prserv.net [32.102.64.216]) by mail.pulver.com (8.9.2/8.9.2) with ESMTP id KAA29863; Fri, 23 Jun 2000 10:45:06 -0400 (EDT) Message-ID: <395379ED.2D08FCEC@cs.columbia.edu> Date: Fri, 23 Jun 2000 10:53:33 -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: Sean Olson , sip@lists.bell-labs.com, rafi@sasi.com Subject: Re: [SIP] How to ping Prxoy Server ? References: <200006201439.JAA12331@b04a45.exu.ericsson.se> <39528FED.49D46042@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 The paragraph you quote refers to caching *DNS* query results, not whether the host was contacted or not. The idea here is just to make sure that SRV load balancing is observed. I don't think the text says anything about caching addresses, but it does have the potential drawback of bypassing load balancing. Since caching is likely only to be useful for large servers with lots of traffic, this could be a problem. You don't want AOL to always go to the same Earthlink server. Jonathan Rosenberg wrote: > > A UA could also cache the fact that there was a failure; next time it > tries to contact that host, it can continue using the backup address. I > will note that rfc2543bis does actually forbid this behavior, though: > > >From 1.4.2: > > > A client MAY cache a successful DNS query result. A successful query is one which contained records > > in the answer, and a server was contacted at one of the addresses from the answer. When the client wishes > > to send a request to the same host, it MUST start the search as if it had just received this answer from the > > name server. The client MUST follow the procedures in RFC1035 [16] regarding DNS cache invalidation > > when the DNS time-to-live expires. > > I don't remember why we made it a MUST to start the search from > scratch.... Henning? > > -Jonathan R. > > Sean Olson wrote: > > > > > > > > > Is there > > > any method/way available in SIP using which status of proxy server can be known in advance ?. > > > This information helps the UAC in keeping track current active list of default > > > proxy server(s). > > > > > > > The OPTIONS method provides a very crude sort of ping for SIP. > > Combined with the Max-Forwards: header, you can ping various nodes along > > a call signalling path. But this may still not give you the information > > you desire; just because a proxy responds to an OPTIONS request, doesn't > > mean it is capable of handling calls. > > > > > Thank You > > > Rafi Assadi H.M. > > > Silicon Automation Sysytems > > > Bangalore, INDIA > > > > > > > -- > > Sean Olson > > > > _______________________________________________ > > 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 Jun 23 10:52: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 KAA12160 for ; Fri, 23 Jun 2000 10:52: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 1E6E4443C7; Fri, 23 Jun 2000 10:39:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id E7405443B4 for ; Fri, 23 Jun 2000 10:39:45 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id UAA17246 for ; Fri, 23 Jun 2000 20:20:41 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 23 Jun 2000 20:20:39 +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 UAA25185 for ; Fri, 23 Jun 2000 20:20:37 +0530 (IST) Message-ID: <02f601bfdd22$470faf20$8c40000a@sasi.com> From: "rafi" To: Date: Fri, 23 Jun 2000 20:19:47 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F3_01BFDD50.609EB840" 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] Is SIP Transperent in this case ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_02F3_01BFDD50.609EB840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Consider a call setup involving PSTN-IP-PSTN network. How much (SIP is used in IP network -:) ) transparent SIP can be in this case ?.If features like calling party presentation restriction are desired then how=20 can SIP handle/carry these kind of information? =20 Thank You Rafi Assadi H.M. Silicon Automation Systems, Bangalore ------=_NextPart_000_02F3_01BFDD50.609EB840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
 
   Consider a call setup = involving=20 PSTN-IP-PSTN  network.
How much (SIP is used in IP=20 network -:) )
transparent SIP can be in this case = ?.If features=20 like
calling party presentation  = restriction =20 are desired then how
can SIP handle/carry these  kind = of =20 information?
 
 
  
Thank You
Rafi Assadi H.M.
Silicon Automation Systems, = Bangalore
 
 
 
------=_NextPart_000_02F3_01BFDD50.609EB840-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 10:54: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 KAA12178 for ; Fri, 23 Jun 2000 10: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 72D59443D2; Fri, 23 Jun 2000 10:41:44 -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 4B4AB443C3 for ; Fri, 23 Jun 2000 10:41:40 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA25439; Fri, 23 Jun 2000 10:53:30 -0400 (EDT) Message-ID: <395379EA.1D187EED@cisco.com> Date: Fri, 23 Jun 2000 10:53:30 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Jonathan Rosenberg , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@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: > I agree that simplification would be good in this area. There > doesn't seem to be any loss in saying that the standard response > from a proxy/gateway recipient to any request containing > Max-Forwards: 0 is 483. I think we still need 2 special cases here * A REGISTER destined for a proxy may have a Max-Forwards of 0 (registrar/proxy should still process it ) * A CANCEL for an existing call leg is allowed to have Max-Forwards value of 0 Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 11: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 LAA12456 for ; Fri, 23 Jun 2000 11: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 A9FE6443B4; Fri, 23 Jun 2000 10:55:52 -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 8DF3844336 for ; Fri, 23 Jun 2000 10:55:49 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 23 11:06:38 EDT 2000 Received: by lists.bell-labs.com (Postfix) id F256B44348; Fri, 23 Jun 2000 10:53:29 -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 A617C44347 for ; Fri, 23 Jun 2000 10:53:28 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA18755; Fri, 23 Jun 2000 09:53:25 -0500 Cc: jdrosen@dynamicsoft.com, ndeason@ubiquity.net, sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA18736; Fri, 23 Jun 2000 09:53:20 -0500 Message-ID: <395379D7.FE7851A6@lucent.com> Date: Fri, 23 Jun 2000 09:53:11 -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: Sean Olson Original-CC: jdrosen@dynamicsoft.com, ndeason@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.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 Sean Olson wrote: ^^^^^ > > Is it? How does a proxy know that this OPTIONS request is destined > > for it, and not for proxying downstream? The RFC (and the bis > > updates) state that "Proxy and redirect servers simply forward the > > request without indicating their capabilities." I simply assumed > > that a proxy will forward the request downstream and not respond > > upstream with _it's_ capability set. > > This is the point of the Max-Forwards: header usage in connection with > the OPTIONS method. Oh, okay. Kind of like the traceroute command with the TTL being 1 greater then the previous packet. I agree with Jonathan's belief that method-based special handling of headers is confusing. I had to re-read the Max-Forwards section of the RFC before it sunk in that the semantics the authors wanted to impose if (Max-Forwards == 0 && Request == OPTIONS) was to have the current proxy respond with _it's_ capabilities. > It is nice to be able to specify that an OPTIONS/REGISTER be directed > to a particular node, at least for certain diagnostic purposes. I will > probably continue to support this behavior, even if it becomes > "non-standard". But I wouldn't mind if no one else implements it. I'm not sure if there is a better way to achieve this. I don't think having a new request header will help in any way. - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Fri Jun 23 11:20: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 LAA12692 for ; Fri, 23 Jun 2000 11:20: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 9665A443C2; Fri, 23 Jun 2000 11:07:55 -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 2CC9A443B9 for ; Fri, 23 Jun 2000 11:07:52 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05002 for ; Fri, 23 Jun 2000 09:20:09 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA16833 for ; Fri, 23 Jun 2000 08:20:07 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA10413 for ; Fri, 23 Jun 2000 08:20:06 -0700 (PDT) Message-Id: <200006231520.IAA10413@nasnfs.eng.sun.com> Date: Fri, 23 Jun 2000 08:23:50 -0700 (PDT) From: James Kempf Reply-To: James Kempf To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lu3PM3btfnpWvQ+qgXhKnA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Subject: [SIP] Feature Processing 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 Can anybody point me at a draft that discusses call feature processing in SIP? In particular, I'm interested in anything that separates feature processing from initial connection management. Thanx. 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 Jun 23 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 LAA13083 for ; Fri, 23 Jun 2000 11:36: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 EEB90443CA; Fri, 23 Jun 2000 11:23: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 7B8D344336 for ; Fri, 23 Jun 2000 11:23: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 LAA27108; Fri, 23 Jun 2000 11:37:25 -0400 (EDT) Message-ID: <39538438.4959CFBB@dynamicsoft.com> Date: Fri, 23 Jun 2000 11:37:28 -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] Is SIP Transperent in this case ? References: <02f601bfdd22$470faf20$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 Not everything converts to SIP header equivalents; however, SIP-T allows you to tunnel everything that doesn;t convery, resulting in complete transparency. See: http://www.softarmor.com/sipwg/teams/sipt/index.html -Jonathan R. > rafi wrote: > > Hi, > > > Consider a call setup involving PSTN-IP-PSTN network. > How much (SIP is used in IP network -:) ) > transparent SIP can be in this case ?.If features like > calling party presentation restriction are desired then how > can SIP handle/carry these kind of information? > > > > Thank You > Rafi Assadi H.M. > Silicon Automation Systems, Bangalore > > > -- 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 Jun 23 11:37: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 LAA13133 for ; Fri, 23 Jun 2000 11:37: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 C1BA4443E0; Fri, 23 Jun 2000 11:24: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 E232F443DC for ; Fri, 23 Jun 2000 11:24: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 LAA27133; Fri, 23 Jun 2000 11:38:31 -0400 (EDT) Message-ID: <3953847A.27A61A4B@dynamicsoft.com> Date: Fri, 23 Jun 2000 11:38:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@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 Shail Bhatnagar wrote: > > Neil Deason wrote: > > > I agree that simplification would be good in this area. There > > doesn't seem to be any loss in saying that the standard response > > from a proxy/gateway recipient to any request containing > > Max-Forwards: 0 is 483. > > I think we still need 2 special cases here > * A REGISTER destined for a proxy may have a Max-Forwards of 0 > (registrar/proxy should still process it ) Why? I really don't like method specific processing of Max-Forwards; I think this will introduce oddball effects, where the topology of the proxies may effect whether registrations can placed in a server or not. > * A CANCEL for an existing call leg is allowed to have Max-Forwards > value of 0 Also, why? -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 Jun 23 11: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 LAA13188 for ; Fri, 23 Jun 2000 11:42: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 B14B3443E7; Fri, 23 Jun 2000 11:29:56 -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 B0737443E5 for ; Fri, 23 Jun 2000 11:29:42 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 23 11:41:13 EDT 2000 Received: by lists.bell-labs.com (Postfix) id AE34B44348; Fri, 23 Jun 2000 11:28:03 -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 679F344347 for ; Fri, 23 Jun 2000 11:28:03 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA04241; Fri, 23 Jun 2000 10:28:01 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA04223; Fri, 23 Jun 2000 10:27:59 -0500 Message-ID: <395381F6.D90C226C@lucent.com> Date: Fri, 23 Jun 2000 10:27:50 -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: rafi Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Is SIP Transperent in this case ? References: <02f601bfdd22$470faf20$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 a call setup involving PSTN-IP-PSTN network. > How much (SIP is used in IP network -:) ) > transparent SIP can be in this case ?.If features like > calling party presentation restriction are desired then how > can SIP handle/carry these kind of information? Rafi: Some thoughts on using SIP for PSTN-like service delivery are outlined in the following I-Ds: Title: Accessing IN services from SIP networks URL: http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip-to-in-02.txt Title: SIP enabled IN Services - an implementation report URL: http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip-to-in-02.txt Title: Frameworks and Requirements for Internet Intelligent Networks (IIN) URL: http://search.ietf.org/internet-drafts/draft-lslutsman-sip-iin-framework-00.txt - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Fri Jun 23 11:46: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 LAA13269 for ; Fri, 23 Jun 2000 11:46: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 D7AD3443F1; Fri, 23 Jun 2000 11:31:12 -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 92584443EE for ; Fri, 23 Jun 2000 11:31:09 -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 LAA27226; Fri, 23 Jun 2000 11:44:31 -0400 (EDT) Message-ID: <395385E2.6E62851B@dynamicsoft.com> Date: Fri, 23 Jun 2000 11:44:34 -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: Sean Olson , sip@lists.bell-labs.com, rafi@sasi.com Subject: Re: [SIP] How to ping Prxoy Server ? References: <200006201439.JAA12331@b04a45.exu.ericsson.se> <39528FED.49D46042@dynamicsoft.com> <395379ED.2D08FCEC@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: > > The paragraph you quote refers to caching *DNS* query results, not > whether the host was contacted or not. The quote indirectly says you shouldn't cache whether the host was contacted or not; it says you should start the search afresh when contacting the same host. To me, this means you are not allowed to remember that you previously reached the host at address X. The idea here is just to make > sure that SRV load balancing is observed. I don't think the text says > anything about caching addresses, but it does have the potential > drawback of bypassing load balancing. Since caching is likely only to be > useful for large servers with lots of traffic, this could be a problem. > You don't want AOL to always go to the same Earthlink server. The cache would need to honor DNS TTLs, as the paragraph says, so it would eventually time out. Not caching means you may increase call setup times waiting to fail against servers you have been failing against for the last hour... -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 Jun 23 11:50: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 LAA13438 for ; Fri, 23 Jun 2000 11:50: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 7E90E443FC; Fri, 23 Jun 2000 11:33: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 D57D1443F7 for ; Fri, 23 Jun 2000 11:33:34 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA07271; Fri, 23 Jun 2000 16:43:04 +0100 (BST) Message-ID: <39538587.D673E2B0@ubiquity.net> Date: Fri, 23 Jun 2000 16:43:03 +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: Jonathan Rosenberg Cc: Shail Bhatnagar , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@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: > > Shail Bhatnagar wrote: > > > > Neil Deason wrote: > > > > > I agree that simplification would be good in this area. There > > > doesn't seem to be any loss in saying that the standard response > > > from a proxy/gateway recipient to any request containing > > > Max-Forwards: 0 is 483. > > > > I think we still need 2 special cases here > > * A REGISTER destined for a proxy may have a Max-Forwards of 0 > > (registrar/proxy should still process it ) > > Why? I really don't like method specific processing of Max-Forwards; I > think this will introduce oddball effects, where the topology of the > proxies may effect whether registrations can placed in a server or not. I agree. If you make an exception for REGISTER though why not INVITE? If a proxy receives an INVITE and it knows from it's location service that the response would be a 3XX redirect then why not return this. > > * A CANCEL for an existing call leg is allowed to have Max-Forwards > > value of 0 > > Also, why? Yeah, this seems like allowing an unnecessarily odd way of doing a CANCEL. For me the simplicity of 483 for all methods, which allows the apparent fault diagnosis of the Max-Forwards tracing, still wins out. 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 Fri Jun 23 11:52: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 LAA13500 for ; Fri, 23 Jun 2000 11:52: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 8545C443E5; Fri, 23 Jun 2000 11:39:14 -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 040C744336 for ; Fri, 23 Jun 2000 11:39:11 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA05602; Fri, 23 Jun 2000 11:51:18 -0400 (EDT) Message-ID: <39538776.E603ABAF@cisco.com> Date: Fri, 23 Jun 2000 11:51:18 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@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 I don't have a problem with this simplification - but the spec says an incoming request with Max-Forwards of 0 MUST NOT be forwarded. It does not say that the request cannot be locally processed and a response returned. Since REGISTER (for the registrar) and CANCEL will be absorbed by the proxy, I thought it is okay to process these requests. The relevant statement in the spec should be appropriately changed - request MUST NOT be forward and MUST NOT be processed. Thanks, Shail Jonathan Rosenberg wrote: > > Shail Bhatnagar wrote: > > > > Neil Deason wrote: > > > > > I agree that simplification would be good in this area. There > > > doesn't seem to be any loss in saying that the standard response > > > from a proxy/gateway recipient to any request containing > > > Max-Forwards: 0 is 483. > > > > I think we still need 2 special cases here > > * A REGISTER destined for a proxy may have a Max-Forwards of 0 > > (registrar/proxy should still process it ) > > Why? I really don't like method specific processing of Max-Forwards; I > think this will introduce oddball effects, where the topology of the > proxies may effect whether registrations can placed in a server or not. > > > * A CANCEL for an existing call leg is allowed to have Max-Forwards > > value of 0 > > Also, why? > > -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 Fri Jun 23 12:06: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 MAA13853 for ; Fri, 23 Jun 2000 12:06: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 7EFE0443C7; Fri, 23 Jun 2000 11:53:46 -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 80FDF44336 for ; Fri, 23 Jun 2000 11:53:42 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA21305; Fri, 23 Jun 2000 11:06:02 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA22278; Fri, 23 Jun 2000 11:06:02 -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 LAA07091; Fri, 23 Jun 2000 11:06:01 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id LAA21678; Fri, 23 Jun 2000 11:06:01 -0500 (CDT) Date: Fri, 23 Jun 2000 11:06:01 -0500 (CDT) Message-Id: <200006231606.LAA21678@b04a45.exu.ericsson.se> To: jhornsby@ubiquity.net Subject: RE: [SIP] Caller receives responses Cc: 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 X-BeenThere: sip@lists.bell-labs.com > > If you fork REGISTERs (I'm not sure why you'd do this -- perhaps > towards some sort of redundancy?), are there any potential > problems with only returning one 200? The only other request > I can possibly see problems with (because you might get a response > from a UA that ultimately you wouldn't have been interested in) > is OPTIONS. (Of course, unknown methods are forwarded like > OPTIONS.) I can think of a couple of good applications for forking REGISTER and other non-INVITE requests where you definitely DO care about receiving ALL of the 200 class responses. If a UA already has to deal with multiple 2xx response for an INVITE, is it really so different to do this for non-INVITE requests as well? sean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 12:12: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 MAA13999 for ; Fri, 23 Jun 2000 12:12: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 6F46A443DA; Fri, 23 Jun 2000 11:59:55 -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 CCE98443CA for ; Fri, 23 Jun 2000 11:59:51 -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 LAA24162; Fri, 23 Jun 2000 11:12:11 -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 LAA16373; Fri, 23 Jun 2000 11:12:11 -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 LAA07398; Fri, 23 Jun 2000 11:12:10 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id LAA21685; Fri, 23 Jun 2000 11:12:10 -0500 (CDT) Date: Fri, 23 Jun 2000 11:12:10 -0500 (CDT) Message-Id: <200006231612.LAA21685@b04a45.exu.ericsson.se> To: ndeason@ubiquity.net, drwalker@ss8networks.com Subject: Re: [SIP] Announcement of SIP Forum Cc: 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 X-BeenThere: sip@lists.bell-labs.com Dave Walker wrote: > Well, I don't know about the WAP Forum, but I would think that > a certification program should certainly be open to non-members > if it's run by a forum that charges for membership. I'd be > surprised if a certification program could be run without > costs that have to be covered somehow (volunteer organizations > aren't too reliable in the long term). Oops. I think you have a typo in there. There a number of volunteer organizations in the OpenSource community that have been very reliable, even in the long term. I do agree, however, that it is reasonable for an organization to charge a reasonable fee for certification (provided that don't make a business out of it) > And remember, the reason > people will want such a certification for their products is to > make money. And it takes money to make money. (or it used to!) > Many of the best implementations of IETF protocols were not done for profit and were done with little or no commercial support. Is there a reason for discouraging research or non-profit implementations? > I also note that SIP Forum indicates that it will be charging > a fee to organizations (didn't see how much), and while it's > free to individuals, it is typically organizations that have > more of a motivation for acquiring certification. > True. my two cents sean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 13:00: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 NAA15182 for ; Fri, 23 Jun 2000 13:00: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 C852E4436F; Fri, 23 Jun 2000 12:47:38 -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 9E1BA44336 for ; Fri, 23 Jun 2000 12:47:34 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA29554; Fri, 23 Jun 2000 17:56:48 +0100 (BST) Message-ID: <395396D0.8915C308@ubiquity.net> Date: Fri, 23 Jun 2000 17:56:48 +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: Sean Olson Cc: drwalker@ss8networks.com, sip@lists.bell-labs.com Subject: Re: [SIP] Announcement of SIP Forum References: <200006231612.LAA21685@b04a45.exu.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 Sean Olson wrote: > > Dave Walker wrote: > > Well, I don't know about the WAP Forum, but I would think that > > a certification program should certainly be open to non-members > > if it's run by a forum that charges for membership. I'd be > > surprised if a certification program could be run without > > costs that have to be covered somehow (volunteer organizations > > aren't too reliable in the long term). > > Oops. I think you have a typo in there. There a number of volunteer > organizations in the OpenSource community that have been very > reliable, even in the long term. Indeed - the IETF is made up of volunteers. > I do agree, however, that it is > reasonable for an organization to charge a reasonable fee for > certification (provided that don't make a business out of it) Yes, this wasn't my major concern. That is that any closed organisation (a membership oriented group is by definition closed to non-members, be it because they can't afford the fees or even the governing body reserves the right to deny membership to them) might be able to decide what is certified as being the standard for an open protocol, such as SIP. 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 Fri Jun 23 13:07: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 NAA15411 for ; Fri, 23 Jun 2000 13:07: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 A9ED544393; Fri, 23 Jun 2000 12:55: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 49B2F44336 for ; Fri, 23 Jun 2000 12:55: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 MAA12298; Fri, 23 Jun 2000 12:09:26 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jun 2000 12:04:00 -0500 Message-ID: From: "Culpepper, Bert" To: rafi , sip@lists.bell-labs.com Subject: RE: [SIP] Is SIP Transperent in this case ? Date: Fri, 23 Jun 2000 12:03: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 Using SIP in the network architecture you describe requires some "extensions" to the protocol. There is a solution to the situation in your example though. That is to use the SIP INFO method to carry ISUP messages. See http://www.ietf.org/internet-drafts/draft-ietf-sip-info-method-03.txt and http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-02.txt. Regards, Bert > -----Original Message----- > From: rafi [mailto:rafi@sasi.com] > Sent: Friday, June 23, 2000 10:50 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Is SIP Transperent in this case ? > > > Hi, > > > Consider a call setup involving PSTN-IP-PSTN network. > How much (SIP is used in IP network -:) ) > transparent SIP can be in this case ?.If features like > calling party presentation restriction are desired then how > can SIP handle/carry these kind of information? > > > > Thank You > Rafi Assadi H.M. > Silicon Automation Systems, Bangalore > > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 15:33: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 PAA18089 for ; Fri, 23 Jun 2000 15:33: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 C88B044383; Fri, 23 Jun 2000 15:20: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 CE00E44336 for ; Fri, 23 Jun 2000 15:20: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 PAA29053; Fri, 23 Jun 2000 15:30:43 -0400 (EDT) Message-ID: <3953BAE5.B603A78@dynamicsoft.com> Date: Fri, 23 Jun 2000 15:30:45 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: jhornsby@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] Caller receives responses References: <200006231606.LAA21678@b04a45.exu.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 Sean Olson wrote: > > > > > If you fork REGISTERs (I'm not sure why you'd do this -- perhaps > > towards some sort of redundancy?), are there any potential > > problems with only returning one 200? The only other request > > I can possibly see problems with (because you might get a response > > from a UA that ultimately you wouldn't have been interested in) > > is OPTIONS. (Of course, unknown methods are forwarded like > > OPTIONS.) > > I can think of a couple of good applications for forking REGISTER and other > non-INVITE requests where you definitely DO care about receiving > ALL of the 200 class responses. If a UA already has to deal with > multiple 2xx response for an INVITE, is it really so different > to do this for non-INVITE requests as well? Yes, because it is impossible. Multiple 200 OK for INVITE only works because you can ACK each one individually. With non-INVITE, the only way to retrigger a response retransmission is a request retransmission. But, request retransmissions are not for a specific response; thus, it would be impossible to reliably transmit multiple 200 OK to non-INVITE. I do not believe there is really a need for multiple 200 OK for non-INVITE, in any 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 Fri Jun 23 15:39: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 PAA18170 for ; Fri, 23 Jun 2000 15:39: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 0B1F5443C3; Fri, 23 Jun 2000 15:26: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 5AB17443A7 for ; Fri, 23 Jun 2000 15:26:37 -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 PAA29123; Fri, 23 Jun 2000 15:35:32 -0400 (EDT) Message-ID: <3953BC06.59B9275E@dynamicsoft.com> Date: Fri, 23 Jun 2000 15:35:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@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 Shail Bhatnagar wrote: > > I don't have a problem with this simplification - but the spec says > an incoming request with Max-Forwards of 0 MUST NOT be forwarded. > It does not say that the request cannot be locally processed and a > response returned. Since REGISTER (for the registrar) and CANCEL > will be absorbed by the proxy, I thought it is okay to process these > requests. > The relevant statement in the spec should be appropriately changed - > > request MUST NOT be forward and MUST NOT be processed. That is the proposal; as I said, I think it is very confusing otherwise. -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 Jun 23 15:46: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 PAA18287 for ; Fri, 23 Jun 2000 15:46: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 ACF16443DE; Fri, 23 Jun 2000 15:33:32 -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 D73AA443A7 for ; Fri, 23 Jun 2000 15:33:28 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA14778; Fri, 23 Jun 2000 15:42:16 -0400 (EDT) Message-ID: <3953BD98.8545FFB9@cisco.com> Date: Fri, 23 Jun 2000 15:42:16 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@cisco.com> <3953BC06.59B9275E@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: > > Shail Bhatnagar wrote: > > > > I don't have a problem with this simplification - but the spec says > > an incoming request with Max-Forwards of 0 MUST NOT be forwarded. > > It does not say that the request cannot be locally processed and a > > response returned. Since REGISTER (for the registrar) and CANCEL > > will be absorbed by the proxy, I thought it is okay to process these > > requests. > > The relevant statement in the spec should be appropriately changed - > > > > request MUST NOT be forward and MUST NOT be processed. > > That is the proposal; as I said, I think it is very confusing >otherwise. I thought behavior of registrars/redirect servers closely matches user agents, in terms of request handling. Of course there are differences. Per this proposal, a user agent will process a request with Max-Forwards of 0 but registrars/redirect servers and proxies will not. Is my understanding correct ?? Thanks, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 16: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 QAA18605 for ; Fri, 23 Jun 2000 16: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 18CFD443A7; Fri, 23 Jun 2000 15:55: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 1836D44336 for ; Fri, 23 Jun 2000 15:55: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.9.3/8.9.3/o) with ESMTP id XAA29531 for ; Fri, 23 Jun 2000 23:07:16 +0300 (EETDST) From: Poornima.Lalwaney@nokia.com Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id XAA11789 for ; Fri, 23 Jun 2000 23:07:15 +0300 (EETDST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jun 2000 15:07:14 -0500 Message-ID: To: sip@lists.bell-labs.com Date: Fri, 23 Jun 2000 15:07:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Distributing call state : draft-dcsgroup-sip-state-01.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 The draft draft-dcsgroup-sip-state-01.txt was presented in Adelaide. In brief, the draft discusses the "State" header extension that may be used to transfer call state from the proxy to the UAC. The proxy can then be stateless for the duration of the call. The state is stored at the UAC/endpoint for the duration of the call and passed back to the proxy if mid-call changes are required. The draft also includes rules at endpoints and proxies on inclusion and processing of State headers. Comments and suggestions on the State header extension as presented in draft-01 are welcome. (this is available at http://search.ietf.org/internet-drafts/draft-dcsgroup-sip-state-01.txt ). I am in the process of updating the draft and submitting it as draft-dcsgroup-sip-state-02.txt before the Pittsburgh IETF. The dcsgroup has cleared the RFC2026 issues and the updated draft will reflect that and comments received on this list on the proposed State header extension and associated rules. Thanks and regards, Poornima Lalwaney ------------------------------------------------ Poornima Lalwaney Nokia poornima.lalwaney@nokia.com Tel: +1 858-831-4727 ----------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 23 21:09: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 VAA23942 for ; Fri, 23 Jun 2000 21:09: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 AC91F443DC; Fri, 23 Jun 2000 20:56:24 -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 EDB9244336 for ; Fri, 23 Jun 2000 20:56:20 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 18:09:14 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Static Images Date: Fri, 23 Jun 2000 18:09:10 -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 Perhaps an accompanying *-Disposition or *-Type or *-Function header to describe the purpose of *-Info would be helpful. This stops a UA trying to display something that was not supposed to be. Actually, IMO, this goal would perhaps be better served by incorporating the function/type/disposition information into the actual *-Info field. This would make the provisioning of multiple *-Info headers much simpler. Display-Info (simple but can be misleading), Optional-Info, Optional-Content, Fluff-Info? :) Robert. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, June 23, 2000 9:42 PM To: Jonathan Rosenberg Cc: Fairlie-Cuninghame, Robert; Adam B. Roach; Henning Schulzrinne; Billy Biggs; Colin Perkins; sip@lists.bell-labs.com Subject: Re: [SIP] Static Images This sounds find (I'll incorporate it), but I do wonder if one wouldn't want to be more specific in the purpose of the header, rather than just "URI". For the 'visual caller id', something like '*-Info' (with a suitable value of *, TBD) seems more evocative. I don't want to follow the INFO tradition of dumping everything into one header. This may be relevant, for example, as to whether the UA uses this information to update some kind of address book. Jonathan Rosenberg wrote: > > So, in the interests of coming to consensus, let me propose that: > > 1. inline content MAY be included, possibly using multipart. This would > obviously include MIME types like application/URI-list which are > themselves indirect references > 2. we define a new header, called URI or something, which contains > indirect references to content that is to be displayed. The header is > totally optional to process at UAS. It cannot be used for content that > is critical for processing the request properly. > > We also RECOMMEND that proxies use the URI header when inserting > content. A UA inserting content can use either, but indirect references > are RECOMMENDED for content over 500 bytes (or some other number). In > this way, if a UAC sends content inline using multipart, and the UAS > doesn't support it, the 415 response will indicate that multipart isn't > supported. The UAC can then resubmit the request using the URI header. > > This keeps things open and flexible, but makes concrete recommendations > to guide implementors (i.e, supporting the URI header would be your > first choice). > > -Jonathan R. > > Henning Schulzrinne wrote: > > > > The problem with having proxies add body parts is (a) complexity, (b) > > that now all clients have to understand multipart, even if they have no > > interest in the information (I would guess that most current SIP clients > > don't understand multipart) and (c) that it doesn't work with signed > > requests. Headers containing a reference (http:, say) avoid these > > problems. The only drawback is that such references require http support > > in clients (which may be an issue for a very light-weight clients, but > > most of these are probably graphically challenged anyway) and requires > > that the information is available on a publically accessible web page. I > > suspect that most corporate users would have difficult uploading their > > likeness or other images to a web page, and not everyone wants to have > > their likeness framed by an advertisement from geocity or kin. These > > are, more or less, the arguments that were made the last time this topic > > came around, I believe. > > -- > 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 Jun 24 04:23: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 EAA10778 for ; Sat, 24 Jun 2000 04:23: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 885BA44358; Sat, 24 Jun 2000 04:10:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6AF284433E for ; Sat, 24 Jun 2000 04:10:41 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id NAA01279 for ; Sat, 24 Jun 2000 13:51:44 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Sat, 24 Jun 2000 13:51:43 +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 NAA01121 for ; Sat, 24 Jun 2000 13:51:43 +0530 (IST) Message-ID: <009501bfddb5$166378a0$8c40000a@sasi.com> From: "rafi" To: Date: Sat, 24 Jun 2000 13:50:42 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01BFDDE3.2FF0FB20" 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] How Expire field works in this case ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_0092_01BFDDE3.2FF0FB20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Consider a call set up between UAC and=20 UAS passing through 'n' number of proxies. When UAC generated INVITE message it used Expire field with time 't'. All the intermediate proxies upon receiving INVITE message decided to use time 't' in order to limit their=20 search. When INVITE finally arrives at UAS (assuming user is presently unavailable), it decides to wait for time duration 't'. Now, before timer of duration 't' really expires at UAS, timer at = proxy (first proxy=20 in the call setup) expires first resulting in call being released. = Thus call=20 MAY be released much earlier than call waiting time promised at = UAS.=20 Thus, how should UAS use time 't' present in INVITE request when=20 user is currently not available?. Second question is how does UA handles the=20 case of INVITE crossing each other for a given pair of user ?. Is this decision is left to user of SIP stack ? Thank You Rafi Assadi H.M. Silicon Automation Systems Bangalore, INDIA ------=_NextPart_000_0092_01BFDDE3.2FF0FB20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
          &nbs= p;     =20 Consider a call set up between  UAC and
     UAS  = passing through=20 'n' number of proxies. When
    UAC  generated = INVITE=20 message it used   Expire
    field with = time  't'. =20 All the intermediate proxies  = upon=20 receiving
    INVITE message=20 decided  to use time 't' in = order to limit=20 their
    search. = When  INVITE finally arrives=20 at UAS (assuming user is
   presently = unavailable),   it=20 decides to wait for time duration 't'.
    Now, before = timer of duration 't' really expires  at UAS, timer at = proxy (first proxy=20
    in the call setup)=20 expires first=20 resulting in call being released. Thus call 
    MAY be=20 released  much earlier = than call waiting time promised at = UAS. 
   =20 Thus, how  should  UAS use = time 't'=20 present in INVITE request when =
    user is  currently not available?.
 
 
       = Second=20 question is how does UA handles the
case of INVITE crossing each other for = a given pair=20 of
user ?.  Is this decision is left = to user of=20 SIP stack ?
 
 
Thank You
Rafi Assadi H.M.
Silicon Automation Systems
Bangalore,  INDIA
 
 
------=_NextPart_000_0092_01BFDDE3.2FF0FB20-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jun 24 13:05: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 NAA14071 for ; Sat, 24 Jun 2000 13:05: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 2482944349; Sat, 24 Jun 2000 12:51:31 -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 A7CAC44336 for ; Sat, 24 Jun 2000 12:51:27 -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 NAA24933; Sat, 24 Jun 2000 13:03:43 -0400 (EDT) Message-ID: <3954EA2D.345273FB@cs.columbia.edu> Date: Sat, 24 Jun 2000 13:04:45 -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: rafi Cc: sip@lists.bell-labs.com Subject: Re: [SIP] How Expire field works in this case ? References: <009501bfddb5$166378a0$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 a call set up between UAC and > UAS passing through 'n' number of proxies. When > UAC generated INVITE message it used Expire > field with time 't'. All the intermediate proxies upon > receiving > INVITE message decided to use time 't' in order to limit their > search. When INVITE finally arrives at UAS (assuming user is > presently unavailable), it decides to wait for time duration 't'. > Now, before timer of duration 't' really expires at UAS, timer at > proxy (first proxy > in the call setup) expires first resulting in call being released. > Thus call > MAY be released much earlier than call waiting time promised at > UAS. > Thus, how should UAS use time 't' present in INVITE request when > user is currently not available?. > The timer is not suitable for microsecond timing. If forwarding your call takes more than a second, something is seriously broken (and your call throughput is going to be pretty low). Thus, the window where the call gets terminated by the first proxy rather than the UAS is going to be measured in units of milliseconds. In addition, even if the first proxy cancels the call, the total search time is still the expiration time, so this is correct behavior. The phone will stop ringing either way. (This can happen in any event if a proxy has a shorter pre-configured patience than the UAS.) > > Second question is how does UA handles the > case of INVITE crossing each other for a given pair of > user ?. Is this decision is left to user of SIP stack ? This question has been discussed several times on the list, at great length. Please take a look at the archives. > > > Thank You > Rafi Assadi H.M. > Silicon Automation Systems > Bangalore, INDIA > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jun 24 15: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 PAA14622 for ; Sat, 24 Jun 2000 15: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 5475444357; Sat, 24 Jun 2000 14:48:51 -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 D4E7444336 for ; Sat, 24 Jun 2000 14:48:47 -0400 (EDT) Received: from yahoo.com (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 PAA12362; Sat, 24 Jun 2000 15:01:09 -0400 (EDT) Message-ID: <3953EC8F.B1D82C66@cs.columbia.edu> Date: Fri, 23 Jun 2000 19:02: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: James Kempf Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Feature Processing Draft? References: <200006231520.IAA10413@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 Can you explain what you mean by "feature processing"? That's not really a SIP term... James Kempf wrote: > > Can anybody point me at a draft that discusses call feature processing in SIP? > In particular, I'm interested in anything that separates feature > processing from initial connection management. Thanx. > > jak > > _______________________________________________ > 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 Jun 24 15:02: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 PAA14642 for ; Sat, 24 Jun 2000 15:02: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 8895C4439A; Sat, 24 Jun 2000 14:49:12 -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 B335644397 for ; Sat, 24 Jun 2000 14:49:06 -0400 (EDT) Received: from yahoo.com (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 PAA12511; Sat, 24 Jun 2000 15:01:27 -0400 (EDT) Message-ID: <3953F599.AB76E952@cs.columbia.edu> Date: Fri, 23 Jun 2000 19:41:13 -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: Sean Olson , sip@lists.bell-labs.com, rafi@sasi.com Subject: Re: [SIP] How to ping Prxoy Server ? References: <200006201439.JAA12331@b04a45.exu.ericsson.se> <39528FED.49D46042@dynamicsoft.com> <395379ED.2D08FCEC@cs.columbia.edu> <395385E2.6E62851B@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 > > The quote indirectly says you shouldn't cache whether the host was > contacted or not; it says you should start the search afresh when > contacting the same host. To me, this means you are not allowed to > remember that you previously reached the host at address X. I have no (serious) problem with caching results of failed requests, but the paragraph cited is simply silent on this issue. It is not clear to me whether this implementation decision needs to be specified, since the "bad server" avoidance policy can be as complex as "if this is a first-priority server, retry with exponential back-off every 5, 10, 20 seconds; if it is a lower-priority server, retry with some other delay". I don't think that the DNS time-out is necessarily the optimal choice, since validity of name translations and likely downtime durations are not inherently related. Might be useful to see if the MX record RFC (and RFC 821/822) says anything about this. I believe SMTP MTAs have fairly sophisticated retry algorithms for failed servers, but I'm not sure if these are for a single message or per server. (Due to aggregation, probably makes no difference.) > > The idea here is just to make > > sure that SRV load balancing is observed. I don't think the text says > > anything about caching addresses, but it does have the potential > > drawback of bypassing load balancing. Since caching is likely only to be > > useful for large servers with lots of traffic, this could be a problem. > > You don't want AOL to always go to the same Earthlink server. > > The cache would need to honor DNS TTLs, as the paragraph says, so it > would eventually time out. Not caching means you may increase call setup > times waiting to fail against servers you have been failing against for > the last hour... > > -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 Jun 24 15:03: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 PAA14653 for ; Sat, 24 Jun 2000 15:03: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 E32DC443E4; Sat, 24 Jun 2000 14:50:03 -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 A23E8443DD for ; Sat, 24 Jun 2000 14:49:58 -0400 (EDT) Received: from yahoo.com (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 PAA12673; Sat, 24 Jun 2000 15:01:37 -0400 (EDT) Message-ID: <3953F7DA.BC0E3523@cs.columbia.edu> Date: Fri, 23 Jun 2000 19:50: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: Neil Deason Cc: Sean Olson , drwalker@ss8networks.com, sip@lists.bell-labs.com Subject: Re: [SIP] Announcement of SIP Forum References: <200006231612.LAA21685@b04a45.exu.ericsson.se> <395396D0.8915C308@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 While this is getting into hypotheticals (it is unlikely, say, that the SIP Forum would deny membership to any semi-reasonable candidate, as the likely "stink" generated is going to be far in excess of whatever damage the membership could conceivably cause), one low-cost model might be to provide a generally agreed upon set of call flows and sample messages, similar to the torture tests and call flows in the existing I-D, that makes the test open to community inspection and allows self-certification. Since this is not a health-and-safety issue, self-"certification" is less of a risk. I doubt that any company would want to be caught claiming "we 'passed' the set of message flows" if that was not the truth. Neil Deason wrote: > > Sean Olson wrote: > > > > Dave Walker wrote: > > > Well, I don't know about the WAP Forum, but I would think that > > > a certification program should certainly be open to non-members > > > if it's run by a forum that charges for membership. I'd be > > > surprised if a certification program could be run without > > > costs that have to be covered somehow (volunteer organizations > > > aren't too reliable in the long term). > > > > Oops. I think you have a typo in there. There a number of volunteer > > organizations in the OpenSource community that have been very > > reliable, even in the long term. > > Indeed - the IETF is made up of volunteers. > > > I do agree, however, that it is > > reasonable for an organization to charge a reasonable fee for > > certification (provided that don't make a business out of it) > > Yes, this wasn't my major concern. That is that any > closed organisation (a membership oriented > group is by definition closed to non-members, be > it because they can't afford the fees or even the > governing body reserves the right to deny membership > to them) might be able to decide what is certified > as being the standard for an open protocol, such as SIP. > > 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jun 25 16:16: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 QAA10112 for ; Sun, 25 Jun 2000 16:16: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 E59D144350; Sun, 25 Jun 2000 16:02:41 -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 A1EA944336 for ; Sun, 25 Jun 2000 16:02:38 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FWQ0050189GL3@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 25 Jun 2000 20:15:16 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FWQ0021Q89GPU@firewall.mcit.com>; Sun, 25 Jun 2000 20:15:16 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0FWQ00L018AEXT@dgismtp04.wcomnet.com>; Sun, 25 Jun 2000 20:15:50 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FWQ00L018ADXP@dgismtp04.wcomnet.com>; Sun, 25 Jun 2000 20:15:49 +0000 (GMT) Received: from C25776A ([166.46.19.214]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FWQ007GG8A45I@dgismtp04.wcomnet.com>; Sun, 25 Jun 2000 20:15:43 +0000 (GMT) Date: Sun, 25 Jun 2000 15:14:55 -0500 From: Henry Sinnreich Subject: RE: [SIP] Launch of www.sipcenter.com In-reply-to: <3951D29D.BFA3E6C4@ubiquity.net> To: Michael Doyle , sip-implementors@cs.columbia.edu, sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 Hearty congratulations and success with the SIP Center! 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 >Michael Doyle >Sent: Thursday, June 22, 2000 3:47 AM >To: sip-implementors@cs.columbia.edu; sip@lists.bell-labs.com >Subject: [SIP] Launch of www.sipcenter.com > > >UBIQUITY SOFTWARE LAUNCHES WWW.SIPCENTER.COM >WITH CO-SPONSORSHIP FROM SUN MICROSYSTEMS AND TELECOM >TECHNOLOGIES > >SIP Center - an independent portal dedicated to the >acceleration of the >commercial development of Session Initiation Protocol software. > >VON, Stockholm, Sweden, June 20th, 2000 - Ubiquity >Software Corporation, >a major developer of 'End to End' SIP Service >Solutions, today announced >the launch of the new web site: >http://www.sipcenter.com - a portal >dedicated to the development and deployment of SIP >(Session Initiation >Protocol) based products. Ubiquity's co-sponsors, Sun >Microsystems and >telecom technologies, will be assisting with >promotion, next generation >technologies and services. The SIP Center web site, >designed for both >technical and commercial use, is an open and >independent site where SIP >ideas and views can be exchanged. With a unique Test >Bed Area, SIP >software developers can access to SIP software for >interoperability >testing 24hrs a day, 7 days a week, 365 days a year. > >There are no membership fees or joining process and >all companies are >invited to participate in the exchange of ideas and >news items related >to the SIP community. Interactive forums have been >setup to facilitiate >rapid exchange of information. > >The SIP Center is actively seeking sponsorship from >other companies and >organisations. > >-- >Michael Doyle Ubiquity >Software Corporation >Chief Technology Officer Ubiquity House >Tel: +44 (0) 1633-765600 Langstone Park >Fax: +44 (0) 1633-765601 Newport NP18 2LH >URL: http://www.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 Sun Jun 25 17:23: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 RAA10404 for ; Sun, 25 Jun 2000 17:23: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 089804434E; Sun, 25 Jun 2000 17:10:45 -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 DFBA044336 for ; Sun, 25 Jun 2000 17:10:42 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FWQ00J01BEXVH@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 25 Jun 2000 21:23:21 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FWQ001DXBEXWO@firewall.mcit.com>; Sun, 25 Jun 2000 21:23:21 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0FWQ00L01BFULC@dgismtp04.wcomnet.com>; Sun, 25 Jun 2000 21:23:54 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FWQ00L01BFUKZ@dgismtp04.wcomnet.com>; Sun, 25 Jun 2000 21:23:54 +0000 (GMT) Received: from C25776A ([166.46.19.214]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FWQ00184BFG15@dgismtp04.wcomnet.com>; Sun, 25 Jun 2000 21:23:42 +0000 (GMT) Date: Sun, 25 Jun 2000 16:22:54 -0500 From: Henry Sinnreich Subject: RE: [SIP] Announcement of SIP Forum In-reply-to: <3952587E.3930A139@ss8networks.com> To: Dave Walker , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 serious misgivings about a certification program. The SIP bakeoffs provide excellent and discreet info that helps vendors correct their bugs. Would rather see vendors stating compliance with the published I-D's with call flows. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dave Walker >Sent: Thursday, June 22, 2000 1:19 PM >To: 'sip@lists.bell-labs.com' >Subject: Re: [SIP] Announcement of SIP Forum > > >In case anyone is not aware of it, I believe that this type >of certification program is currently being considered by the >SIP Working Group in the Softswitch Consortium (which is *not* >looking for post-H.323 work!). > >Dave Walker >SS8 Networks >Ottawa, Canada > > >Henning Schulzrinne wrote: >> >> One of the ideas that was discussed at the Telia >dinner in Stockholm was >> whether there was a need for a basic SIP >certification program. There >> are obvious pluses and minuses for this, but my >concern is that if this >> is a real need, I can think of a few organizations >(looking for >> post-H.323 work...) that I would rather *not* see doing this. >> -- >> 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jun 25 22:47: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 WAA13601 for ; Sun, 25 Jun 2000 22:47: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 0B8A944353; Sun, 25 Jun 2000 22:34:05 -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 6ED1644336 for ; Sun, 25 Jun 2000 22:34:02 -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 UAA29723; Sun, 25 Jun 2000 20:46:41 -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 TAA08100; Sun, 25 Jun 2000 19:46:40 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id TAA26933; Sun, 25 Jun 2000 19:46:07 -0700 (PDT) From: James Kempf Message-Id: <200006260246.TAA26933@nasnfs.eng.sun.com> Date: Sun, 25 Jun 2000 19:47:52 -0700 To: "Henning Schulzrinne" , "James Kempf" Cc: Reply-To: Subject: Re: [SIP] Feature Processing Draft? X-Mailer: Sun NetMail 2.3 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 For example, suppose the SIP proxy server gets an INVITE from a client that's a prepaid cellular caller, and the company that sold the service is not the operator. The operator's SIP proxy would like to pass authorization and accounting (and potentially handling the call itself) to the third party server. This *particular* example involves authorization and accounting, but one could imagine other such features that do not involve them but are actually implemented by a third party. I'm familiar with OPTIONS, which seems to be a way for the SIP server itself to advertise that it supports particular features. Is SIP the proper way for the SIP server to communicate with a server implementing the actual options themselves or would that be some other protocol? jak >Can you explain what you mean by "feature processing"? That's not really >a SIP term... > >James Kempf wrote: >> >> Can anybody point me at a draft that discusses call feature processing in >SIP? >> In particular, I'm interested in anything that separates feature >> processing from initial connection management. Thanx. >> >> jak >> >> _______________________________________________ >> 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 Jun 25 22:58: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 WAA13651 for ; Sun, 25 Jun 2000 22:58: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 805E044359; Sun, 25 Jun 2000 22:45:58 -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 92FAD44336 for ; Sun, 25 Jun 2000 22:45:55 -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 WAA15267; Sun, 25 Jun 2000 22:56:23 -0400 (EDT) Message-ID: <3956C699.BF38BB48@cs.columbia.edu> Date: Sun, 25 Jun 2000 22:57:29 -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: James.Kempf@eng.sun.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Feature Processing Draft? References: <200006260246.TAA26933@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 Rather than repackaging SIP requests into another protocol (since probably almost information in the request might be useful for some service or another), it would seem easiest if the SIP proxy server simply proxies the request to the server that has the necessary information. Elsewhere, one might to need to worry about sending signaling around, but this seems easiest in the SIP case. Clearly, for some specialized applications, such as QoS and AAA, the mechanisms described in draft-sinnreich-sip-qos-osp might be useful. James Kempf wrote: > > For example, suppose the SIP proxy server gets an INVITE from a client that's a prepaid > cellular caller, and the company that sold the service is not the operator. > The operator's SIP proxy would like to pass authorization and accounting > (and potentially handling the call itself) to the third party server. > > This *particular* example involves authorization and accounting, but one could imagine other > such features that do not involve them but are actually implemented by > a third party. > > I'm familiar with OPTIONS, which seems to be a way for the SIP server itself > to advertise that it supports particular features. Is SIP the proper way for > the SIP server to communicate with a server implementing the actual options > themselves or would that be some other protocol? > > jak > > >Can you explain what you mean by "feature processing"? That's not really > >a SIP term... > > > >James Kempf wrote: > >> > >> Can anybody point me at a draft that discusses call feature processing in > >SIP? > >> In particular, I'm interested in anything that separates feature > >> processing from initial connection management. Thanx. > >> > >> jak > >> > >> _______________________________________________ > >> 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 Jun 26 00:16: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 AAA14441 for ; Mon, 26 Jun 2000 00:16: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 6851E4434C; Mon, 26 Jun 2000 00:03:53 -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 4051E44336 for ; Mon, 26 Jun 2000 00:03:50 -0400 (EDT) Received: from dynamicsoft.com (1Cust52.tnt1.freehold.nj.da.uu.net [63.17.113.52]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01089; Mon, 26 Jun 2000 00:17:32 -0400 (EDT) Message-ID: <3956D96F.AE5A9495@dynamicsoft.com> Date: Mon, 26 Jun 2000 00:17:51 -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: "'Henning Schulzrinne'" , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images 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: > > Perhaps an accompanying *-Disposition or *-Type or *-Function header to > describe the purpose of *-Info would be helpful. This stops a UA trying to > display something that was not supposed to be. Actually, IMO, this goal > would perhaps be better served by incorporating the > function/type/disposition information into the actual *-Info field. This > would make the provisioning of multiple *-Info headers much simpler. Agree; sounds like a parameter: Display-Info: http://www.example.com/picture;purpose=picture, http://www.example.com/hello.au;purpose=speakname We would need to define some basic purpose values, and then define a procedure for specifying new ones with IANA. -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 Jun 26 03:02: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 DAA27697 for ; Mon, 26 Jun 2000 03:02: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 82D1144350; Mon, 26 Jun 2000 02:49:46 -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 0C58244336 for ; Mon, 26 Jun 2000 02:49:43 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 00:03:00 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" Cc: "'Henning Schulzrinne'" , sip@lists.bell-labs.com Subject: RE: [SIP] Static Images Date: Mon, 26 Jun 2000 00:02:59 -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 Perhaps this Display-Info field could also be used to describe inline content. This means that all information regarding optional content is in the same place. Display-Info: http://www.example.com/picture;purpose=picture,inline:2;purpose=aboutme where inline:2 means that the content is contained in the second multipart body. [Although this would place a requirement on proxies adding multipart bodies to place them at the end.] Do you think that a mime type parameter is required (especially for URL's)? eg Display-Info: http://www.example.com/picture;purpose=picture;type=image/tiff Robert. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, June 26, 2000 12:18 PM To: Fairlie-Cuninghame, Robert Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com Subject: Re: [SIP] Static Images "Fairlie-Cuninghame, Robert" wrote: > > Perhaps an accompanying *-Disposition or *-Type or *-Function header to > describe the purpose of *-Info would be helpful. This stops a UA trying to > display something that was not supposed to be. Actually, IMO, this goal > would perhaps be better served by incorporating the > function/type/disposition information into the actual *-Info field. This > would make the provisioning of multiple *-Info headers much simpler. Agree; sounds like a parameter: Display-Info: http://www.example.com/picture;purpose=picture, http://www.example.com/hello.au;purpose=speakname We would need to define some basic purpose values, and then define a procedure for specifying new ones with IANA. -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 Jun 26 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 EAA28397 for ; Mon, 26 Jun 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 461E74434D; Mon, 26 Jun 2000 04:28:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.192.45]) by lists.bell-labs.com (Postfix) with ESMTP id 8750844336 for ; Mon, 26 Jun 2000 04:28:53 -0400 (EDT) Received: from [193.118.192.41] by cundall.co.uk with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 26 Jun 2000 09:40:08 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: References: Date: Mon, 26 Jun 2000 09:41:36 +0100 To: "Fairlie-Cuninghame, Robert" , "'Jonathan Rosenberg'" From: Lawrence Conroy Subject: RE: [SIP] Static Images Cc: "'Henning Schulzrinne'" , sip@lists.bell-labs.com 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:02 am -0700 26/6/00, Fairlie-Cuninghame, Robert wrote: >Perhaps this Display-Info field could also be used to describe inline >content. This means that all information regarding optional content is in >the same place. > >Display-Info: >http://www.example.com/picture;purpose=picture,inline:2;purpose=aboutme > >where inline:2 means that the content is contained in the second multipart >body. [Although this would place a requirement on proxies adding multipart >bodies to place them at the end.] > >Do you think that a mime type parameter is required (especially for URL's)? >eg >Display-Info: http://www.example.com/picture;purpose=picture;type=image/tiff > >Robert. > Problem is, there is an ASSUMPTION here that the body parts are never re-ordered. This would require a prohibition or re-ordering, as implied above. If you use the body part content-ID field instead of just a plain part index, then re-ordering is no longer a problem, and we don't have to add such a prohibition. Thus, inline:2@3456 indicates the subpart with a content-id:2@3456. MIME Content-ID is defined Appendix A of RFC 2045, and that in turn took it from RFC822. We stand on the shoulders of giants. -- All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd pay me for them" | |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 26 08: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 IAA03219 for ; Mon, 26 Jun 2000 08:42: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 8F65444350; Mon, 26 Jun 2000 08:29:06 -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 84C0044336 for ; Mon, 26 Jun 2000 08:29:03 -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 IAA22958; Mon, 26 Jun 2000 08:41:45 -0400 (EDT) Message-ID: <39574F89.B09A504E@cs.columbia.edu> Date: Mon, 26 Jun 2000 08:41:45 -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: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images 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: > > Perhaps this Display-Info field could also be used to describe inline > content. This means that all information regarding optional content is in > the same place. > > Display-Info: > http://www.example.com/picture;purpose=picture,inline:2;purpose=aboutme > > where inline:2 means that the content is contained in the second multipart > body. [Although this would place a requirement on proxies adding multipart > bodies to place them at the end.] > > Do you think that a mime type parameter is required (especially for URL's)? > eg > Display-Info: http://www.example.com/picture;purpose=picture;type=image/tiff I know this is tempting, but can we please make this implementable in less than a GHz Pentium workstation and describable in less than 30 pages? Adding MIME types to a URL is a really bad idea. URLs may well map to several different MIME types, depending on content negotiation. (This is implemented in Apache, for example.) Since it doesn't matter, semantically, whether you speak something or display it, I would also be disinclined about being too specific about the rendering method used. We don't do this for the web, either. -- 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 Jun 26 08:58: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 IAA03693 for ; Mon, 26 Jun 2000 08:58: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 6AB134435F; Mon, 26 Jun 2000 08:45:29 -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 9B4654435D for ; Mon, 26 Jun 2000 08:45:26 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id HAA17624; Mon, 26 Jun 2000 07:58:10 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id HAA19852; Mon, 26 Jun 2000 07:58:08 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id HAA26859; Mon, 26 Jun 2000 07:58:07 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id HAA00122; Mon, 26 Jun 2000 07:58:07 -0500 (CDT) Message-Id: <200006261258.HAA00122@b04a24.exu.ericsson.se> Subject: Re: [SIP] Static Images To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Mon, 26 Jun 2000 07:58:07 -0500 (CDT) Cc: rfairlie@nuera.com (Fairlie-Cuninghame Robert), hgs@cs.columbia.edu ('Henning Schulzrinne'), sip@lists.bell-labs.com In-Reply-To: <3956D96F.AE5A9495@dynamicsoft.com> from "Jonathan Rosenberg" at Jun 26, 2000 12:17:51 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 >Agree; sounds like a parameter: > >Display-Info: http://www.example.com/picture;purpose=picture, > http://www.example.com/hello.au;purpose=speakname > >We would need to define some basic purpose values, and then define a >procedure for specifying new ones with IANA. I'm with Henning on this one: your values seem to imply a certain type of *rendering*, not a certain type of information -- and, in HTTP at least, it's the client's responsiblity to render the content type fetched in a appropriate form. Display-Info: http://www.example.com/call-id/adam.roach For example, if you fetch this URI with an Accept of "audio/*", and no video parameters, the HTTP server may return an audio clip. If you send both of "audio/*, image/*", it may return a GIF instead. This has to do with trusting the way HTTP currently handles browser capabilities. I know this isn't widely used right now, even though servers (and browsers) support it; I'm sure this type of use of HTTP will expand as terminals evolve away from 17" screens with 101-key keyboards. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 26 09:17: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 JAA04402 for ; Mon, 26 Jun 2000 09:17: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 E34274435E; Mon, 26 Jun 2000 09:04:02 -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 372D444346 for ; Mon, 26 Jun 2000 09:03:58 -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 IAA29535; Mon, 26 Jun 2000 08:16:40 -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 IAA00694; Mon, 26 Jun 2000 08:16:25 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA27588; Mon, 26 Jun 2000 08:16:25 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id IAA00141; Mon, 26 Jun 2000 08:16:24 -0500 (CDT) Message-Id: <200006261316.IAA00141@b04a24.exu.ericsson.se> Subject: Re: [SIP] Static Images To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Mon, 26 Jun 2000 08:16:24 -0500 (CDT) Cc: hgs@cs.columbia.edu (Henning Schulzrinne), rfairlie@nuera.com (Fairlie-Cuninghame Robert), schulzrinne@cs.columbia.edu (Henning Schulzrinne), vektor@div8.net (Billy Biggs), C.Perkins@cs.ucl.ac.uk (Colin Perkins), sip@lists.bell-labs.com In-Reply-To: <3953189E.4125273D@dynamicsoft.com> from "Jonathan Rosenberg" at Jun 23, 2000 03:58:22 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 >So, in the interests of coming to consensus, let me propose that: > >1. inline content MAY be included, possibly using multipart. This would >obviously include MIME types like application/URI-list which are >themselves indirect references I agree with your goal, but my originally posed question seems a bit unanswered still. If you'll remember, the goal was to send arbitrary-sized still images (or a single image) after a conversation has been set up. This can be generalised into the problem of sending arbitrary data during the course of a conversation, where the data has no realtime characteristics. I prefer this problem description, since it avoids being mired down with the realtime stuff like low bitrate codecs (which I don't think address my problem; they all aim towards error concealment instead of error correction). If I read the ongoing conversation so far, the consensus would seem to point to a solution of sending an INFO midcall (or possibly a re-INVITE, to keep the number of required extensions somewhat lower); this INFO or INVITE would contain a new header (Display-Info has been proposed) with a URL. Since the image in this case is expected to originate from the terminal sending the INFO or INVITE, it would be an HTTP URL pointing to itself, with some sort of identifier to tie back to the call or resource (implementation dependant, but chosen to be the call ID in this example). INVITE sip:bob@terminal1273.example.com SIP/2.0 From: Adam Roach ;tag=99999 To: Bob Example ;tag=44444 Call-ID: 12345@b04a24.exu.ericsson.se Display-Info: http://b04a24.exu.ericsson.se/12345 Bob's terminal would then contact mine using HTTP to get the picture: GET /12345 HTTP/1.0 Accept: image/jpeg, image/png, video/mpeg, audio/ulaw So, the terminals would need a minimal HTTP implementation for this purpose. I have no problem with this; I just wanted to make sure that, given this information, the consensus remains the same. Finally, I pose a quick straw poll: INFO or INVITE? INFO requires much less processing (since it can't change callstate), while INVITE will already be implemented on all clients. (Consider: what does your implementation do if it gets a re-INVITE with no SDP present? With unchanged SDP? Are you sure everyone else has done the same thing?) -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 26 09:24: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 JAA04653 for ; Mon, 26 Jun 2000 09:24: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 C561A44359; Mon, 26 Jun 2000 09:11:35 -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 A993744346 for ; Mon, 26 Jun 2000 09:11:32 -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 IAA05273; Mon, 26 Jun 2000 08:24:15 -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 IAA02405; Mon, 26 Jun 2000 08:24:13 -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 IAA28076; Mon, 26 Jun 2000 08:24:12 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id IAA26550; Mon, 26 Jun 2000 08:24:12 -0500 (CDT) Date: Mon, 26 Jun 2000 08:24:12 -0500 (CDT) Message-Id: <200006261324.IAA26550@b04a45.exu.ericsson.se> To: rfairlie@nuera.com, schulzrinne@cs.columbia.edu Subject: Re: [SIP] Static Images Cc: jdrosen@dynamicsoft.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 X-BeenThere: sip@lists.bell-labs.com > "Fairlie-Cuninghame, Robert" wrote: > > > > Perhaps this Display-Info field could also be used to describe inline > > content. This means that all information regarding optional content is in > > the same place. > > > > Display-Info: > > http://www.example.com/picture;purpose=picture,inline:2;purpose=aboutme > > > > where inline:2 means that the content is contained in the second multipart > > body. [Although this would place a requirement on proxies adding multipart > > bodies to place them at the end.] > > > > Do you think that a mime type parameter is required (especially for URL's)? > > eg > > Display-Info: http://www.example.com/picture;purpose=picture;type=image/tiff > This is not a road we want to go down. Especially with deeply nested multipart bodies. sean -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 26 13:38: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 NAA11728 for ; Mon, 26 Jun 2000 13:38: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 A0E0744353; Mon, 26 Jun 2000 13:25: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 23D9E44346 for ; Mon, 26 Jun 2000 13:25:15 -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 NAA04475; Mon, 26 Jun 2000 13:39:18 -0400 (EDT) Message-ID: <39579559.71A27F7B@dynamicsoft.com> Date: Mon, 26 Jun 2000 13:39:37 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Cc: Fairlie-Cuninghame Robert , "'Henning Schulzrinne'" , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006261258.HAA00122@b04a24.exu.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 "Adam B. Roach" wrote: > > >Agree; sounds like a parameter: > > > >Display-Info: http://www.example.com/picture;purpose=picture, > > http://www.example.com/hello.au;purpose=speakname > > > >We would need to define some basic purpose values, and then define a > >procedure for specifying new ones with IANA. > > I'm with Henning on this one: your values seem to imply a certain > type of *rendering*, not a certain type of information -- and, > in HTTP at least, it's the client's responsiblity to render the > content type fetched in a appropriate form. No, they don't imply any kind of mandated behavior. I was trying to address a concern raised previously on the list, which was that just the MIME type wasn't enough. Is this image a thumbnail of the caller? Is it a picture of a phone for a "graphical custom ringing" or something? The idea with this purpose thing was just a hint to indicate the purpose of the content, so that the device could do with it something reasonable, as it saw fit. -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 Jun 26 13: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 NAA11939 for ; Mon, 26 Jun 2000 13: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 354D644361; Mon, 26 Jun 2000 13:32: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 26BA04435A for ; Mon, 26 Jun 2000 13:31:57 -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 NAA04527; Mon, 26 Jun 2000 13:45:51 -0400 (EDT) Message-ID: <395796E3.41ED3068@dynamicsoft.com> Date: Mon, 26 Jun 2000 13:46:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Cc: Henning Schulzrinne , Fairlie-Cuninghame Robert , Henning Schulzrinne , Billy Biggs , Colin Perkins , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006261316.IAA00141@b04a24.exu.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 "Adam B. Roach" wrote: > > >So, in the interests of coming to consensus, let me propose that: > > > >1. inline content MAY be included, possibly using multipart. This would > >obviously include MIME types like application/URI-list which are > >themselves indirect references > > I agree with your goal, but my originally posed question > seems a bit unanswered still. If you'll remember, the goal > was to send arbitrary-sized still images (or a single > image) after a conversation has been set up. This can be > generalised into the problem of sending arbitrary data > during the course of a conversation, where the data > has no realtime characteristics. I prefer this problem > description, since it avoids being mired down with > the realtime stuff like low bitrate codecs (which I don't > think address my problem; they all aim towards error > concealment instead of error correction). The difference is artificial. You can no doubt use RTP over TCP and obtain reliable, non-real time transport. > > If I read the ongoing conversation so far, the consensus > would seem to point to a solution of sending an INFO > midcall (or possibly a re-INVITE, to keep the number of > required extensions somewhat lower); this INFO or INVITE > would contain a new header (Display-Info has been proposed) > with a URL. Since the image in this case is expected to > originate from the terminal sending the INFO or INVITE, > it would be an HTTP URL pointing to itself, with some sort > of identifier to tie back to the call or resource > (implementation dependant, but chosen to be the call ID in > this example). The URL need not point to itself, of course. If you are doing a slide show of your kids, I still think that TCP/RTP is better. If it is something more aynchronous and "one shot", I see no fault in using INFO. In fact, INFO already allows this with content in the body: > If a server receives an INFO request with a body it understands, > but it has no knowledge of INFO associated processing rules for > the body, the body MAY be rendered and displayed to the user. The > INFO is responded to with a 200 OK. I would prefer INFO to re-INVITE in this case; re-INVITE is meant to have some affect on session state. This does not. > Finally, I pose a quick straw poll: INFO or INVITE? INFO > requires much less processing (since it can't change > callstate), while INVITE will already be implemented on > all clients. (Consider: what does your implementation > do if it gets a re-INVITE with no SDP present? With unchanged > SDP? Are you sure everyone else has done the same thing?) re-INVITE with no SDP mid-call is probably an error. If you want to add a stream, you add an m line. If you want to remove one, you set its port to zero and re-INVITE. Sending no SDP at all is not right. If the SDP is unchanged, its unchanged. This is a session refresh, as per session timer. -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 Jun 26 14: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 OAA12414 for ; Mon, 26 Jun 2000 14: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 A8FEB4435A; Mon, 26 Jun 2000 13:51: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 94A4C44346 for ; Mon, 26 Jun 2000 13:50:57 -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 OAA04698; Mon, 26 Jun 2000 14:05:05 -0400 (EDT) Message-ID: <39579B64.BD7C4A04@dynamicsoft.com> Date: Mon, 26 Jun 2000 14:05:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@cisco.com> <3953BC06.59B9275E@dynamicsoft.com> <3953BD98.8545FFB9@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 Shail Bhatnagar wrote: > > Jonathan Rosenberg wrote: > > > > Shail Bhatnagar wrote: > > > > > > I don't have a problem with this simplification - but the spec says > > > an incoming request with Max-Forwards of 0 MUST NOT be forwarded. > > > It does not say that the request cannot be locally processed and a > > > response returned. Since REGISTER (for the registrar) and CANCEL > > > will be absorbed by the proxy, I thought it is okay to process these > > > requests. > > > The relevant statement in the spec should be appropriately changed - > > > > > > request MUST NOT be forward and MUST NOT be processed. > > > > That is the proposal; as I said, I think it is very confusing >otherwise. > > I thought behavior of registrars/redirect servers closely matches > user agents, in terms of request handling. Of course > there are differences. Per this proposal, a user agent will process a > request with Max-Forwards of 0 but registrars/redirect servers and > proxies will not. Is my understanding correct ?? No. Any server (UA, proxy, redirect, registrar) receiving a request with Max-Forwards zero responds with a 483 and does not process. -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 Jun 26 14:06: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 OAA12464 for ; Mon, 26 Jun 2000 14:06: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 4284744359; Mon, 26 Jun 2000 13:53:19 -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 6798444346 for ; Mon, 26 Jun 2000 13:53:16 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jun 26 14:05:08 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6DA6644348; Mon, 26 Jun 2000 13:51:59 -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 2A82044347 for ; Mon, 26 Jun 2000 13:51:59 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA24868; Mon, 26 Jun 2000 12:51:55 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA24864; Mon, 26 Jun 2000 12:51:55 -0500 Message-ID: <3957983D.64C7A019@lucent.com> Date: Mon, 26 Jun 2000 12:51:57 -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: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Compact form for CSeq Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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: Any particular reason there isn't a compact form representation of CSeq? It is a mandatory parameter in all SIP requests. Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Jun 26 14:23: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 OAA12834 for ; Mon, 26 Jun 2000 14:23: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 CB66844360; Mon, 26 Jun 2000 14:10:22 -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 978CC44336 for ; Mon, 26 Jun 2000 14:10: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 OAA23384; Mon, 26 Jun 2000 14:23:03 -0400 (EDT) Message-ID: <39579F87.7DD1CEF3@cs.columbia.edu> Date: Mon, 26 Jun 2000 14:23:03 -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: vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Compact form for CSeq References: <3957983D.64C7A019@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 "Vijay K. Gurbani" wrote: > > Hi: > > Any particular reason there isn't a compact form representation of > CSeq? It is a mandatory parameter in all SIP requests. > Mostly oversight, secondly because it would only save 3 bytes. Thirdly, it's too late to change it... -- 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 Jun 26 14:39: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 OAA13259 for ; Mon, 26 Jun 2000 14: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 BF80444362; Mon, 26 Jun 2000 14:25:32 -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 7CF5444336 for ; Mon, 26 Jun 2000 14:25: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 OAA24807; Mon, 26 Jun 2000 14:38:09 -0400 (EDT) Message-ID: <3957A311.13AACC2A@cs.columbia.edu> Date: Mon, 26 Jun 2000 14:38:09 -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: vkg@lucent.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Compact form for CSeq References: <3957983D.64C7A019@lucent.com> <39579F87.7DD1CEF3@cs.columbia.edu> <3957A17C.195ABD4B@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 "Vijay K. Gurbani" wrote: > > Henning Schulzrinne wrote: > > > > > Thirdly, it's too late to change it... > > Is it? Older UAC's can still use the full form. In any case, it is no > big deal, really. I was just looking for some orthogonality with other > required headers (like To, From, Via) and since a big drive for compact > form appears to be memory-constrained devices, CSeq, as a required > header appeared to be left out. This discussion appears to occur occasionally. We can't add abbreviations for "old" headers since old UAs wouldn't understand the compact form. (That they can't generate them is not the issue.) If you do compression, CSeq is likely to be transformed to one byte or less anyway. -- 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 Jun 26 14:46: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 OAA13427 for ; Mon, 26 Jun 2000 14:46: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 5EA384436E; Mon, 26 Jun 2000 14:32: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 3864744365 for ; Mon, 26 Jun 2000 14:32:15 -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 OAA05174; Mon, 26 Jun 2000 14:46:29 -0400 (EDT) Message-ID: <3957A51B.63B2002B@dynamicsoft.com> Date: Mon, 26 Jun 2000 14:46:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gopal Cc: sip@lists.bell-labs.com Subject: Re: [SIP] > 12. Re: Questions on section 10.1.1 of RFC2543bis (Jonathan Rosenberg) References: <200006231159.HAA01748@alliance.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 Gopal wrote: > > > No; nothing like that. I actually think the complete To field should be > > included in the comparison, so as to make this consistent with the > > definition of a call leg (which does include To). In practice it will > > There is another potential problem though with comparing tag value of To. > Consider the foll. scenario when a UAC talks directly to a UAS (no proxy) > > UAC UAS > INVITE (no tag value for To)----------->Generate new Tag value for To > (lost)X <------ 100 Trying (MAY include tag in To) > (lost)X <------ 180 Ringing (MAY include tag in To) > > (timeout. Retransmit INVITE) > INVITE ((no tag value for To)---------->Rejected since Tag value of To does not > match > > 10.1.1 of RFC2543bis I think (wrongfully) suggests the above behavior. Ideally, > re-transmission of the INVITE should trigger the 180 response from the UAS. I > think the tag value of To should be compared only if the To field in the > incoming message has a tag. Sec. 6.23 actually states that tag values of 2 > URIs are compared only if both URIs have tags. How about changing the sentence to > > "If the Call-ID was found, it compares the tag value of To (if present) > with the users tag and rejects the request if the two do not match." > > -gopal Right. This also allows you to send a BYE without knowing the tag, something that can cause problems, but people seem very insistent on. We'll try to clean up the description. Tags are an unending source of confusion. -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 Jun 26 14:47: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 OAA13472 for ; Mon, 26 Jun 2000 14:47: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 D326444374; Mon, 26 Jun 2000 14:32:49 -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 F2AE244365 for ; Mon, 26 Jun 2000 14:32:46 -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 OAA05145; Mon, 26 Jun 2000 14:43:15 -0400 (EDT) Message-ID: <3957A459.8CB43356@dynamicsoft.com> Date: Mon, 26 Jun 2000 14:43:37 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Hoffer Cc: sip@lists.bell-labs.com Subject: Re: [SIP] PGP Authentication Scheme - REPOST References: <39535A2F.C9CC6AF9@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 Phil Hoffer wrote: > > Hi, > > Section 15.1.1 of the rfc2543bis draft is missing information, and a BNF entry with respect to pgp-pubalgolrithm. > > Presumably, pgp-pubalgolrithm should be included in the BNF for pgp-params in section 15.1.1 Yes, I believe it should. > > Also some text about the parameter is required, e.g. what is the default value of pgp-pubalgolrithm if it is omitted from WWW-Authenticate header. > Is it assumed to be RSA? I presume... I guess it depends on what the default is for PGP in general, if there is a default...? -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 Jun 26 14:49: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 OAA13522 for ; Mon, 26 Jun 2000 14:49: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 DCF414438B; Mon, 26 Jun 2000 14:33:18 -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 D59DB4437B for ; Mon, 26 Jun 2000 14:33:15 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jun 26 14:44:36 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 50DAB44348; Mon, 26 Jun 2000 14:31:27 -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 0FA4344347 for ; Mon, 26 Jun 2000 14:31:27 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA05557; Mon, 26 Jun 2000 13:31:23 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA05547; Mon, 26 Jun 2000 13:31:22 -0500 Message-ID: <3957A17C.195ABD4B@lucent.com> Date: Mon, 26 Jun 2000 13:31:24 -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: Henning Schulzrinne Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Compact form for CSeq References: <3957983D.64C7A019@lucent.com> <39579F87.7DD1CEF3@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: > > "Vijay K. Gurbani" wrote: > > > > Hi: > > > > Any particular reason there isn't a compact form representation of > > CSeq? It is a mandatory parameter in all SIP requests. > > > > Mostly oversight, secondly because it would only save 3 bytes. That's what I thought, but since we have a compact form for To and Via (at a savings of 1 and 2 bytes respectively), I figured maybe CSeq should be included as well since it is a required header in all requests. > Thirdly, it's too late to change it... Is it? Older UAC's can still use the full form. In any case, it is no big deal, really. I was just looking for some orthogonality with other required headers (like To, From, Via) and since a big drive for compact form appears to be memory-constrained devices, CSeq, as a required header appeared to be left out. Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Jun 26 15:27: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 PAA14442 for ; Mon, 26 Jun 2000 15:27: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 22D1A44360; Mon, 26 Jun 2000 15:13:20 -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 946F144336 for ; Mon, 26 Jun 2000 15:13:16 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon Jun 26 15:25:55 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3938544348; Mon, 26 Jun 2000 15:12:46 -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 E10BC44347 for ; Mon, 26 Jun 2000 15:12:45 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21668; Mon, 26 Jun 2000 14:12:42 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21664; Mon, 26 Jun 2000 14:12:41 -0500 Message-ID: <3957AB2C.1AEE3ED0@lucent.com> Date: Mon, 26 Jun 2000 14:12:44 -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: sip@lists.bell-labs.com, shh@microappliances.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] More on tags Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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: A collegue asked this question of me, for which I have an answer (see below), but would like to validate it. Question: Why does the RFCbis (June 9, 2000) mandate that the tag be "globally unique" (Section 6.23)? Can't it be unique within the Call-ID space it occupies? The Call-ID already is "a globally unique identifier". Why have 2 globally unique identifiers to identify a single call leg? One reason I can think of is that if multiple UA servers are contacted for a call, this wording guarantees that each of the UA servers use an algorithm to generate a globally unique tag; otherwise, if each of them used, say, the time of day to generate the tag (and they happen to be in the same time zone etc. etc.), there could be a potential to generate the same tag at each UA server. Is this accurate? Any other reasons? Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group 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 Jun 26 15:49: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 PAA14746 for ; Mon, 26 Jun 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 4BD3844361; Mon, 26 Jun 2000 15:48:51 -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 031E744336 for ; Mon, 26 Jun 2000 15:48:48 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA05777; Mon, 26 Jun 2000 15:44:16 -0400 (EDT) Message-ID: <3957B290.F14A4BE8@cisco.com> Date: Mon, 26 Jun 2000 15:44:16 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@cisco.com> <3953BC06.59B9275E@dynamicsoft.com> <3953BD98.8545FFB9@cisco.com> <39579B64.BD7C4A04@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 > > I thought behavior of registrars/redirect servers closely matches > > user agents, in terms of request handling. Of course > > there are differences. Per this proposal, a user agent will process a > > request with Max-Forwards of 0 but registrars/redirect servers and > > proxies will not. Is my understanding correct ?? > > No. Any server (UA, proxy, redirect, registrar) receiving a request with > Max-Forwards zero responds with a 483 and does not process. > > -Jonathan R. > Okay, so any proxy should not forward a request with incoming Max-Forwards 1, since if it forwards it, Max-Forwards will become 0 and the downstream guy will return 483. Right ?? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 26 16:25: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 QAA15329 for ; Mon, 26 Jun 2000 16:25: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 59E6944362; Mon, 26 Jun 2000 16:24:44 -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 4013044336 for ; Mon, 26 Jun 2000 16:24:41 -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 QAA06296; Mon, 26 Jun 2000 16:22:03 -0400 (EDT) Message-ID: <3957BB81.F3888271@dynamicsoft.com> Date: Mon, 26 Jun 2000 16:22:25 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@cisco.com> <3953BC06.59B9275E@dynamicsoft.com> <3953BD98.8545FFB9@cisco.com> <39579B64.BD7C4A04@dynamicsoft.com> <3957B290.F14A4BE8@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 Shail Bhatnagar wrote: > > > > I thought behavior of registrars/redirect servers closely matches > > > user agents, in terms of request handling. Of course > > > there are differences. Per this proposal, a user agent will process a > > > request with Max-Forwards of 0 but registrars/redirect servers and > > > proxies will not. Is my understanding correct ?? > > > > No. Any server (UA, proxy, redirect, registrar) receiving a request with > > Max-Forwards zero responds with a 483 and does not process. > > > > -Jonathan R. > > > > Okay, so any proxy should not forward a request with incoming > Max-Forwards 1, since if it forwards it, Max-Forwards will become > 0 and the downstream guy will return 483. > > Right ?? 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 Mon Jun 26 16:36: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 QAA15477 for ; Mon, 26 Jun 2000 16:36: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 900694436E; Mon, 26 Jun 2000 16:35:20 -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 1F34544361 for ; Mon, 26 Jun 2000 16:35:17 -0400 (EDT) Received: from computer.ix.netcom.com (pool-209-138-155-208-ipls.grid.net [209.138.155.208]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA14206; Mon, 26 Jun 2000 16:35:04 -0400 (EDT) Message-Id: <4.3.1.2.20000626153204.00cbb940@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: Mon, 26 Jun 2000 15:36:00 -0500 To: Jonathan Rosenberg , "Adam B. Roach" From: Richard Shockey Subject: Re: [SIP] Static Images Cc: Fairlie-Cuninghame Robert , "'Henning Schulzrinne'" , sip@lists.bell-labs.com In-Reply-To: <39579559.71A27F7B@dynamicsoft.com> References: <200006261258.HAA00122@b04a24.exu.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 > > > >Display-Info: http://www.example.com/picture;purpose=picture, > > > http://www.example.com/hello.au;purpose=speakname > > > > > >We would need to define some basic purpose values, and then define a > > >procedure for specifying new ones with IANA. > > > > I'm with Henning on this one: your values seem to imply a certain > > type of *rendering*, not a certain type of information -- and, > > in HTTP at least, it's the client's responsiblity to render the > > content type fetched in a appropriate form. > >No, they don't imply any kind of mandated behavior. I was trying to >address a concern raised previously on the list, which was that just the >MIME type wasn't enough. Is this image a thumbnail of the caller? Is it >a picture of a phone for a "graphical custom ringing" or something? The >idea with this purpose thing was just a hint to indicate the purpose of >the content, so that the device could do with it something reasonable, >as it saw fit. Gentlemen ... I'd like to offer a "RATHOLE ALERT" here. The problem of defining content-types and the priority of those content-types in processing has been thoroughly debated in the VPIM WG with no conclusion. Please note { draft-burger-vpim-cc-00.txt } for some background discussion of what you are getting into. The context of each application is different but the problem statement is quite similar. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Mon Jun 26 16:37: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 QAA15492 for ; Mon, 26 Jun 2000 16:37: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 D8E1E44379; Mon, 26 Jun 2000 16:37: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 A77A244374 for ; Mon, 26 Jun 2000 16:37: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 QAA05185; Mon, 26 Jun 2000 16:33:35 -0400 (EDT) Message-ID: <3957BE1F.5A892769@cs.columbia.edu> Date: Mon, 26 Jun 2000 16:33: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: Jonathan Rosenberg Cc: Shail Bhatnagar , Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@cisco.com> <3953BC06.59B9275E@dynamicsoft.com> <3953BD98.8545FFB9@cisco.com> <39579B64.BD7C4A04@dynamicsoft.com> <3957B290.F14A4BE8@cisco.com> <3957BB81.F3888271@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: > > Shail Bhatnagar wrote: > > > > > > I thought behavior of registrars/redirect servers closely matches > > > > user agents, in terms of request handling. Of course > > > > there are differences. Per this proposal, a user agent will process a > > > > request with Max-Forwards of 0 but registrars/redirect servers and > > > > proxies will not. Is my understanding correct ?? > > > > > > No. Any server (UA, proxy, redirect, registrar) receiving a request with > > > Max-Forwards zero responds with a 483 and does not process. > > > > > > -Jonathan R. > > > > > > > Okay, so any proxy should not forward a request with incoming > > Max-Forwards 1, since if it forwards it, Max-Forwards will become > > 0 and the downstream guy will return 483. > > > > Right ?? > > I suppose so, yes. But that would defeat the whole point of being able to figure out the downstream capabilities, returned in the 483. Thus, a proxy should *not* try to be too smart. After all, if IP routers did this, traceroute wouldn't work... -- 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 Jun 26 18:01: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 SAA16511 for ; Mon, 26 Jun 2000 18:01: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 815AB44365; Mon, 26 Jun 2000 18:01:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6F28944336 for ; Mon, 26 Jun 2000 18:01:19 -0400 (EDT) Date: Tue, 27 Jun 2000 00:01:40 +0200 (CEST) From: Lars Berggren To: Poornima.Lalwaney@nokia.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Distributing call state : draft-dcsgroup-sip-state-01.txt 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 Some comments: 1. The extension does not define an option-tag to be used with the Require and Supported header fields. How would a proxy know that the UAC or UAS support the 'state' extension? 2. Section 4.2 mentions that the state header is included in subsequent INVITEs. What about BYE requests? I think it could be useful to include it in BYEs also, since BYEs certainly affects call state. /Lars On Fri, 23 Jun 2000 Poornima.Lalwaney@nokia.com wrote: > > The draft draft-dcsgroup-sip-state-01.txt was presented in Adelaide. In > brief, the draft discusses the "State" header extension that may be used to > transfer call state from the proxy to the UAC. The proxy can then be > stateless for the duration of the call. The state is stored at the > UAC/endpoint for the duration of the call and passed back to the proxy if > mid-call changes are required. The draft also includes rules at endpoints > and proxies on inclusion and processing of State headers. Comments and > suggestions on the State header extension as presented in draft-01 are > welcome. (this is available at > http://search.ietf.org/internet-drafts/draft-dcsgroup-sip-state-01.txt ). > > I am in the process of updating the draft and submitting it as > draft-dcsgroup-sip-state-02.txt before the Pittsburgh IETF. The dcsgroup has > cleared the RFC2026 issues and the updated draft will reflect that and > comments received on this list on the proposed State header extension and > associated rules. > > > Thanks and regards, > Poornima Lalwaney > > > > ------------------------------------------------ > Poornima Lalwaney > Nokia > poornima.lalwaney@nokia.com > Tel: +1 858-831-4727 > ----------------------------------------------- > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jun 26 23:49: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 XAA21302 for ; Mon, 26 Jun 2000 23:49: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 0CB324436D; Mon, 26 Jun 2000 23:48: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 DF39E44336 for ; Mon, 26 Jun 2000 23:48:48 -0400 (EDT) Received: from dynamicsoft.com (1Cust239.tnt2.freehold.nj.da.uu.net [63.17.114.239]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA08112; Mon, 26 Jun 2000 23:46:01 -0400 (EDT) Message-ID: <3958238F.FD826DD9@dynamicsoft.com> Date: Mon, 26 Jun 2000 23:46:23 -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: Shail Bhatnagar , Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@cisco.com> <3953BC06.59B9275E@dynamicsoft.com> <3953BD98.8545FFB9@cisco.com> <39579B64.BD7C4A04@dynamicsoft.com> <3957B290.F14A4BE8@cisco.com> <3957BB81.F3888271@dynamicsoft.com> <3957BE1F.5A892769@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: > > > > Okay, so any proxy should not forward a request with incoming > > > Max-Forwards 1, since if it forwards it, Max-Forwards will become > > > 0 and the downstream guy will return 483. > > > > > > Right ?? > > > > I suppose so, yes. > > But that would defeat the whole point of being able to figure out the > downstream capabilities, returned in the 483. Thus, a proxy should *not* > try to be too smart. After all, if IP routers did this, traceroute > wouldn't work... I was assuming that the proxy wouldn't say anything useful in the 483. If it does contain a Supported header, then yes, you are right. Sooo, seems like in general it is NOT a good idea to drop the request with Max-Forwards 1. -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 Jun 26 23:52: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 XAA21317 for ; Mon, 26 Jun 2000 23:52: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 3746844365; Mon, 26 Jun 2000 23:52:01 -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 C4A0A44360 for ; Mon, 26 Jun 2000 23:51:57 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 20:52:35 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Max-Forwards + Proxies Date: Mon, 26 Jun 2000 20:52:32 -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 the IP TTL operates in the way that Johnathan described. That is, a router should not forward packets with a TTL of 0 or 1 (returning an ICMP in both cases). A Host however is free to process a received packet with a TTL of 0 or 1 (although it should not normally receive a packet with a TTL of 0). Traceroute knows that it reached the destination because the endpoint returns an ICMP Echo reply (rather than ICMp Time Exceeded). This is not necessarily the behavior we want in this case but I thought I would straighten out the analogy. Cheers, Robert. -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Tuesday, June 27, 2000 4:34 AM To: Jonathan Rosenberg Cc: Shail Bhatnagar; Neil Deason; Sean Olson; vkg@lucent.com; sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies Jonathan Rosenberg wrote: > > Shail Bhatnagar wrote: > > > > > > I thought behavior of registrars/redirect servers closely matches > > > > user agents, in terms of request handling. Of course > > > > there are differences. Per this proposal, a user agent will process a > > > > request with Max-Forwards of 0 but registrars/redirect servers and > > > > proxies will not. Is my understanding correct ?? > > > > > > No. Any server (UA, proxy, redirect, registrar) receiving a request with > > > Max-Forwards zero responds with a 483 and does not process. > > > > > > -Jonathan R. > > > > > > > Okay, so any proxy should not forward a request with incoming > > Max-Forwards 1, since if it forwards it, Max-Forwards will become > > 0 and the downstream guy will return 483. > > > > Right ?? > > I suppose so, yes. But that would defeat the whole point of being able to figure out the downstream capabilities, returned in the 483. Thus, a proxy should *not* try to be too smart. After all, if IP routers did this, traceroute wouldn't work... -- 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 Tue Jun 27 02:06: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 CAA04312 for ; Tue, 27 Jun 2000 02:06: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 29D6144365; Tue, 27 Jun 2000 02:05:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6D20244336 for ; Tue, 27 Jun 2000 02:05:42 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id LAA09287 for ; Tue, 27 Jun 2000 11:34:26 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Tue, 27 Jun 2000 11:34:25 +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 LAA01700 for ; Tue, 27 Jun 2000 11:34:21 +0530 (IST) Message-ID: <01e501bfdffd$4f55b480$8c40000a@sasi.com> From: "rafi" To: Date: Tue, 27 Jun 2000 11:32:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E2_01BFE02B.68D26E20" 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] SIP:dcsgroup:draft-dcsgroup-sip-privacy-01.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 multi-part message in MIME format. ------=_NextPart_000_01E2_01BFE02B.68D26E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Couple of comment on the draft. Syntax for Anonymity is given as (1) Anonymity =3D "Anonymity" ":" *privacy-tag privacy-tag =3D "Full" | "URI" | "Name" | "IPAddr" | "Off" I think it should have been, Anonymity =3D "Anonymity" ":" 1#privacy-tag privacy-tag =3D "Full" | "URI" | "Name" | "IPAddr" | "Off" (2) When DCS-proxy-t encrypts the "addr-spec" in the Remote-Party-ID I think it should use different key each time it encrypts. Thank You Rafi Assadi H.M. Silicon Automation Systems Bangalore, INDIA ------=_NextPart_000_01E2_01BFE02B.68D26E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Couple of comment on the = draft.
 
Syntax for Anonymity is given = as
 
(1)   =20  Anonymity       =3D "Anonymity" = ":" =20 *privacy-tag
      =   =20 privacy-tag     =3D "Full" | "URI" | "Name" | = "IPAddr" |=20 "Off"
 
I think it should have = been,
 
       Anonymity  &= nbsp;   =20 =3D "Anonymity" ":"  = 1#privacy-tag
     =20  privacy-tag     =3D "Full" | "URI" | "Name" | = "IPAddr" |=20 "Off"
 
 
(2)  When DCS-proxy-t  = encrypts the=20 "addr-spec" in the Remote-Party-ID
       I = think it=20 should use different key each time it encrypts.
 
 
Thank You
Rafi Assadi H.M.
Silicon Automation Systems
Bangalore, INDIA

 
------=_NextPart_000_01E2_01BFE02B.68D26E20-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 27 04:10: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 EAA05006 for ; Tue, 27 Jun 2000 04:10: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 B6CF944360; Tue, 27 Jun 2000 04:10:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mip.miptel.com (unknown [210.108.73.141]) by lists.bell-labs.com (Postfix) with ESMTP id 127DC44336 for ; Tue, 27 Jun 2000 04:10:45 -0400 (EDT) Received: from khlee ([210.108.73.150]) by mip.miptel.com (8.9.3/8.8.7) with SMTP id RAA21285 for ; Tue, 27 Jun 2000 17:11:47 +0900 Message-ID: <002601bfe00f$25f4e180$96496cd2@miptel.com> From: =?ks_c_5601-1987?B?wMyw5sjx?= To: Date: Tue, 27 Jun 2000 17:10:24 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01BFE05A.9577D440" 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-info-method-02.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 multi-part message in MIME format. ------=_NextPart_000_0023_01BFE05A.9577D440 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 aGkuDQoNCkluIDxUaGUgU0lQIElORk8gTWV0aG9kPiBEb2N1bWVudC4uLg0KIA0KUGFnZSAzDQoN CjEuMSBFeGFtcGxlIFVzZXMNCg0KLSBDYXJyeWluZyBpbWFnZXMgb3Igb3RoZXIgbm9uIHN0cmVh bWluZyBpbmZvcm1hdGlvbiBiZXR3ZWVuIHRoZSBwYXJ0aWNpcGF0bnRzIG9mIGEgc2Vzc2lvbi4N Cg0KDQpXaGF0IGlzICJpbWFnZSIgPw0KTWljcm9zb2Z0IE5ldG1lZXRpbmcncyBib2FyZCBzZW5k IGltYWdlIGZyb20gdXNlciB0byB1c2VyLg0KSXMgdGhhdCBzYW1lPz8NCk90aGVyd2lzZSwgd2hh dCBpcyAiaW1hZ2UiPw0KDQpOaWNlIGEgZGF5ISEhIQ0KDQo= ------=_NextPart_000_0023_01BFE05A.9577D440 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI2MTQuMzUwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48 Rk9OVCBzaXplPTI+DQo8RElWPjxGT05UIHNpemU9Mj5oaS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SW4gJmx0O1RoZSBTSVAgSU5GTyBNZXRob2Qm Z3Q7IERvY3VtZW50Li4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+UGFnZSAzPC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+MS4xIEV4YW1wbGUgVXNlczwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPi0gQ2FycnlpbmcgPEZPTlQgY29sb3I9IzgwMDAwMD48U1RS T05HPjxGT05UIA0KY29sb3I9I2ZmMDAwMD5pbWFnZXM8L0ZPTlQ+IDwvU1RST05HPjwvRk9OVD5v ciBvdGhlciBub24gc3RyZWFtaW5nIGluZm9ybWF0aW9uIA0KYmV0d2VlbiB0aGUgcGFydGljaXBh dG50cyBvZiBhIHNlc3Npb24uPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5XaGF0IGlzICJpbWFnZSIgPzwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPk1pY3Jvc29mdCBOZXRtZWV0aW5nJ3MgYm9hcmQgc2Vu ZCBpbWFnZSA8Rk9OVCBzaXplPTI+ZnJvbSB1c2VyIA0KdG8gdXNlci48L0ZPTlQ+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXMgdGhhdCZuYnNwO3NhbWU/PzwvRk9OVD48L0RJVj4N CjxESVY+T3RoZXJ3aXNlLCB3aGF0IGlzICJpbWFnZSI/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+TmljZSBhIGRheSEhISE8L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0023_01BFE05A.9577D440-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 27 08: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 IAA09255 for ; Tue, 27 Jun 2000 08:16: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 0554F44361; Tue, 27 Jun 2000 08:14:56 -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 A85CB44336 for ; Tue, 27 Jun 2000 08:14:53 -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 IAA02278; Tue, 27 Jun 2000 08:14:45 -0400 (EDT) Message-ID: <39589AB5.69683762@cs.columbia.edu> Date: Tue, 27 Jun 2000 08:14:45 -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: Shail Bhatnagar , Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@cisco.com> <3953BC06.59B9275E@dynamicsoft.com> <3953BD98.8545FFB9@cisco.com> <39579B64.BD7C4A04@dynamicsoft.com> <3957B290.F14A4BE8@cisco.com> <3957BB81.F3888271@dynamicsoft.com> <3957BE1F.5A892769@cs.columbia.edu> <3958238F.FD826DD9@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: > > Henning Schulzrinne wrote: > > > > But that would defeat the whole point of being able to figure out the > > downstream capabilities, returned in the 483. Thus, a proxy should *not* > > try to be too smart. After all, if IP routers did this, traceroute > > wouldn't work... > > I was assuming that the proxy wouldn't say anything useful in the 483. > If it does contain a Supported header, then yes, you are right. Sooo, > seems like in general it is NOT a good idea to drop the request with > Max-Forwards 1. > > -Jonathan R. > Another semi-interesting question is whether it is useful for any server that returns a final response to include a "Server" header. That way, one could find out which types of servers are along the path. (I suspect that some people are including this in the Via header comment, but even so, that information doesn't get back to the UAC.) -- 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 Jun 27 08:24: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 IAA09487 for ; Tue, 27 Jun 2000 08: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 2DB4844373; Tue, 27 Jun 2000 08:23:10 -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 A700F44336 for ; Tue, 27 Jun 2000 08:23:06 -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 IAA02614; Tue, 27 Jun 2000 08:23:03 -0400 (EDT) Message-ID: <39589CA7.9CF1F3E3@cs.columbia.edu> Date: Tue, 27 Jun 2000 08:23:03 -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: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies 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 Not to belabor the point, but please see RFC 1009 (Requirements for Internet Gateways), Section 4.8. Your statement about TTL appears to be at variance with the facts. (Not forwarding a packet with TTL 1 also wouldn't work since receiving a packet with TTL 0 is perfectly valid.) -- 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 Jun 27 09: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 JAA11379 for ; Tue, 27 Jun 2000 09: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 9E42244370; Tue, 27 Jun 2000 09:18: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 217C744336 for ; Tue, 27 Jun 2000 09:18:52 -0400 (EDT) Received: from dynamicsoft.com (1Cust205.tnt1.freehold.nj.da.uu.net [63.17.113.205]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA09134; Tue, 27 Jun 2000 09:20:01 -0400 (EDT) Message-ID: <3958AA1A.5E27C76D@dynamicsoft.com> Date: Tue, 27 Jun 2000 09:20:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?=C0=CC=B0=E6=C8=F1?= Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Question on draft-ietf-sip-info-method-02.txt References: <002601bfe00f$25f4e180$96496cd2@miptel.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 > ÀÌ°æÈñ wrote: > > hi. > > In Document... > > Page 3 > > 1.1 Example Uses > > - Carrying images or other non streaming information between the > participatnts of a session. > > > What is "image" ? > Microsoft Netmeeting's board send image from user to user. > Is that same?? > Otherwise, what is "image"? Any MIME type of type image/* whose purpose is to render on the recipients machine. -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 Jun 27 09:25: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 JAA11782 for ; Tue, 27 Jun 2000 09:25: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 43B784437B; Tue, 27 Jun 2000 09:24:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id CA9C34436B for ; Tue, 27 Jun 2000 09:24:42 -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.10.1/8.10.1/WIREfire-1.9) with ESMTP id e5RDOfs15895 for ; Tue, 27 Jun 2000 15:24:41 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Tue, 27 Jun 2000 15:24:41 +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) ; Tue, 27 Jun 2000 13:24:40 0000 (GMT) Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 27 Jun 2000 15:24:39 +0200 Message-ID: From: "Nils Appeldoorn (EMN)" To: "'sip@lists.bell-labs.com'" Date: Tue, 27 Jun 2000 15:24:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 27 Jun 2000 13:24:41.0059 (UTC) FILETIME=[0CB5B330:01BFE03B] Subject: [SIP] How do these programs work? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 everybody, I hope this is an approperiate mailinglist, please correct me if it's not. Thanks anyway. I'm doing some research on the current use of VoIP (voice and multimedia). I want to get the state of the art on VoIP applications that are available on the net. Now, I know there are a few applications available. I've seen Net2Phone, DialPad. But the problem is, I want to know what functionality these programs offer, where are they used for? And how do they work? Are they SIP or H.323 based? I can't look into the programs, maybe some of you know the answer? Can someone explain to me how these programs work? What's the principle behind these services? Thanks, Nils _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 27 09:44: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 JAA12322 for ; Tue, 27 Jun 2000 09:44: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 1D78244371; Tue, 27 Jun 2000 09:44: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 4D88D44336 for ; Tue, 27 Jun 2000 09:44:36 -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 JAA07528 for ; Tue, 27 Jun 2000 09:44:34 -0400 (EDT) Message-ID: <3958AFC1.C100DF5D@cs.columbia.edu> Date: Tue, 27 Jun 2000 09:44:33 -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] SIP bake-off technical program committee Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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'm looking for volunteers to assist with planning the technical aspects of the upcoming SIP bake-off, including interoperability scenarios, grouping of implementations, etc. -- 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 Jun 27 09:57: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 JAA12758 for ; Tue, 27 Jun 2000 09:57: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 CAF3C4438B; Tue, 27 Jun 2000 09:56:49 -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 8581F44370 for ; Tue, 27 Jun 2000 09:56:45 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id IAA27432; Tue, 27 Jun 2000 08:56:40 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id IAA28750; Tue, 27 Jun 2000 08:56:39 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA28908; Tue, 27 Jun 2000 08:56:39 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id IAA02779; Tue, 27 Jun 2000 08:56:38 -0500 (CDT) Message-Id: <200006271356.IAA02779@b04a24.exu.ericsson.se> Subject: Re: [SIP] Static Images To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Tue, 27 Jun 2000 08:56:38 -0500 (CDT) Cc: rfairlie@nuera.com (Fairlie-Cuninghame Robert), hgs@cs.columbia.edu ('Henning Schulzrinne'), sip@lists.bell-labs.com In-Reply-To: <39579559.71A27F7B@dynamicsoft.com> from "Jonathan Rosenberg" at Jun 26, 2000 01:39:37 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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: >"Adam B. Roach" wrote: >> >> >Agree; sounds like a parameter: >> > >> >Display-Info: http://www.example.com/picture;purpose=picture, >> > http://www.example.com/hello.au;purpose=speakname >> > >> >We would need to define some basic purpose values, and then define a >> >procedure for specifying new ones with IANA. >> >> I'm with Henning on this one: your values seem to imply a certain >> type of *rendering*, not a certain type of information -- and, >> in HTTP at least, it's the client's responsiblity to render the >> content type fetched in a appropriate form. > >No, they don't imply any kind of mandated behavior. I was trying to >address a concern raised previously on the list, which was that just the >MIME type wasn't enough. Is this image a thumbnail of the caller? Is it >a picture of a phone for a "graphical custom ringing" or something? The >idea with this purpose thing was just a hint to indicate the purpose of >the content, so that the device could do with it something reasonable, >as it saw fit. I propose, then, that the purpose for *both* of your URIs is the same: caller identification. I beleive the distinction you're trying to make would be better illustrated by, for example, the difference between a spoken name to identify the caller and a custom alerting tone provided (or, more appropriately, suggested) by the caller. The callee's device may then choose to present this content appropriately. Display-Info: http://www.example.com/picture;purpose=callerid, http://www.example.com/hello.au;purpose=callerid, http://www.example.com/chimes.au;purpose=alerting -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jun 27 10:04: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 KAA12956 for ; Tue, 27 Jun 2000 10:04: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 AEE4844394; Tue, 27 Jun 2000 10:02: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 CA09244336 for ; Tue, 27 Jun 2000 10:02:25 -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 KAA08626; Tue, 27 Jun 2000 10:02:21 -0400 (EDT) Message-ID: <3958B3ED.75C26A89@cs.columbia.edu> Date: Tue, 27 Jun 2000 10:02:21 -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: "Adam B. Roach" Cc: Jonathan Rosenberg , Fairlie-Cuninghame Robert , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006271356.IAA02779@b04a24.exu.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 "Adam B. Roach" wrote: > > Jonathan Rosenberg writes: > >"Adam B. Roach" wrote: > >> > >> >Agree; sounds like a parameter: > >> > > >> >Display-Info: http://www.example.com/picture;purpose=picture, > >> > http://www.example.com/hello.au;purpose=speakname > >> > > >> >We would need to define some basic purpose values, and then define a > >> >procedure for specifying new ones with IANA. > >> > >> I'm with Henning on this one: your values seem to imply a certain > >> type of *rendering*, not a certain type of information -- and, > >> in HTTP at least, it's the client's responsiblity to render the > >> content type fetched in a appropriate form. > > > >No, they don't imply any kind of mandated behavior. I was trying to > >address a concern raised previously on the list, which was that just the > >MIME type wasn't enough. Is this image a thumbnail of the caller? Is it > >a picture of a phone for a "graphical custom ringing" or something? The > >idea with this purpose thing was just a hint to indicate the purpose of > >the content, so that the device could do with it something reasonable, > >as it saw fit. > > I propose, then, that the purpose for *both* of your URIs > is the same: caller identification. I beleive the distinction you're > trying to make would be better illustrated by, for example, the > difference between a spoken name to identify the caller and > a custom alerting tone provided (or, more appropriately, suggested) > by the caller. The callee's device may then choose to present this > content appropriately. > > Display-Info: http://www.example.com/picture;purpose=callerid, > http://www.example.com/hello.au;purpose=callerid, > http://www.example.com/chimes.au;purpose=alerting > Given that we don't have to pay taxes for headers, and given that the number of purposes suggested so far is small, why all these parameters? Using, for example, To-Info: From-Info: Alert: is much shorter and it's much easier to tell what's going on. If we go the parameter route, I'd suggest being more consistent and rewriting SIP as Protocol-Info: some-url;purpose=to-address Protocol-Info: some-other-url;purpose=from-address Protocol-Info: 1234 INVITE;purpose=sequence-number Protocol-Info: INVITE;purpose=method :-) -- 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 Jun 27 14:24: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 OAA20548 for ; Tue, 27 Jun 2000 14:24: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 B0A5F4436C; Tue, 27 Jun 2000 14:24:11 -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 D5F3644336 for ; Tue, 27 Jun 2000 14:24:06 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nok.ntc.nokia.com [131.228.10.151]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id VAA12249 for ; Tue, 27 Jun 2000 21:24:04 +0300 (EETDST) From: Poornima.Lalwaney@nokia.com Received: from daebh01nok.americas.nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 27 Jun 2000 21:24:03 +0300 Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 27 Jun 2000 13:21:58 -0500 Message-ID: To: lars@intertex.se, Poornima.Lalwaney@nokia.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Distributing call state : draft-dcsgroup-sip-state-01.t xt Date: Tue, 27 Jun 2000 13:24:00 -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 Lars, Thanks for your comments. > 1. The extension does not define an option-tag to be used > with the Require > and Supported header fields. How would a proxy know that the > UAC or UAS > support the 'state' extension? > I agree that we need a Requires: header so the proxy can depend on the UAC/UAS storing the state headers and returning them. Perhaps Requires: State (or any other name besides "dcs" which is being proposed for proxy to proxy signaling extensions) would work. I will update the draft to include a discussion on Requires and Supports with an option-tag. > 2. Section 4.2 mentions that the state header is included in > subsequent > INVITEs. What about BYE requests? I think it could be useful > to include it > in BYEs also, since BYEs certainly affects call state. > As currently used in DCS, the state header includes information that is relevant to proxies only in subsequent INVITE's that go through proxies (i.e. INVITE's that affect mid call "resource" or "authorization" changes). As you correctly point out, in a general model if the state information sent by the proxy to the client is required by the proxy at call termination, and if the BYE goes through proxies, the state header can be sent back in a BYE. The updated draft will include some discussion on the general case. Thanks.. Poornima Lalwaney > On Fri, 23 Jun 2000 Poornima.Lalwaney@nokia.com wrote: > > > > The draft draft-dcsgroup-sip-state-01.txt was presented in > Adelaide. In > > brief, the draft discusses the "State" header extension > that may be used to > > transfer call state from the proxy to the UAC. The proxy can then be > > stateless for the duration of the call. The state is stored at the > > UAC/endpoint for the duration of the call and passed back > to the proxy if > > mid-call changes are required. The draft also includes > rules at endpoints > > and proxies on inclusion and processing of State headers. > Comments and > > suggestions on the State header extension as presented in > draft-01 are > > welcome. (this is available at > > > http://search.ietf.org/internet-drafts/draft-dcsgroup-sip-stat e-01.txt ). > > I am in the process of updating the draft and submitting it as > draft-dcsgroup-sip-state-02.txt before the Pittsburgh IETF. The dcsgroup has > cleared the RFC2026 issues and the updated draft will reflect that and > comments received on this list on the proposed State header extension and > associated rules. > > > Thanks and regards, > Poornima Lalwaney > > > > ------------------------------------------------ > Poornima Lalwaney > Nokia > poornima.lalwaney@nokia.com > Tel: +1 858-831-4727 > ----------------------------------------------- > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ 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 Jun 27 18:03: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 SAA25745 for ; Tue, 27 Jun 2000 18:03: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 29BDB4436C; Tue, 27 Jun 2000 18:03:01 -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 5136044336 for ; Tue, 27 Jun 2000 18:02:57 -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 PAA22164; Tue, 27 Jun 2000 15:02:49 -0700 (PDT) Message-Id: <4.1.20000627150221.009f5100@diablo.cisco.com> Message-Id: <4.1.20000627150221.009f5100@diablo.cisco.com> X-Sender: jmpolk@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 27 Jun 2000 15:03:23 -0500 To: "Fox, Mike" , Jonathan Rosenberg , IMPP WG From: "James M. Polk" Cc: sip , rem-conf@es.net, "iptel, list" In-Reply-To: <613A6A6A3F09D3118F5C00508B2C24FE7F35E6@sd_exchange.nuera.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1302240==_.ALT" Subject: [SIP] RE: proposal for IMPP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --=====================_1302240==_.ALT Content-Type: text/plain; charset="us-ascii" Mike How long did it take you to think of this acronym? If less than an hour -- you need a life, man! ;-) cheers At 03:18 PM 6/15/2000 -0700, Fox, Mike wrote: >Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol >may be the right way. Call it SIP Control by Unified Methods. > >SOAP SCUM > > >Best regards, >Mike Fox > > ************************************* "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 --=====================_1302240==_.ALT Content-Type: text/html; charset="us-ascii"
Mike

How long did it take you to think of this acronym? If less than an hour -- you need a life, man!

;-)

cheers

At 03:18 PM 6/15/2000 -0700, Fox, Mike wrote:
>Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol
>may be the right way. Call it SIP Control by Unified Methods.
>
>SOAP SCUM
>
>
>Best regards,
>Mike Fox
>
>
*************************************
"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 --=====================_1302240==_.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 Jun 27 21: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 VAA28621 for ; Tue, 27 Jun 2000 21:40: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 5A72B4437D; Tue, 27 Jun 2000 21:40:09 -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 E971944336 for ; Tue, 27 Jun 2000 21:40:04 -0400 (EDT) Received: from dynamicsoft.com (1Cust205.tnt1.freehold.nj.da.uu.net [63.17.113.205]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA15022; Tue, 27 Jun 2000 21:41:15 -0400 (EDT) Message-ID: <395957D0.42D76A4F@dynamicsoft.com> Date: Tue, 27 Jun 2000 21:41:36 -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: "Adam B. Roach" , Fairlie-Cuninghame Robert , sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006271356.IAA02779@b04a24.exu.ericsson.se> <3958B3ED.75C26A89@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: > > > >No, they don't imply any kind of mandated behavior. I was trying to > > >address a concern raised previously on the list, which was that just the > > >MIME type wasn't enough. Is this image a thumbnail of the caller? Is it > > >a picture of a phone for a "graphical custom ringing" or something? The > > >idea with this purpose thing was just a hint to indicate the purpose of > > >the content, so that the device could do with it something reasonable, > > >as it saw fit. > > > > I propose, then, that the purpose for *both* of your URIs > > is the same: caller identification. I beleive the distinction you're > > trying to make would be better illustrated by, for example, the > > difference between a spoken name to identify the caller and > > a custom alerting tone provided (or, more appropriately, suggested) > > by the caller. The callee's device may then choose to present this > > content appropriately. > > > > Display-Info: http://www.example.com/picture;purpose=callerid, > > http://www.example.com/hello.au;purpose=callerid, > > http://www.example.com/chimes.au;purpose=alerting > > > > Given that we don't have to pay taxes for headers, and given that the > number of purposes suggested so far is small, why all these parameters? > > Using, for example, > > To-Info: > From-Info: > Alert: The difference is that with a single header, if you don't understand the parameter that gives a "hint" on what its for, you still know to display it. If you use a separate header for each "hint", then as we come up with new purposes, they won't be handled at all by older UAs. In general, parameters make sense when they further qualify the semantics implied by the header. I think this is the case here. The header says "render this". The parameter provides an application layer hint, which may be ignored, saying for what purpose this should be rendered. -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 Jun 28 02:14: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 CAA16063 for ; Wed, 28 Jun 2000 02:14: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 8148C44382; Wed, 28 Jun 2000 02:13:59 -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 12C6B44336 for ; Wed, 28 Jun 2000 02:13:55 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Jun 2000 23:14:35 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Max-Forwards + Proxies Date: Tue, 27 Jun 2000 23:14:32 -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 got this from Stevens, TCP/IP Illustrated Vol. 1 chapter on Traceroute. It is normally a fairly good source. I read RFC1009 and it also says that you should never receive a packet with TTL 0 (cf. Section 4.8). Likewise, RFC1122(Host Requirements) states "A host MUST NOT discard a datagram just because it was received with TTL less than 2. .... The intent is that TTL expiration will cause a datagram to be discarded by a gateway but not by the destination host; however, hosts that act as gateways by forwarding datagrams must follow the gateway rules for TTL. So I am unsure as to what is in dispute here. Anyway this is getting fairly offtopic and so we should probably take the discussion offline. Regards, Robert. -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Tuesday, June 27, 2000 8:23 PM To: Fairlie-Cuninghame, Robert Cc: Jonathan Rosenberg; sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies Not to belabor the point, but please see RFC 1009 (Requirements for Internet Gateways), Section 4.8. Your statement about TTL appears to be at variance with the facts. (Not forwarding a packet with TTL 1 also wouldn't work since receiving a packet with TTL 0 is perfectly valid.) -- 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 Jun 28 06:49: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 GAA17923 for ; Wed, 28 Jun 2000 06:49: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 815124434A; Wed, 28 Jun 2000 06:48:35 -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 CF4B144336 for ; Wed, 28 Jun 2000 06:48:31 -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 GAA17811; Wed, 28 Jun 2000 06:48:30 -0400 (EDT) Message-Id: <200006281048.GAA17811@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com, confctr@isi.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Wed, 28 Jun 2000 06:48:30 -0400 Subject: [SIP] I-D ACTION:draft-camarillo-sip-sdp-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SDP media alignment in SIP Author(s) : G. Camarillo, J. Holler, G. Eriksson Filename : draft-camarillo-sip-sdp-00.txt Pages : 7 Date : 27-Jun-00 This document defines an SDP media attribute. This attribute is intended to be used in conjunction with SIP in order to align different media streams belonging to a session. The use of this attribute allows sending media from a single media stream, encoded in different formats during the session, to different ports and host interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sip-sdp-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-camarillo-sip-sdp-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-camarillo-sip-sdp-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: <20000627104835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sip-sdp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sip-sdp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000627104835.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 Wed Jun 28 10:56: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 KAA24822 for ; Wed, 28 Jun 2000 10:56: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 5D7B14434A; Wed, 28 Jun 2000 10:56: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 A47F644336 for ; Wed, 28 Jun 2000 10:56:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jun 28 10:54:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C4F3044348; Wed, 28 Jun 2000 10:41:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id A14E644347 for ; Wed, 28 Jun 2000 10:41:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DBB9852C4; Wed, 28 Jun 2000 10:41:10 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 2C1AD52B6 for ; Wed, 28 Jun 2000 10:41:08 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Jun 28 10:40:32 EDT 2000 Received: from mail.sedonanetworks.com ([64.26.140.3]) by dusty; Wed Jun 28 10:40:32 EDT 2000 Received: by mail.sedonanetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Jun 2000 10:40:04 -0400 Message-ID: <81BAD602267CD3119016009027747F6740E00F@mail.sedonanetworks.com> From: Elizabeth George To: "'sip@lists.research.bell-labs.com'" Date: Wed, 28 Jun 2000 10:40:04 -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 server by mci Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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 anybody know of a Sip Server by MCI WorldCom which i can talk to Thanks EG _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 28 11:26: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 LAA25464 for ; Wed, 28 Jun 2000 11:26: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 57F2F4436E; Wed, 28 Jun 2000 11:26:07 -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 C415344336 for ; Wed, 28 Jun 2000 11:26:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jun 28 11:24:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2E19544348; Wed, 28 Jun 2000 11:11:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 0F17044347 for ; Wed, 28 Jun 2000 11:11:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3703D52C4; Wed, 28 Jun 2000 11:11:12 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5044E52B6 for ; Wed, 28 Jun 2000 11:11:09 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jun 28 11:09:26 EDT 2000 Received: from ubiquity.net ([194.128.96.72]) by dusty; Wed Jun 28 11:09:23 EDT 2000 Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA11473; Wed, 28 Jun 2000 16:07:02 +0100 (BST) Message-ID: <395A1496.E69FF0A8@ubiquity.net> Date: Wed, 28 Jun 2000 16:07:02 +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: Elizabeth George Cc: "'sip@lists.research.bell-labs.com'" Subject: Re: [SIP] SIP server by mci References: <81BAD602267CD3119016009027747F6740E00F@mail.sedonanetworks.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 Elizabeth George wrote: > > Does anybody know of a Sip Server by MCI WorldCom which i can talk to > > Thanks > EG Not an MCI one specifically but there is a list of public SIP Servers here ... http://www.cs.columbia.edu/%7Ehgs/sip/servers.html There is also a new public SIP Server not yet listed on that page at http://www.sipcenter.com (you can actually reach it at sip.sipcenter.com port 5060) but I would check the web site for related info first. 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 Wed Jun 28 11:27: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 LAA25501 for ; Wed, 28 Jun 2000 11:27: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 5FBD444379; Wed, 28 Jun 2000 11:26:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from oss.oss.com (oss.com [207.207.205.89]) by lists.bell-labs.com (Postfix) with SMTP id 1735144377 for ; Wed, 28 Jun 2000 11:26:54 -0400 (EDT) Received: from Neptune (neptune.oss.com) by oss.oss.com ; 28 JUN 100 11:26:49 EDT Message-ID: <008f01bfe115$23769500$2001a8c0@oss.com> From: "Zipora Hartov" To: Date: Wed, 28 Jun 2000 11:25:49 -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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] New book Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 English version of Mr. Olivier Dubuisson's book "ASN.1 - Communication between heterogeneous systems" is now available as a free download in pdf format from: http://www.oss.com/asn1/booksintro.html Zipora Hartov _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jun 28 20:23: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 UAA06742 for ; Wed, 28 Jun 2000 20:23: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 F16DB44356; Wed, 28 Jun 2000 20:22:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from paleale.cisco.com (paleale.cisco.com [171.71.154.60]) by lists.bell-labs.com (Postfix) with ESMTP id 9EB2244336 for ; Wed, 28 Jun 2000 20:22:51 -0400 (EDT) Received: from orannt (oran-nt.cisco.com [171.69.210.7]) by paleale.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id RAA22820; Wed, 28 Jun 2000 17:22:16 -0700 (PDT) Message-ID: <0cab01bfe160$7e2817d0$07d245ab@cisco.com> From: "David R. Oran" To: "Henning Schulzrinne" , "Adam B. Roach" Cc: "Jonathan Rosenberg" , "Fairlie-Cuninghame Robert" , References: <200006271356.IAA02779@b04a24.exu.ericsson.se> <3958B3ED.75C26A89@cs.columbia.edu> Subject: Re: [SIP] Static Images Date: Wed, 28 Jun 2000 20:25:12 -0400 Organization: Cisco Systems 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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's reductio ad absurdum really drove this home for me. If we want to do something that needs a header, just invent a header. We could go even further than Henning suggests and just cast SIP as a single Lamba function in Common Lisp. Or better still, use my favorite one-instruction programming language: DWIM(arg1,arg2...) where DWIM = "Do what I mean". Dave. > > I propose, then, that the purpose for *both* of your URIs > > is the same: caller identification. I beleive the distinction you're > > trying to make would be better illustrated by, for example, the > > difference between a spoken name to identify the caller and > > a custom alerting tone provided (or, more appropriately, suggested) > > by the caller. The callee's device may then choose to present this > > content appropriately. > > > > Display-Info: http://www.example.com/picture;purpose=callerid, > > http://www.example.com/hello.au;purpose=callerid, > > http://www.example.com/chimes.au;purpose=alerting > > > > Given that we don't have to pay taxes for headers, and given that the > number of purposes suggested so far is small, why all these parameters? > > Using, for example, > > To-Info: > From-Info: > Alert: > > is much shorter and it's much easier to tell what's going on. If we go > the parameter route, I'd suggest being more consistent and rewriting SIP > as > > Protocol-Info: some-url;purpose=to-address > Protocol-Info: some-other-url;purpose=from-address > Protocol-Info: 1234 INVITE;purpose=sequence-number > Protocol-Info: INVITE;purpose=method > > :-) > -- > 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 Jun 29 06:06: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 GAA24954 for ; Thu, 29 Jun 2000 06:06: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 E07DC44354; Thu, 29 Jun 2000 06:06:13 -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 19DCF44336 for ; Thu, 29 Jun 2000 06:06:10 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 03:06:54 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'David R. Oran'" , Henning Schulzrinne , "Adam B. Roach" Cc: Jonathan Rosenberg , "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: RE: [SIP] Static Images Date: Thu, 29 Jun 2000 03:06:52 -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 However Dave, although Display-Info could be done using multiple headers (anything is possible), I don't believe this would be helpful. The parsing is much more difficult and order is now important for multiple headers. Adding purpose-specific parameters is IMO option a lot simpler and more localized than adding new headers. Come on, would you prefer Display-Info: http:blah Display-Purpose: picture Display-Info: http:blah2 Display-Purpose: picture Display-Info: http:blah3 Display-Purpose: myagent Display-Other: whatever Display-Info: inline:25487852 Display-Purpose: aboutme or Display-Info: http:blah;purpose=picture Display-Info: http:blah2;purpose=picture Display-Info: http:blah;purpose=myagent;other=whatever Display-Info: inline:25487852;purpose=aboutme [or just comma separate them] This is a very flexible & powerful feature and like anything that is very flexible you want to make sure that flexibility does not turn into widespread chaos - where there are a zillion SIP headers defined. Using only only header a) abstracts/prevents the Display-Info flexibility from cluttering the core SIP functionality and parsing. b) localizes future extensions (the scope of any future parameter is limited to that purpose type and not to ALL SIP processing!!) c) removes the need correlate all the Display-* headers. Each header is self-contained and order is unimportant. All Display info can be found in one place - your Walmart of Display content. Henning, so when are we going to see the new SIP draft with your syntax proposal? Cheers, Robert. -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Thursday, June 29, 2000 8:25 AM To: Henning Schulzrinne; Adam B. Roach Cc: Jonathan Rosenberg; Fairlie-Cuninghame Robert; sip@lists.bell-labs.com Subject: Re: [SIP] Static Images Henning's reductio ad absurdum really drove this home for me. If we want to do something that needs a header, just invent a header. We could go even further than Henning suggests and just cast SIP as a single Lamba function in Common Lisp. Or better still, use my favorite one-instruction programming language: DWIM(arg1,arg2...) where DWIM = "Do what I mean". Dave. > > I propose, then, that the purpose for *both* of your URIs > > is the same: caller identification. I beleive the distinction you're > > trying to make would be better illustrated by, for example, the > > difference between a spoken name to identify the caller and > > a custom alerting tone provided (or, more appropriately, suggested) > > by the caller. The callee's device may then choose to present this > > content appropriately. > > > > Display-Info: http://www.example.com/picture;purpose=callerid, > > http://www.example.com/hello.au;purpose=callerid, > > http://www.example.com/chimes.au;purpose=alerting > > > > Given that we don't have to pay taxes for headers, and given that the > number of purposes suggested so far is small, why all these parameters? > > Using, for example, > > To-Info: > From-Info: > Alert: > > is much shorter and it's much easier to tell what's going on. If we go > the parameter route, I'd suggest being more consistent and rewriting SIP > as > > Protocol-Info: some-url;purpose=to-address > Protocol-Info: some-other-url;purpose=from-address > Protocol-Info: 1234 INVITE;purpose=sequence-number > Protocol-Info: INVITE;purpose=method > > :-) > -- > 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 29 08:04: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 IAA27545 for ; Thu, 29 Jun 2000 08: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 CFDD144363; Thu, 29 Jun 2000 08:04:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from paleale.cisco.com (paleale.cisco.com [171.71.154.60]) by lists.bell-labs.com (Postfix) with ESMTP id 2957D44336 for ; Thu, 29 Jun 2000 08:04:22 -0400 (EDT) Received: from orannt (oran-nt.cisco.com [171.69.210.7]) by paleale.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id FAA10016; Thu, 29 Jun 2000 05:03:45 -0700 (PDT) Message-ID: <0cfa01bfe1c2$7dd02040$07d245ab@cisco.com> From: "David R. Oran" To: "Fairlie-Cuninghame, Robert" , "Henning Schulzrinne" , "Adam B. Roach" Cc: "Jonathan Rosenberg" , "Fairlie-Cuninghame, Robert" , References: Subject: Re: [SIP] Static Images Date: Thu, 29 Jun 2000 08:06:42 -0400 Organization: Cisco Systems 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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, perhaps you missed my point amidst the humor element. I was advocating that the information actually be semantically tagged by the name of the header so we don't have so much overloading and an extra identifier space to manage. The tag method introduces a whole new identifier space with its own semantics for the UA to understand, when the header would work just fine. As Henning and others have ponted out, the rendering method (picture, audio, video, smell, etc.) should be deduced by the UA from the content of the URL when it's accessed rather than via URI names or purpose tags. So, in my view, if you wanted a something to be presented to the user during alerting, we'd have headers like: Alerting-Info: http://doggie-heaven.aol.com/~mydogskip/mug.jpg Alerting-Info: ftp://doggie-heaven.aol.com/~mydogskip/woof-woof.mp3 Alerting-Info: rtsp://doggie-heaven.aol.com/~mydogskip/phew-phew.sml From-Info: http://doggie-heaven.aol.com/~mydogskip/skip.vcf Depending on what the UA was capable of and the UA owner's preferences, during alerting it could do one or more of: a) display the picture of Skip b) play Skip barking as the alerting sound c) emit chemicals to simulate a very muddy unwashed skip walking into the room. and make available via some UI function Skip's vCard information to allow it to be added to an address book, or whatever. This making more sense? Dave. ----- Original Message ----- From: "Fairlie-Cuninghame, Robert" To: "'David R. Oran'" ; "Henning Schulzrinne" ; "Adam B. Roach" Cc: "Jonathan Rosenberg" ; "Fairlie-Cuninghame, Robert" ; Sent: Thursday, June 29, 2000 6:06 AM Subject: RE: [SIP] Static Images > However Dave, although Display-Info could be done using multiple headers > (anything is possible), I don't believe this would be helpful. The parsing > is much more difficult and order is now important for multiple headers. > Adding purpose-specific parameters is IMO option a lot simpler and more > localized than adding new headers. > > Come on, would you prefer > > Display-Info: http:blah > Display-Purpose: picture > Display-Info: http:blah2 > Display-Purpose: picture > Display-Info: http:blah3 > Display-Purpose: myagent > Display-Other: whatever > Display-Info: inline:25487852 > Display-Purpose: aboutme > > or > > Display-Info: http:blah;purpose=picture > Display-Info: http:blah2;purpose=picture > Display-Info: http:blah;purpose=myagent;other=whatever > Display-Info: inline:25487852;purpose=aboutme > [or just comma separate them] > > This is a very flexible & powerful feature and like anything that is very > flexible you want to make sure that flexibility does not turn into > widespread chaos - where there are a zillion SIP headers defined. Using only > only header > a) abstracts/prevents the Display-Info flexibility from cluttering the core > SIP functionality and parsing. > b) localizes future extensions (the scope of any future parameter is limited > to that purpose type and not to ALL SIP processing!!) > c) removes the need correlate all the Display-* headers. Each header is > self-contained and order is unimportant. All Display info can be found in > one place - your Walmart of Display content. > > Henning, so when are we going to see the new SIP draft with your syntax > proposal? > > Cheers, > > Robert. > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Thursday, June 29, 2000 8:25 AM > To: Henning Schulzrinne; Adam B. Roach > Cc: Jonathan Rosenberg; Fairlie-Cuninghame Robert; > sip@lists.bell-labs.com > Subject: Re: [SIP] Static Images > > > Henning's reductio ad absurdum really drove this home for me. If we want to > do something that needs a header, just invent a header. > > We could go even further than Henning suggests and just cast SIP as a single > Lamba function in Common Lisp. Or better still, use my favorite > one-instruction programming language: > > DWIM(arg1,arg2...) > > where DWIM = "Do what I mean". > > Dave. > > > > I propose, then, that the purpose for *both* of your URIs > > > is the same: caller identification. I beleive the distinction you're > > > trying to make would be better illustrated by, for example, the > > > difference between a spoken name to identify the caller and > > > a custom alerting tone provided (or, more appropriately, suggested) > > > by the caller. The callee's device may then choose to present this > > > content appropriately. > > > > > > Display-Info: http://www.example.com/picture;purpose=callerid, > > > http://www.example.com/hello.au;purpose=callerid, > > > http://www.example.com/chimes.au;purpose=alerting > > > > > > > Given that we don't have to pay taxes for headers, and given that the > > number of purposes suggested so far is small, why all these parameters? > > > > Using, for example, > > > > To-Info: > > From-Info: > > Alert: > > > > is much shorter and it's much easier to tell what's going on. If we go > > the parameter route, I'd suggest being more consistent and rewriting SIP > > as > > > > Protocol-Info: some-url;purpose=to-address > > Protocol-Info: some-other-url;purpose=from-address > > Protocol-Info: 1234 INVITE;purpose=sequence-number > > Protocol-Info: INVITE;purpose=method > > > > :-) > > -- > > 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 > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 29 08: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 IAA28914 for ; Thu, 29 Jun 2000 08: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 64EAE44354; Thu, 29 Jun 2000 08:43:25 -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 5697644336 for ; Thu, 29 Jun 2000 08:43:22 -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 HAA24676; Thu, 29 Jun 2000 07:43:17 -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 HAA18044; Thu, 29 Jun 2000 07:43:17 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id HAA11517; Thu, 29 Jun 2000 07:43:16 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id HAA08045; Thu, 29 Jun 2000 07:43:16 -0500 (CDT) Message-Id: <200006291243.HAA08045@b04a24.exu.ericsson.se> Subject: Re: [SIP] Static Images To: oran@cisco.com (David R. Oran) Date: Thu, 29 Jun 2000 07:43:16 -0500 (CDT) Cc: rfairlie@nuera.com (Fairlie-Cuninghame Robert), schulzrinne@cs.columbia.edu (Henning Schulzrinne), jdrosen@dynamicsoft.com (Jonathan Rosenberg), sip@lists.bell-labs.com In-Reply-To: <0cfa01bfe1c2$7dd02040$07d245ab@cisco.com> from "David R. Oran" at Jun 29, 2000 08:06:42 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 >So, in my view, if you wanted a something to be presented to the user during >alerting, we'd have headers like: >Alerting-Info: http://doggie-heaven.aol.com/~mydogskip/mug.jpg >Alerting-Info: ftp://doggie-heaven.aol.com/~mydogskip/woof-woof.mp3 >Alerting-Info: rtsp://doggie-heaven.aol.com/~mydogskip/phew-phew.sml >From-Info: http://doggie-heaven.aol.com/~mydogskip/skip.vcf > >Depending on what the UA was capable of and the UA owner's preferences, >during alerting it could do one or more of: >a) display the picture of Skip >b) play Skip barking as the alerting sound >c) emit chemicals to simulate a very muddy unwashed skip walking into the >room. > >and make available via some UI function Skip's vCard information to allow it >to be added to an address book, or whatever. I think the point that Jonathan is trying to make (and one with which I agree) is that, for example, if you define a future extension for some other semantics than "alerting" or "from," new *headers* are suboptimal. Henning's argument holds *only* if the header itself has no associated semantics. In this case, it isn't true. "Display-Info" conveys the concept that "this is additional content to be rendered for the user." The purpose parameters are merely giving hints as to how this information would most effectively be conveyed. I'll demonstrate this point. Sprog-Info: http://www.xyz.com/image.jpg If your client didn't understand this new header type of "Sprog-Info," it would be ignored. Display-Info: http://www.xyz.com/image.jpg;purpose=sprog On the other hand, a client which understood the general "Display-Info" header, but had no idea what this new "sprog" thing was would have a much better recovery. It could either present the image (possibly in a box labeled "sprog"), or at least let the user know: "I have an image here labeled 'sprog.' Do you want to see it?") I see the second set of behavior as far preferable. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 29 11: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 LAA11945 for ; Thu, 29 Jun 2000 11:49: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 2C3254436C; Thu, 29 Jun 2000 11:48:47 -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 836EB44336 for ; Thu, 29 Jun 2000 11:48:43 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 29 Jun 2000 07:19:11 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 07:17:28 -0500 Message-ID: From: "Jean Jervis" To: IETF SIP Subject: [SIP] RFC 2543bis - SDP Compliance, ABNF Date: Thu, 29 Jun 2000 07:17:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE1C3.FCCAB59E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@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_01BFE1C3.FCCAB59E Content-Type: text/plain; charset="windows-1252" Here are some comments on the SIP RFC2543bis Draft. 1. Section 16.8 OPTIONS Request. The example SDP here does not have a c= line. I believe it needs one, either at the session level or as part of each media description in order to be compliant with the SDP spec. 2. Appendix B.7 Subject and SDP "s=" Line. This section indicates that the s= line may be left empty for invitations to two-party sessions. This is not compliant with the grammar in the SDP RFC (Appendix A) which requires at least one character in the session name (which may be a blank). 3. Appendix B.8 SDP "o=" Line. I had trouble with the wording "not strictly necessary". Does this mean that the o= line is not always required or that it is always required, but sometimes not very useful? Wouldn't it be best to always be compliant with the SDP RFC, and just require that it be present? 4. Appendix C Summary of Augmented BNF. The *rule description seems to have a problem with the < and > characters in , etc. I see upside down ! and ? (Spanish punctuation marks?). Don't know if this is just occurring at my end or there is actually a problem with the document source. My apologies if I have misunderstood any of these points. Regards, Jean Jervis Nortel Networks ------_=_NextPart_001_01BFE1C3.FCCAB59E Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable [SIP] RFC 2543bis - SDP Compliance, ABNF

Here are some comments on the SIP = RFC2543bis Draft.

1. Section 16.8 OPTIONS Request. The = example SDP here does not have a c=3D line. I believe it needs one, = either at the session level or as part of each media description in = order to be compliant with the SDP spec.

2. Appendix B.7 Subject and SDP = "s=3D" Line. This section indicates that the s=3D line may be = left empty for invitations to two-party sessions. This is not compliant = with the grammar in the SDP RFC (Appendix A) which requires at least = one character in the session name (which may be a blank).

3. Appendix B.8 SDP "o=3D" = Line. I had trouble with the wording "not strictly = necessary". Does this mean that the o=3D line is not always = required or that it is always required, but sometimes not very useful? = Wouldn't it be best to always be compliant with the SDP RFC, and just = require that it be present?

4. Appendix C Summary of Augmented = BNF. The *rule description seems to have  a problem with the < = and > characters in <n>, etc. I see upside down ! and ? = (Spanish punctuation marks?). Don't know if this is just occurring at = my end or there is actually a problem with the document = source.

My apologies if I have misunderstood = any of these points.

Regards,
Jean Jervis
Nortel Networks

------_=_NextPart_001_01BFE1C3.FCCAB59E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 29 12:11: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 MAA13257 for ; Thu, 29 Jun 2000 12:11: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 168D74434F; Thu, 29 Jun 2000 12:11:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from oss.oss.com (oss.com [207.207.205.89]) by lists.bell-labs.com (Postfix) with SMTP id 6560244336 for ; Thu, 29 Jun 2000 12:11:39 -0400 (EDT) Received: from Neptune (neptune.oss.com) by oss.oss.com ; 29 JUN 100 12:11:36 EDT Message-ID: <00dd01bfe1e4$8ec484a0$2001a8c0@oss.com> From: "Zipora Hartov" To: Date: Thu, 29 Jun 2000 12:10:35 -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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] New ASN.1 Syntax Checker Version Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.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 anyone needs an ASN.1 Syntax Checker, or wants to update theirs, Version 5.2 of the OSS ASN.1 Syntax Checker is available as a free download from: http://www.nokalva.com/products/checksyntax.html Zipora Hartov _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 29 12:15: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 MAA13345 for ; Thu, 29 Jun 2000 12:15: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 CAE8C4437B; Thu, 29 Jun 2000 12:14:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by lists.bell-labs.com (Postfix) with ESMTP id 2D63344377 for ; Thu, 29 Jun 2000 12:14:06 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id LAA26236; Thu, 29 Jun 2000 11:13:59 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA01837; Thu, 29 Jun 2000 11:13:58 -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 LAA23742; Thu, 29 Jun 2000 11:13:58 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id LAA10402; Thu, 29 Jun 2000 11:13:57 -0500 (CDT) Date: Thu, 29 Jun 2000 11:13:57 -0500 (CDT) Message-Id: <200006291613.LAA10402@b04a45.exu.ericsson.se> To: sip@lists.bell-labs.com, zipora@oss.com Subject: Re: [SIP] New ASN.1 Syntax Checker Version 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 X-BeenThere: sip@lists.bell-labs.com > If anyone needs an ASN.1 Syntax Checker, or wants to update theirs, Version > 5.2 of the OSS ASN.1 Syntax Checker is available as a free download from: > http://www.nokalva.com/products/checksyntax.html > > Zipora Hartov > Interesting, but I hope to never have to use ASN.1 with SIP :) sean > _______________________________________________ > 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 Jun 29 12:34: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 MAA14000 for ; Thu, 29 Jun 2000 12:34: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 AD5014436E; Thu, 29 Jun 2000 12:34: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 41D7044336 for ; Thu, 29 Jun 2000 12:34:19 -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 JAA14754; Thu, 29 Jun 2000 09:34:30 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAA95987; Thu, 29 Jun 2000 09:30:57 -0700 (PDT) Message-Id: <4.2.0.58.20000629091909.00dc1490@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 29 Jun 2000 09:33:31 -0700 To: "Adam B. Roach" From: Rohan Mahy Subject: Re: [SIP] Static Images Cc: oran@cisco.com (David R. Oran), rfairlie@nuera.com (Fairlie-Cuninghame Robert), schulzrinne@cs.columbia.edu (Henning Schulzrinne), jdrosen@dynamicsoft.com (Jonathan Rosenberg), sip@lists.bell-labs.com In-Reply-To: <200006291243.HAA08045@b04a24.exu.ericsson.se> References: <0cfa01bfe1c2$7dd02040$07d245ab@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 Adam, The "sprog" behavior reminds me of push advertising content. I am incredibly alarmed at the idea of displaying "sprog", or playing "sprog", or continually prompting me if I want to see "sprog". It's bad enough when I surf with cookie protection turned on. IMO, This non-semantically defined rendering is more appropriate for Instant Messaging. Now if you really want your UA to always display whatever content your peer barfs down to you, then I suggest we use headers, but create a convention that all the header names end with -Info. Then, when you get the headers: Sprog-Info: http://www.spam.com/annoying-animated.gif Sprog-Info: http://www.spam.com/annoying.wav Your UA can match against unknown *-Info headers and a) happily render them, b) prompt for them, or c) ignore them. Alerting-Info: special ring or display From-Info: CallerID photos, .vcfs, spoken names, etc. Error-Info: Dave's pointer to error messages Context-Info: stuff relevant to the call (presentation, web page, photo, etc.) etc... thanks, -rohan At 05:43 AM 6/29/00 , Adam B. Roach wrote: > >So, in my view, if you wanted a something to be presented to the user during > >alerting, we'd have headers like: > >Alerting-Info: http://doggie-heaven.aol.com/~mydogskip/mug.jpg > >Alerting-Info: ftp://doggie-heaven.aol.com/~mydogskip/woof-woof.mp3 > >Alerting-Info: rtsp://doggie-heaven.aol.com/~mydogskip/phew-phew.sml > >From-Info: http://doggie-heaven.aol.com/~mydogskip/skip.vcf > > > >Depending on what the UA was capable of and the UA owner's preferences, > >during alerting it could do one or more of: > >a) display the picture of Skip > >b) play Skip barking as the alerting sound > >c) emit chemicals to simulate a very muddy unwashed skip walking into the > >room. > > > >and make available via some UI function Skip's vCard information to allow it > >to be added to an address book, or whatever. > >I think the point that Jonathan is trying to make (and one >with which I agree) is that, for example, if you define a future >extension for some other semantics than "alerting" or "from," new >*headers* are suboptimal. > >Henning's argument holds *only* if the header itself has >no associated semantics. In this case, it isn't true. >"Display-Info" conveys the concept that "this is additional >content to be rendered for the user." The purpose >parameters are merely giving hints as to how this >information would most effectively be conveyed. > >I'll demonstrate this point. > >Sprog-Info: http://www.xyz.com/image.jpg > >If your client didn't understand this new header type >of "Sprog-Info," it would be ignored. > >Display-Info: http://www.xyz.com/image.jpg;purpose=sprog > >On the other hand, a client which understood the general >"Display-Info" header, but had no idea what this new "sprog" >thing was would have a much better recovery. It could either >present the image (possibly in a box labeled "sprog"), or at >least let the user know: "I have an image here labeled 'sprog.' >Do you want to see it?") > >I see the second set of behavior as far preferable. > >-- >Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 >adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA > > >_______________________________________________ >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 Jun 29 12:57: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 MAA14540 for ; Thu, 29 Jun 2000 12:57: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 035D24434F; Thu, 29 Jun 2000 12:57:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by lists.bell-labs.com (Postfix) with ESMTP id 1404B44336 for ; Thu, 29 Jun 2000 12:57:38 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id LAA09094; Thu, 29 Jun 2000 11:57:36 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA19195; Thu, 29 Jun 2000 11:57:35 -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 LAA26483; Thu, 29 Jun 2000 11:57:34 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id LAA10490; Thu, 29 Jun 2000 11:57:33 -0500 (CDT) Date: Thu, 29 Jun 2000 11:57:33 -0500 (CDT) Message-Id: <200006291657.LAA10490@b04a45.exu.ericsson.se> To: Adam.Roach@Ericsson.com, rohan@cisco.com Subject: Re: [SIP] Static Images Cc: oran@cisco.com, rfairlie@nuera.com, schulzrinne@cs.columbia.edu, jdrosen@dynamicsoft.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 X-BeenThere: sip@lists.bell-labs.com > Adam, > > The "sprog" behavior reminds me of push advertising content. I am > incredibly alarmed at the idea of displaying "sprog", or playing "sprog", > or continually prompting me if I want to see "sprog". It's bad enough when > I surf with cookie protection turned on. IMO, This non-semantically > defined rendering is more appropriate for Instant Messaging. > > Now if you really want your UA to always display whatever content your peer > barfs down to you, then I suggest we use headers, but create a convention > that all the header names end with -Info. Then, when you get the headers: > > Sprog-Info: http://www.spam.com/annoying-animated.gif > Sprog-Info: http://www.spam.com/annoying.wav > > Your UA can match against unknown *-Info headers and a) happily render > them, b) prompt for them, or c) ignore them. It can quite easily do the same when matching unknown "purpose=" parameters on a Display-Info: header. This is just a syntactical difference, not a semantic one. You might argue that it can be more efficient to filter based on the header name. You can also argue that it's easier to just look for all the Display-Info: headers and not have to worry about possible namespace collisions if someone adds a SIP extension header that uses a *-Info header. Both approaches have problems. There seems to be some confusion here about what you are trying to convey either with a header or with a parameter on that header. There seem to be three pieces of information that are needed and only two are being addressed. 1) A URL identifying some resource potentially to be accessed 2) The purpose of that resource 3) The mechanism for presenting that resource What I would propose then is a compromise: Use the header name to indicate the purpose of the resource as in: Alerting-Info: special ring or display From-Info: CallerID photos, .vcfs, spoken names, etc. Error-Info: Dave's pointer to error messages Context-Info: stuff relevant to the call (presentation, web page, photo, etc.) Use a "disposition=" parameter to indicate the mechanism for presenting that resource. For example, a caller ID image that is meant to be rendered in parallel with call setup would be From-Info: http://www.cow.com/~bob/id.jpg ; disposition=inline sean -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jun 29 13:06: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 NAA14866 for ; Thu, 29 Jun 2000 13:06: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 7C00E44336; Thu, 29 Jun 2000 13:06:31 -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 6E2134436C for ; Thu, 29 Jun 2000 13:06:28 -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 KAA10858; Thu, 29 Jun 2000 10:06:39 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAA96402; Thu, 29 Jun 2000 10:03:06 -0700 (PDT) Message-Id: <4.2.0.58.20000629100407.00dc2f00@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 29 Jun 2000 10:05:40 -0700 To: Jonathan Rosenberg From: Rohan Mahy Subject: Re: [SIP] Handling multiple Transfer Target Cc: Helpdesk MIS , sip@lists.bell-labs.com In-Reply-To: <394B2446.C6798225@dynamicsoft.com> References: <4D0A8ECBDC8AD211BD0900A0C9EBC13301C23D1B@rambo.globespan.net> 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:09 AM 6/17/00 , Jonathan Rosenberg wrote: > > From: rafi > > Is it possible for the transferor to inform the transferee > > to try more than one transfer target serially or simultaneously? > > Probably one way to do is to include more than one Transfer-to-Header > > in the TRANSFER request message because transferee take decision > > based on this field (section 4.6 of draft > > draft-sparks-sip-cc-transfer-00.txt). > > May be order of the of each name-addr / addr-spec in > > Transfer-to-Header implies > > their priority. Having more than one Transfer-to-Header header > > is not allowed in the draft, draft-sparks-sip-cc-transfer-00.txt. > >I'm a bit reluctant to allow that. I'm not sure its needed. If you want >the transferred party to try one address, then the next, then the next, >etc., once each fails, you can do that without having multiple >transfer-tos. Logic in the transferring party can simply send multiple >transfer requests, one after a failure response from the previous. > >So, having multiple addresses is only useful for parallel transfers, but >I doubt that this is useful. What happens if multiple acceptances come >back? Does the transferred party speak to all, or just one? Was the >TRANSFER successful if only some of the addresses in the transfer-to >header yield successful results? Lots of complexity for no real value. Rafi, If you want message-level efficiency instead of byte level efficiency, you could bundle multiple TRANSFER requests into a single UDP datagram (size permitting). 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 Fri Jun 30 09:46: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 JAA17409 for ; Fri, 30 Jun 2000 09:46: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 D7EBC44363; Fri, 30 Jun 2000 09:45:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nausicaa.coritel.it (unknown [193.205.242.5]) by lists.bell-labs.com (Postfix) with ESMTP id BB28A44336 for ; Fri, 30 Jun 2000 09:45:29 -0400 (EDT) Received: from fermi (fermi.coritel.it [193.205.242.3]) by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id PAA19591 for ; Fri, 30 Jun 2000 15:35:32 +0200 (MET DST) From: "Tonino Villani" To: Subject: [SIP] Dissipate Date: Fri, 30 Jun 2000 15:55:46 +0200 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: <200006291613.LAA10402@b04a45.exu.ericsson.se> 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 Hi, I'm looking for information about dissipate. Where can I download the latest revision of this library. Best regards Tony _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 30 09:50: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 JAA17462 for ; Fri, 30 Jun 2000 09:50: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 1100544377; Fri, 30 Jun 2000 09:49:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr703217-a.ktchnr1.on.wave.home.com [24.42.217.5]) by lists.bell-labs.com (Postfix) with ESMTP id 7708F4434F for ; Fri, 30 Jun 2000 09:49:51 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 30 Jun 2000 09:49:39 -0400 (EDT) Date: Fri, 30 Jun 2000 09:49:39 -0400 From: Billy Biggs To: Tonino Villani Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Dissipate Message-ID: <20000630094939.A29074@div8.net> References: <200006291613.LAA10402@b04a45.exu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from villani@coritel.it on Fri, Jun 30, 2000 at 03:55:46PM +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 Tonino Villani (villani@coritel.it): > I'm looking for information about dissipate. Where can I download the > latest revision of this library. The homepage is at http://www.div8.net/dissipate/ If you have questions about it, please contact me directly. Thanks, -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 30 11: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 LAA19465 for ; Fri, 30 Jun 2000 11:28: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 C4E614436E; Fri, 30 Jun 2000 11:27: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 5108A44336 for ; Fri, 30 Jun 2000 11:27: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 LAA29659 for ; Fri, 30 Jun 2000 11:28:59 -0400 (EDT) Message-ID: <395CBCE0.8E525CDC@dynamicsoft.com> Date: Fri, 30 Jun 2000 11:29:36 -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] updated reliable 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 Folks, Based on comments during last call, I have updated the reliable provisional responses draft, and resubmitted. I have removed cumulative PRACK from the document. Until it appears, you can find a new version at: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-sip-100rel-02.txt as this represents a technical change, I will not send to IESG until the end of next week. This will give people a chance to comment on this final version. 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 Fri Jun 30 18:56: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 SAA28079 for ; Fri, 30 Jun 2000 18:56: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 8558644349; Fri, 30 Jun 2000 18:56:04 -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 7061844336 for ; Fri, 30 Jun 2000 18:56:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 30 18:54:39 EDT 2000 Received: by lists.bell-labs.com (Postfix) id F166844348; Fri, 30 Jun 2000 18:41:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id CB73344347 for ; Fri, 30 Jun 2000 18:41:29 -0400 (EDT) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA19577; Fri, 30 Jun 2000 18:41:34 -0400 (EDT) Message-ID: <395D221A.9D6E6F58@cs.columbia.edu> Date: Fri, 30 Jun 2000 18:41:30 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: sip@lists.bell-labs.com, "Vijay K. Gurbani" Subject: Re: [SIP] More on tags 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 Generally, it seems that the cost of generating globally unique identifiers is low, but the cost of not doing it potentially high. Thus, this seems to be a safe choice. The tag is used to distinguish several "versions" of the same To/From identifier, so it doesn't have to chang when the Call-ID changes. There doesn't seem to be any advantage of making it unique within a call-id, since you'd have to be sure that all "versions" with the same call-id choose a different identifier - at that point, you're likely back at a globally unique identifier, based on (say) the MAC address, CPU identifier and who knows what else. Why is this a problem? > Vijay Gurbani wrote: > Hi: > > A collegue asked this question of me, for which I have an answer (see > below), but would like to validate it. > > Question: Why does the RFCbis (June 9, 2000) mandate that the tag be > "globally unique" (Section 6.23)? Can't it be unique within the Call-ID > space it occupies? The Call-ID already is "a globally unique > identifier". Why have 2 globally unique identifiers to identify a > single call leg? > > One reason I can think of is that if multiple UA servers are contacted > for a call, this wording guarantees that each of the UA servers use an > algorithm to generate a globally unique tag; otherwise, if each of them > used, say, the time of day to generate the tag (and they happen to be > in the same time zone etc. etc.), there could be a potential to generate > the same tag at each UA server. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jun 30 19:30: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 TAA28526 for ; Fri, 30 Jun 2000 19:30: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 9A8EF44349; Fri, 30 Jun 2000 19:30: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 B5CCC44336 for ; Fri, 30 Jun 2000 19:30:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 30 19:29:31 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3121644348; Fri, 30 Jun 2000 19:16:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id 0AEC744347 for ; Fri, 30 Jun 2000 19:16:22 -0400 (EDT) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA20213; Fri, 30 Jun 2000 19:16:23 -0400 (EDT) Message-ID: <395D2A44.22F830A1@cs.columbia.edu> Date: Fri, 30 Jun 2000 19:16:20 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Phil Hoffer , sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] 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: 7bit I can't tell for sure from the PGP documentation, but rsa does seem to be the default. (The documentation for version 6.5, the latest, almost makes it sound like that this depends on the version of the software.) I added the missing parameter. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip