From daemon@optimus.ietf.org Mon Jul 1 03:01:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03157 for ; Mon, 1 Jul 2002 03:01:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA13443 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 03:02:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12099; Mon, 1 Jul 2002 02:41:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12057 for ; Mon, 1 Jul 2002 02:41:49 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02636 for ; Mon, 1 Jul 2002 02:41:01 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g616fgxc024359; Mon, 1 Jul 2002 02:41:42 -0400 (EDT) Received: from cs.columbia.edu (dialin-212-144-151-183.arcor-ip.net [212.144.151.183]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g616fNpf000640 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Jul 2002 02:41:36 -0400 (EDT) Message-ID: <3D1F698A.4020404@cs.columbia.edu> Date: Sun, 30 Jun 2002 16:26:50 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Sriram Parameswar , sip@ietf.org Subject: Re: [Sip] RE: Event Filtering References: <3D1AC5E2.4030302@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I acutally like the idea of a more generic filter/trigger mechanism that > would apply cross-packages. The tradeoff is one of generality vs. > complexity. The single mechanism will be more general, but probably more > complex than an event-specific one. How much more complex? Impossible to > say, of course. I generally favor generality, so if its not to omuch > more complex, I think its a good thing. However, unless you plan on > enumerating the set of filters and triggers allowed in a package, I > suspect that the general one won't be that much more complex. Saying > "only send me notifies once an hour on alternate thursdays, if the value > of the foo parameter is bar" is going to be complex in any case. CPL with the calsch extensions makes expressing alternate Thursdays very easy :-) > > I think the Moran draft is a good start, but not quite there yet. Part > of the problem is scope. What exactly do we wish to support, in terms of > filter/trigger policies? You don't want to boil the ocean with the first > version. I think that, if we go for a general solution, we should do > JUST enough to meet the *real* problems people are trying to solve, and > we can make it extensible to handle more down the road. > > I would postulate that, realistically, the scope of triggers is going to > be limited to: > > * waiting for a certain event to occur within a certain state, > * waiting for a certain variable to take a certain value > > Things like the mathematical and temporal conditions are interesting, > but I doubt would really be used in practice. Similarly, the filtering > conditions are probably limited to asking for notifications to contain > only certain variables. > > With a well scoped set of requirements, as I have proposed above, I > think you can get a pretty straightforward language that would apply > cross-packages. > > I'll also note that, if we assume that all notifications contain XML as > bodies (I know its not true, bear with me), then the filter could > possibly be an XSLT document. This might be overkill. For things that > are not XML, you'd need to specify an XML mapping for it to work (yuck). > Just a thought. > > So, I would propose that, in order to make progress on this issue, we > agree upon a realistic scope for these things, in terms of requirements > on filters and triggers, and then we can see how complex the > general-purpose filtering language is. We've also looked at extending CPL for presence (draft-wu-cpl-presence, I thin). The question is whether the same model makes sense for events. I don't think XSLT is the right choice. If anything, you want something like the XML Query language where you can formulate conditions on XML bodies. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 03:01:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03160 for ; Mon, 1 Jul 2002 03:01:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA13454 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 03:02:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11979; Mon, 1 Jul 2002 02:39:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11938 for ; Mon, 1 Jul 2002 02:39:26 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02571 for ; Mon, 1 Jul 2002 02:38:39 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g616dNxc024213; Mon, 1 Jul 2002 02:39:23 -0400 (EDT) Received: from cs.columbia.edu (dialin-212-144-151-183.arcor-ip.net [212.144.151.183]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g616dIpf000548 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Jul 2002 02:39:21 -0400 (EDT) Message-ID: <3D1F4707.9000403@cs.columbia.edu> Date: Sun, 30 Jun 2002 13:59:35 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Undery CC: "SIP (E-mail)" Subject: Re: [Sip] draft-schulzrinne-sip-bind References: <45730E094814E44488F789C1CDED27AEC55301@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit One more comment based on further thought and side discussions: While one-time URIs are part of the requirements doc, they have a number of problems. For example, does this mean that a server can only hand out this URI once? What if the client never uses it? How does this interact with caching? This adds state complexity and requires transaction-like behavior (what if the server crashes just between handing out the binding and removing it?). I would be interested to hear about the problem this feature is supposed to solve. One-time URIs are not found elsewhere, from my understanding. A web server, say, could always enforce this implicitly, by removing the resource addressed by the URI after the first access, but I'm having a hard time seeing how this can be done in practice, given that the web server won't know how many instances of the AoR will need this information. James Undery wrote: > Hi, > > I generally like this draft, although would like to suggest a change. > > Having "expires=1" a special value isn't very clean, a "usagecount" > parameter that shows how many times a URL will be valid for seems much > more flexible. The combination of usagecount and expires would also > allow for a one-shot URL that's valid for 60 seconds say, i.e. Binding: > ;disposition=token > ;expires=60 ;usagecount=1 > > James > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 03:01:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03186 for ; Mon, 1 Jul 2002 03:01:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA13465 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 03:02:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12055; Mon, 1 Jul 2002 02:41:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12026 for ; Mon, 1 Jul 2002 02:41:46 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02629 for ; Mon, 1 Jul 2002 02:40:58 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g616fdxc024356; Mon, 1 Jul 2002 02:41:39 -0400 (EDT) Received: from cs.columbia.edu (dialin-212-144-151-183.arcor-ip.net [212.144.151.183]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g616fMpf000639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Jul 2002 02:41:26 -0400 (EDT) Message-ID: <3D1F698A.4020404@cs.columbia.edu> Date: Sun, 30 Jun 2002 16:26:50 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Sriram Parameswar , sip@ietf.org Subject: Re: [Sip] RE: Event Filtering References: <3D1AC5E2.4030302@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I acutally like the idea of a more generic filter/trigger mechanism that > would apply cross-packages. The tradeoff is one of generality vs. > complexity. The single mechanism will be more general, but probably more > complex than an event-specific one. How much more complex? Impossible to > say, of course. I generally favor generality, so if its not to omuch > more complex, I think its a good thing. However, unless you plan on > enumerating the set of filters and triggers allowed in a package, I > suspect that the general one won't be that much more complex. Saying > "only send me notifies once an hour on alternate thursdays, if the value > of the foo parameter is bar" is going to be complex in any case. CPL with the calsch extensions makes expressing alternate Thursdays very easy :-) > > I think the Moran draft is a good start, but not quite there yet. Part > of the problem is scope. What exactly do we wish to support, in terms of > filter/trigger policies? You don't want to boil the ocean with the first > version. I think that, if we go for a general solution, we should do > JUST enough to meet the *real* problems people are trying to solve, and > we can make it extensible to handle more down the road. > > I would postulate that, realistically, the scope of triggers is going to > be limited to: > > * waiting for a certain event to occur within a certain state, > * waiting for a certain variable to take a certain value > > Things like the mathematical and temporal conditions are interesting, > but I doubt would really be used in practice. Similarly, the filtering > conditions are probably limited to asking for notifications to contain > only certain variables. > > With a well scoped set of requirements, as I have proposed above, I > think you can get a pretty straightforward language that would apply > cross-packages. > > I'll also note that, if we assume that all notifications contain XML as > bodies (I know its not true, bear with me), then the filter could > possibly be an XSLT document. This might be overkill. For things that > are not XML, you'd need to specify an XML mapping for it to work (yuck). > Just a thought. > > So, I would propose that, in order to make progress on this issue, we > agree upon a realistic scope for these things, in terms of requirements > on filters and triggers, and then we can see how complex the > general-purpose filtering language is. We've also looked at extending CPL for presence (draft-wu-cpl-presence, I thin). The question is whether the same model makes sense for events. I don't think XSLT is the right choice. If anything, you want something like the XML Query language where you can formulate conditions on XML bodies. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 07:09:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25580 for ; Mon, 1 Jul 2002 07:09:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05576 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 07:10:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20837; Mon, 1 Jul 2002 06:40:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20579 for ; Mon, 1 Jul 2002 06:40:03 -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 GAA22480; Mon, 1 Jul 2002 06:39:03 -0400 (EDT) Message-Id: <200207011039.GAA22480@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 01 Jul 2002 06:39:02 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-message-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : Session Initiation Protocol Extension for Instant Messaging Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-sip-message-05.txt Pages : 22 Date : 28-Jun-02 Instant Messageing (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. The MESSAGE method is an extension to the Session Initation Protocol (SIP) that allows the transfer of Instant Messages. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. Since the MESSAGE request is an extension to SIP it inherits all the request routing and security features of that protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-message-05.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-message-05.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: <20020628142840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142840.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 07:58:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29040 for ; Mon, 1 Jul 2002 07:58:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18862 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 07:59:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08534; Mon, 1 Jul 2002 07:18:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08503 for ; Mon, 1 Jul 2002 07:17:57 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26251 for ; Mon, 1 Jul 2002 07:17:08 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 1 Jul 2002 13:16:34 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 13:17:23 +0200 Message-Id: From: "Alexeitsev, D" To: christer.holmberg@lmf.ericsson.se Cc: sip@ietf.org, chogg@nortelnetworks.com Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Mon, 1 Jul 2002 13:17:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA08504 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello All, Some comments/questions inline Greetings, Denis Alexeitsev -----Ursprüngliche Nachricht----- Von: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Gesendet am: Freitag, 28. Juni 2002 18:53 An: Chris Hogg Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson; sip@ietf.org; Bob Penfield Betreff: Re: [Sip] Local vs Remote ringback on 180 [CHH] The UAS may still send early media, but since it sends 180 without SDP it allows the UAC to generate local ringback tone, so the UAC now can assume that it can "cut" the early media from the caller during that time. If the UAS does NOT want the UAC to generate local ringback, the 180 would also contain SDP (the same SDP which was used in the 183 to establish the early dialog, ie the SDP is not a new offer/answer - simply a ringback "indicator"). [DA]I have a question about the need to receive the SDP in any responses in order to play remote ringback. As the offer/answer draft says: "Once the offerer has sent the offer, it MUST be prepared to receive media" The SDP coming from the other side is used to send the media, that is unimportant in the ringback case. Am I missing something here? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 08:10:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29668 for ; Mon, 1 Jul 2002 08:10:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA19763 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 08:11:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17594; Mon, 1 Jul 2002 07:32:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17567 for ; Mon, 1 Jul 2002 07:32:24 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27756 for ; Mon, 1 Jul 2002 07:31:34 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g61BQ9rU025875; Mon, 1 Jul 2002 13:26:09 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g61BQ9a9021769; Mon, 1 Jul 2002 14:26:09 +0300 (EET DST) Message-ID: <3D203C51.DC73559E@lmf.ericsson.se> Date: Mon, 01 Jul 2002 14:26:09 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alexeitsev, D" CC: sip@ietf.org, chogg@nortelnetworks.com Subject: Re: [Sip] Local vs Remote ringback on 180 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, "Alexeitsev, D" wrote: > Hello All, > > Some comments/questions inline > > Greetings, > Denis Alexeitsev > > -----Ursprüngliche Nachricht----- > Von: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Gesendet am: Freitag, 28. Juni 2002 18:53 > An: Chris Hogg > Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson; sip@ietf.org; > Bob Penfield > Betreff: Re: [Sip] Local vs Remote ringback on 180 > > [CHH] The UAS may still send early media, but since it sends 180 without > SDP it allows the UAC to generate local ringback tone, so the UAC now > can assume that it can "cut" the early media from the caller during that > time. If the UAS does NOT want the UAC to generate local ringback, the > 180 would also contain SDP (the same SDP which was used in the 183 to > establish the early dialog, ie the SDP is not a new offer/answer - > simply a ringback "indicator"). > > [DA]I have a question about the need to receive the SDP in any responses in order to play remote ringback. As the offer/answer draft says: > "Once the offerer has sent the offer, it MUST be prepared to receive media" > > The SDP coming from the other side is used to send the media, that is unimportant in the ringback case. Am I missing something here? [CHH] For the specific ringback tone case one can argue that an SDP is not needed for the media itself (unless you need it for RTCP purpose, or something). However, there is no specific "remote ringback session" in SIP. You establish a generic early dialiog, by sending an offer and receiving an answer, which can then be used for any kind of early media (ringback tone, announcement,...), in any direction (depending on the "direction" indicators - sendrecv, sendonly, inactive etc etc). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 10:05:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06659 for ; Mon, 1 Jul 2002 10:05:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00703 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 10:06:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26490; Mon, 1 Jul 2002 09:37:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26445 for ; Mon, 1 Jul 2002 09:37:05 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04499 for ; Mon, 1 Jul 2002 09:36:15 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g61DZ7Q25335; Mon, 1 Jul 2002 14:35:08 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 14:35:08 +0100 Message-ID: From: "Mark Watson" To: "'Christer Holmberg'" , "Alexeitsev, D" Cc: sip@ietf.org, "Chris Hogg" Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Mon, 1 Jul 2002 14:35:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22104.1BBE12E4" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C22104.1BBE12E4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable All, I'm confused by this discussion, because there seems to be a desire to extrapolate some semantics about the *media* from a message which does = not contain SDP. Apologies if I have missed the issue at hand, or if the following is obvious, but... The unify model means that media and session state are completely independent, so, to talk about '180 with SDP' or '180 without SDP' = makes no sense. You can talk about the effect 180 has on the session state (indicates = that called party is being alerted), but this has nothing to do with the = media state (if there was media before, there still is, if there was no media before, there still isn't). You can talk about the effect that SDP offer/answer exchanges have on = the media, but this operates independently of the SIP message those SDP = bodies arrive in. So, 1) the UAC knows whether there is media or not (based on SDP = offer/answer exchanges so far) 2) if 180 has been received, the UAC knows that the called party is = alerting If the UAC knows that the called party is alerting AND knows that there = is media, it is a local matter what to do. Personally, I cannot see an = argument for doing anything other than playing the media (it might contain = 'ringing with call waiting announcement'). A PROBLEM arises if there is a UAS which negotiates media but then = sends silence (no packets) - there ARE some reasons why it might want to do = this to do with reducing clipping on answer. The result is that silence = would be all the caller would hear even though the UAC may know that the called = party is being alerted. I think we just have to say that it is foolish for = the UAS to negotiate media and then send silence - it should put the media on = hold if it has nothing to send. Regards, Mark > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 01 July 2002 12:26 > To: Alexeitsev, D > Cc: sip@ietf.org; Hogg, Chris [MOP:MA01:EXCH] > Subject: Re: [Sip] Local vs Remote ringback on 180 >=20 >=20 >=20 > Hi, >=20 > "Alexeitsev, D" wrote: >=20 > > Hello All, > > > > Some comments/questions inline > > > > Greetings, > > Denis Alexeitsev > > > > -----Urspr=FCngliche Nachricht----- > > Von: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Gesendet am: Freitag, 28. Juni 2002 18:53 > > An: Chris Hogg > > Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson;=20 > sip@ietf.org; > > Bob Penfield > > Betreff: Re: [Sip] Local vs Remote ringback on 180 > > > > [CHH] The UAS may still send early media, but since it=20 > sends 180 without > > SDP it allows the UAC to generate local ringback tone, so=20 > the UAC now > > can assume that it can "cut" the early media from the=20 > caller during that > > time. If the UAS does NOT want the UAC to generate local=20 > ringback, the > > 180 would also contain SDP (the same SDP which was used in=20 > the 183 to > > establish the early dialog, ie the SDP is not a new offer/answer - > > simply a ringback "indicator"). > > > > [DA]I have a question about the need to receive the SDP in=20 > any responses in order to play remote ringback. As the=20 > offer/answer draft says: > > "Once the offerer has sent the offer, it MUST be prepared=20 > to receive media" > > > > The SDP coming from the other side is used to send the=20 > media, that is unimportant in the ringback case. Am I missing=20 > something here? >=20 > [CHH] For the specific ringback tone case one can argue that=20 > an SDP is not needed for the media itself (unless you need it=20 > for RTCP purpose, > or something). >=20 > However, there is no specific "remote ringback session" in=20 > SIP. You establish a generic early dialiog, by sending an=20 > offer and receiving an > answer, which can then be used for any kind of early media=20 > (ringback tone, announcement,...), in any direction=20 > (depending on the "direction" > indicators - sendrecv, sendonly, inactive etc etc). >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 ------_=_NextPart_001_01C22104.1BBE12E4 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Local vs Remote ringback on 180

All,

I'm confused by this discussion, because there seems = to be a desire to extrapolate some semantics about the *media* from a = message which does not contain SDP. Apologies if I have missed the = issue at hand, or if the following is obvious, but...

The unify model means that media and session state = are completely independent, so, to talk about '180 with SDP' or '180 = without SDP' makes no sense.

You can talk about the effect 180 has on the session = state (indicates that called party is being alerted), but this has = nothing to do with the media state (if there was media before, there = still is, if there was no media before, there still isn't).

You can talk about the effect that SDP offer/answer = exchanges have on the media, but this operates independently of the SIP = message those SDP bodies arrive in.

So,

1) the UAC knows whether there is media or not (based = on SDP offer/answer exchanges so far)
2) if 180 has been received, the UAC knows that the = called party is alerting

If the UAC knows that the called party is alerting = AND knows that there is media, it is a local matter what to do. = Personally, I cannot see an argument for doing anything other than = playing the media (it might contain 'ringing with call waiting = announcement').

A PROBLEM arises if there is a UAS which negotiates = media but then sends silence (no packets) - there ARE some reasons why = it might want to do this to do with reducing clipping on answer. The = result is that silence would be all the caller would hear even though = the UAC may know that the called party is being alerted. I think we = just have to say that it is foolish for the UAS to negotiate media and = then send silence - it should put the media on hold if it has nothing = to send.

Regards,

Mark

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: 01 July 2002 12:26
> To: Alexeitsev, D
> Cc: sip@ietf.org; Hogg, Chris = [MOP:MA01:EXCH]
> Subject: Re: [Sip] Local vs Remote ringback on = 180
>
>
>
> Hi,
>
> "Alexeitsev, D" wrote:
>
> > Hello All,
> >
> > Some comments/questions inline
> >
> > Greetings,
> > Denis Alexeitsev
> >
> > -----Urspr=FCngliche Nachricht-----
> > Von: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > Gesendet am: Freitag, 28. Juni 2002 = 18:53
> > An: Chris Hogg
> > Cc: Flemming Andreasen; Jonathan = Rosenberg; Mark Watson;
> sip@ietf.org;
> > Bob Penfield
> > Betreff: Re: [Sip] Local vs Remote = ringback on 180
> >
> > [CHH] The UAS may still send early media, = but since it
> sends 180 without
> > SDP it allows the UAC to generate local = ringback tone, so
> the UAC now
> > can assume that it can "cut" the = early media from the
> caller during that
> > time. If the UAS does NOT want the UAC to = generate local
> ringback, the
> > 180 would also contain SDP (the same SDP = which was used in
> the 183 to
> > establish the early dialog, ie the SDP is = not a new offer/answer -
> > simply a ringback = "indicator").
> >
> > [DA]I have a question about the need to = receive the SDP in
> any responses in order to play remote ringback. = As the
> offer/answer draft says:
> > "Once the offerer has sent the offer, = it MUST be prepared
> to receive media"
> >
> > The SDP coming from the other side is used = to send the
> media, that is unimportant in the ringback = case. Am I missing
> something here?
>
> [CHH] For the specific ringback tone case one = can argue that
> an SDP is not needed for the media itself = (unless you need it
> for RTCP purpose,
> or something).
>
> However, there is no specific "remote = ringback session" in
> SIP. You establish a generic early dialiog, by = sending an
> offer and receiving an
> answer, which can then be used for any kind of = early media
> (ringback tone, announcement,...), in any = direction
> (depending on the "direction"
> indicators - sendrecv, sendonly, inactive etc = etc).
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C22104.1BBE12E4-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 10:16:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07758 for ; Mon, 1 Jul 2002 10:16:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01997 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 10:17:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27177; Mon, 1 Jul 2002 09:44:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17217 for ; Fri, 28 Jun 2002 20:35:28 -0400 (EDT) Received: from services1.dasecurenetworks.com (adsl-64-217-197-215.dsl.rcsntx.swbell.net [64.217.197.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00293 for ; Fri, 28 Jun 2002 20:34:43 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services1.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g5T0APV01253; Fri, 28 Jun 2002 19:10:27 -0500 Message-ID: <3D1D0822.8FF164DC@infravast.com> Date: Fri, 28 Jun 2002 20:06:42 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Sean Olson , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] refreshing NAT binding for SIP with UDP registrations References: <20020628184310.22301.qmail@web11603.mail.yahoo.com> <3D1CC7C3.6090802@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > The holes that this "CRLF approach" has are similar to some of the > generic problems of STUN, which I would prefer be kept isolated there. > THe main one really is that the frequency of the refreshes is dependent > on the binding lifetime; that is not generally known, either to the UA, > or the registrar. TCP works better there. Because TCP connections have > an explicit teardown, they are held in NATs for a long time without > keepalives. > > There is also the needless network traffic from these 1 byte UDP packets > flying around (with 8 bytes UDP, 20 bytes IPv4 headers), a huge waste. I agree on both points...and the majority of corporate network admins would also agree with this, not to mention ISP's if they continue to see constant keepalives....as opposed to what appears to be valid traffic, they may be inclined to cancel service. SIP clients could be considered a violation of ISP policy (in the sense that the majority of existing ISP's forbid web servers on home accounts, for instance, at this point the client represents an internal service listening for connections), excess traffic would cause more notice to these services. I only mention this since many of the NAT scenarios described in past drafts offering solutions for SIP, that I have read, seem to be more suited to SOHO NAT solutions rather than intra/extranet entities, and many of the solutions would not be considered as valid solutions by many corporate administrators/policies due to security issues that would arise from the solutions operation. To clarify the latter comment SIP traversal solutions for the enterprise that involves keep alives or topology discovery on enterprise firewalls may be considered a violation of enterprise security policy, not to mention the excess traffic, which is typically hunted down to be silenced on many of these types of networks, and lastly the potential risk of providing additional vulnerabilities to the internal network that are yet unknown. Many infrastructures do not want internal users having knowlege of the topology. Placing the ability to do so on a client to determine this information may be frowned upon as well. Anyway the firewall vendors have begun to provide SIP solutions to address this now, so it is becoming a moot point. MIDCOM may provide a way to offer additional support for many items other than firewalls, such as load balancing devices etc, so this has much merit, but a traversal solution, IMHO, is not necessary or acceptable, except in the SOHO realm, if that. But if we must work on and develop this capability then the direction that you stated above is the way I would go as well because there are other implications and benefits that we may possibly get from doing this in addition to reducing the excess traffic. Chris Martin > > -Jonathan R. > > Sean Olson wrote: > > This seems to have too many holes. > > However, it *might* be useful to define a > > lightweight SIP keep-alive mechanism. > > > > /sean > > > > --- Cullen Jennings wrote: > > > >>One point about UDP registrations, I don't know if > >>you really need to send a > >>true registration, you can just send any message > >>that creates minimal load > >>on the proxy. For example the UA could send a single > >>CRLF to the proxy. The > >>proxy could have some code to silently ignore any > >>message that is clearly > >>too short to be a valid SIP message. Obviously this > >>won't work in the cases > >>where the UA sends to a proxy inside the NAT then > >>the proxy sends to a > >>another proxy outside the NAT. It also has the > >>problems with no response so > >>you don't know if the message made it to the NAT or > >>not. > >> > >>Do folks see this as an ideal worth pursing or a > >>really bad idea that we > >>should suggest people don't do? > >> > >>Cullen > >> > >> > >>_______________________________________________ > >>Sip mailing list > >>https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP > >>Protocol > >>Use sip-implementors@cs.columbia.edu for questions > >>on current sip > >>Use sipping@ietf.org for new developments on the > >>application of sip > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! - Official partner of 2002 FIFA World Cup > > http://fifaworldcup.yahoo.com > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 10:21:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08252 for ; Mon, 1 Jul 2002 10:21:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02778 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 10:22:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27172; Mon, 1 Jul 2002 09:44:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09902 for ; Mon, 1 Jul 2002 05:23:46 -0400 (EDT) Received: from hotmail.com (f312.law10.hotmail.com [64.4.14.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14881 for ; Mon, 1 Jul 2002 05:22:59 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Jul 2002 02:23:15 -0700 Received: from 192.35.17.22 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 01 Jul 2002 09:23:15 GMT X-Originating-IP: [192.35.17.22] From: "Salva Rey" To: sip@ietf.org Date: Mon, 01 Jul 2002 09:23:15 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jul 2002 09:23:15.0677 (UTC) FILETIME=[EDF450D0:01C220E0] Subject: [Sip] Forking proxy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi all, a doubt regarding forking proxies, why would a proxy do if forked an INVITE request, it got back some reliable provisional responses that established some early dialogs at the UAC, and then one of the UAS's sends a final response 200 oK. If the other early dialogs try to send further reliable provisional responses this wont get through the proxy since a final response was already sent on the response context. Should the proxy behaviour not only forward immediately 200ok responses to INVITE, but also reliable responses ? best regards Salva _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 11:21:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11809 for ; Mon, 1 Jul 2002 11:21:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08187 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 11:22:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05175; Mon, 1 Jul 2002 10:45:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05144 for ; Mon, 1 Jul 2002 10:45:19 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09709 for ; Mon, 1 Jul 2002 10:44:30 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g61Ej9rU002657; Mon, 1 Jul 2002 16:45:09 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g61Ej8a9008146; Mon, 1 Jul 2002 17:45:08 +0300 (EET DST) Message-ID: <3D206AF5.B1C33DF8@lmf.ericsson.se> Date: Mon, 01 Jul 2002 17:45:09 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "Alexeitsev, D" , sip@ietf.org, Chris Hogg Subject: Re: [Sip] Local vs Remote ringback on 180 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Mark, > I'm confused by this discussion, because there seems to be a desire to > extrapolate some semantics about the *media* from a message which does > not contain SDP. Apologies if I have missed the issue at hand, or if > the following is obvious, but... > > The unify model means that media and session state are completely > independent, so, to talk about '180 with SDP' or '180 without SDP' > makes no sense. I agree, but those are the terms used by the drafts I've refered to. The ISUP/SIP mapping draft says that "180 with SDP" means that a remote ringback will be generated, and bis-09 says that "180 without SDP" MAY cause the UAC to generate a local ringback. Of course, those statements may sometimes be valid, if we receive either a 180 without SDP, OR we receive 180 with SDP - and no early dialog still exists. My orignial question was what we do if we receive 180 without SDP, but we DO have an early dialog established. It has been argued that the UAC should not generate local ringback in that case - instead assume the UAS does it since there is an early dialog established (if the UAS wants the UAC to generate local ringback it would have to put the media on hold using UPDATE). IF that's the case, I think it should me more clarified. Clarification is the only thing I've asked for - no changes in the protocol. > You can talk about the effect 180 has on the session state (indicates > that called party is being alerted), but this has nothing to do with > the media state (if there was media before, there still is, if there > was no media before, there still isn't). I've said all the time that the session state is not affected, only that the 180 affects what the application does with the media. So, what you just wrote means, that in the case we have an established early dialog it really doesn't matter, from a ringback point of view, if there is a SDP in the 180 or not. Is that the "official" clarification I've asked for? :) > You can talk about the effect that SDP offer/answer exchanges have on > the media, but this operates independently of the SIP message those > SDP bodies arrive in. True. That is why I also asked if the SDP is a good "ringback indicator" in the first place... > So, > > 1) the UAC knows whether there is media or not (based on SDP > offer/answer exchanges so far) > 2) if 180 has been received, the UAC knows that the called party is > alerting > > If the UAC knows that the called party is alerting AND knows that > there is media, it is a local matter what to do. Personally, I cannot > see an argument for doing anything other than playing the media (it > might contain 'ringing with call waiting announcement'). I think it was earlier said that the decission can't be based on if there is media or not. There may be RTP packets, but that doesn't mean they contain any "real" media. > A PROBLEM arises if there is a UAS which negotiates media but then > sends silence (no packets) - there ARE some reasons why it might want > to do this to do with reducing clipping on answer. The result is that > silence would be all the caller would hear even though the UAC may > know that the called party is being alerted. I think we just have to > say that it is foolish for the UAS to negotiate media and then send > silence - it should put the media on hold if it has nothing to send. Like I said earlier, that would probably not happend when the same server establishes the early dialog and sends the 180. I earlier gave an example where a B2BUA sends the announcement ("you have now reached the X company"), the contacts a SIP phone which sends 180 (the SIP phone does NOT generate early media). Now, the B2BUA gets the 180, stop playing the announcement, and forwards the 180 to the UAC. Now, since there are no more announcements, and the SIP phone doesn't generate remote ringback, and the UAC doesn't generate local ringback, there is no ringback at all. In this case the B2BUA would have to send UPDATE (media on hold), then forward the 180 (the UAC will now generate local ringback), and when the SIP phone answers it would have to send another UPDATE (media un-hold) and then forward the 200. An issue related to this I brought up earlier, is if the UAS will have to buffer the 200 until both UPDATE transactions have been completed. Any comments on that? Also, in a non-PRACK environment, is a 18x "allowed" to establish an early dialog in the first place? Bis-09 says that the answer must be sent in a reliable response, which is 200 OK. Yes, bis-09 DOES say that the answer MAY also be sent earlier, unreliably in a 18x, but when is the early dialog actually "officially" established? Again, the UAC could make a ringback decission based on if there is a SDP in the 180 or not, but a unreliably sent 180 may not even arrive... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 11:56:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14172 for ; Mon, 1 Jul 2002 11:56:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11417 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 11:57:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08862; Mon, 1 Jul 2002 11:30:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08809 for ; Mon, 1 Jul 2002 11:30:26 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12368 for ; Mon, 1 Jul 2002 11:29:39 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 1 Jul 2002 17:29:06 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 17:29:55 +0200 Message-Id: From: "Alexeitsev, D" To: christer.holmberg@lmf.ericsson.se Cc: sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Mon, 1 Jul 2002 17:29:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA08811 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello a comment inline Greeting, Denis Alexeitsev > -----Ursprüngliche Nachricht----- > Von: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Gesendet am: Freitag, 28. Juni 2002 18:53 > An: Chris Hogg > Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson; sip@ietf.org; > Bob Penfield > Betreff: Re: [Sip] Local vs Remote ringback on 180 However, there is no specific "remote ringback session" in SIP. You establish a generic early dialiog, by sending an offer and receiving an answer, [DA]As the offer/answer draft says: one "MUST be prepared to receive media" after the sending of the offer, so it does not require for UAC to receive an answer in order to start the media playback (as the early media, in my understanding, always come from the UAS i.e. ringback tone, announcement,... and not other way around) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 13:08:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19055 for ; Mon, 1 Jul 2002 13:08:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19530 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 13:08:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16146; Mon, 1 Jul 2002 12:30:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16099 for ; Mon, 1 Jul 2002 12:30:44 -0400 (EDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16658 for ; Mon, 1 Jul 2002 12:29:57 -0400 (EDT) Received: from harbour.india.hp.com (harbour.india.hp.com [15.76.114.31]) by palrel12.hp.com (Postfix) with ESMTP id 29AA7E004DC for ; Mon, 1 Jul 2002 09:30:13 -0700 (PDT) Received: from KRISHNAM (dhcp-15-204-127-36.grenoble.hp.com [15.204.127.36]) by harbour.india.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with SMTP id WAA29203 for ; Mon, 1 Jul 2002 22:09:49 +0530 (IST) Message-ID: <037c01c2211c$86de4630$247fcc0f@KRISHNAM> From: "Thalapathy" To: Date: Mon, 1 Jul 2002 18:29:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0379_01C2212D.489AE1B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [Sip] 481 response by a proxy ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0379_01C2212D.489AE1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1) The SIP RFC2543bis-09 only mentions 481 (call leg/transaction does not = exist) as a response generated by a UAS. I donot see any specific = mention of this non-2xx response generated by a proxy which had done = record-route for receiving mid-dialog requests like re-INVITE. 2) The SIP RFC2543bis-09 does not seem to discuss the behaviour of a dialog = stateful proxy. Does it mean, the handling of mid-dialog requests like = re-INVITEs is left to the implementation, in case there is no match = found on the dialog context ? Or should the dialog stateful proxy = behaviour be same as a UAS, in which case it should generate a 481 = response ? 3) What is the behaviour of a transaction stateful proxy (no dialog states = maintained) when it receives a re-INVITE on a secondary server = (identified by DNS) because of a primary server reboot. Does it create a = new client transaction, forward the re-INVITE to the next hop ? Does it = behave statelessly ? The RFC seems to be clear on handling a response = recieved at a transaction stateful proxy (which does not contain the = response context) by saying that the proxy MUST forward the response by = behaving as a stateless proxy. ------=_NextPart_000_0379_01C2212D.489AE1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
1)
 
The SIP RFC2543bis-09 only mentions 481 = (call=20 leg/transaction does not exist) as a response generated by a UAS. I = donot see=20 any specific mention of this non-2xx response generated by a proxy which = had=20 done record-route for receiving mid-dialog requests like = re-INVITE.
 
 
2)
The SIP RFC2543bis-09 does not seem to = discuss the=20 behaviour of a dialog stateful proxy. Does it mean, the handling of = mid-dialog=20 requests like re-INVITEs is left to the implementation, in case there is = no=20 match found on the dialog context ? Or should the dialog stateful proxy=20 behaviour be same as a UAS, in which case it should generate a 481 = response=20 ?
 
3)
 
What is the behaviour of a transaction = stateful=20 proxy (no dialog states maintained) when it receives a re-INVITE on a = secondary=20 server (identified by DNS) because of a primary server reboot. Does it = create a=20 new client transaction, forward the re-INVITE to the next hop ? Does it = behave=20 statelessly ? The RFC seems to be clear on handling a response recieved = at a=20 transaction stateful proxy (which does not contain the response context) = by=20 saying that the proxy MUST forward the response by behaving as a = stateless=20 proxy.
------=_NextPart_000_0379_01C2212D.489AE1B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 14:22:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23982 for ; Mon, 1 Jul 2002 14:22:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27431 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 14:23:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21999; Mon, 1 Jul 2002 13:32:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21968 for ; Mon, 1 Jul 2002 13:32:00 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.ivbnetworksolutions.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20720 for ; Mon, 1 Jul 2002 13:31:11 -0400 (EDT) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id MAA02021 for ; Mon, 01 Jul 2002 12:39:23 -0500 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Mon, 1 Jul 2002 12:25:45 -0500 Received: from bculpepperpc ([151.214.151.123]) by 172.16.16.64; Mon, 01 Jul 2002 12:31:08 -0500 From: "Bert Culpepper" To: "'Alexeitsev, D'" , Cc: Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Mon, 1 Jul 2002 13:30:22 -0400 Message-ID: <00a701c22124$fb98a760$7b97d697@bculpepperpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit comments inline... > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Alexeitsev, D > Sent: Monday, July 01, 2002 11:30 AM > To: christer.holmberg@lmf.ericsson.se > Cc: sip@ietf.org > Subject: Re: [Sip] Local vs Remote ringback on 180 > > > Hello > > a comment inline > > Greeting, > Denis Alexeitsev > > > -----Ursprüngliche Nachricht----- > > Von: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Gesendet am: Freitag, 28. Juni 2002 18:53 > > An: Chris Hogg > > Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson; > sip@ietf.org; > > Bob Penfield > > Betreff: Re: [Sip] Local vs Remote ringback on 180 > > > However, there is no specific "remote ringback session" in > SIP. You establish a generic early dialiog, by sending an > offer and receiving an answer, > > [DA]As the offer/answer draft says: one "MUST be prepared to > receive media" after the sending of the offer, so it does not > require for UAC to receive an answer in order to start the > media playback (as the early media, in my understanding, > always come from the UAS i.e. ringback tone, announcement,... > and not other way around) > We want the UAC to render received media once it's sent an offer to prevent clipping. We need this, it causes an unacceptable user experience if we don't do this. In addition, we don't want to require the UAS to provide "call progress" media, we have the 180 for it to indicate the callee is being alerted, the UAC can convey this state to the caller through local ringback or whatever. It's been proposed/discussed/and I believe there's consensus that a UAS will send 183 (or 180 recently) with SDP when it intends to present media that should be rendered to the caller. (Now this is not required of the UAS but it is "polite" in that it informs the UAC of its intentions.) The expected UAC behavior is for it to stop "ringback" indication at this point. Now there's the case when the UAS is doing something more with the session, and stops sending media to the UAC. In this case, the caller will not see/hear any "call progress". What's being asked for now is clarification on how to "ask" the UAC to again generate call progress indication. It's been suggested that another 18x without SDP indicate this scenario. As Christer indicated, there are some I-Ds that describe this behavior. There was a period in time where there seemed to be consensus in the WG on this. However, offer-answer, unify, ... I-Ds have since come along that more rigorously define "early dialogs", meaning of SDP, etc. And again, the presence of SDP in 18x has nothing to do with when a UAC should generate or expect session progress indications. AFAIK, it's not possible in SIP to indicate to a UAC that it should stop rendering media and go back to local generation of progress indication. Nor do we want to try to do this in SIP. IMHO, services/applications that will generate early media and then stop have the responsibility to make the caller's user experience acceptable (i.e., by playing an announcement, music, or whatever). In Christer's B2BUA example, the B2BUA's UAC assumes the responsibility to provide call progress indication to its user (which is another UAC). We should only recommend that a UAC generate a local indication upon receipt of a 180 and then stop upon receipt of media (which it should render). Services such as Christer's example must take it upon themselves to provide an acceptable user experience. Otherwise we add complexity to the protocol and degrade both interoperability and user experience. This is what I'd propose be the "official" clarification. My 2 cents anyway. Regards, Bert > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 15:44:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29074 for ; Mon, 1 Jul 2002 15:44:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06135 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 15:45:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03584; Mon, 1 Jul 2002 15:17:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23976 for ; Mon, 1 Jul 2002 13:46:45 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21694 for ; Mon, 1 Jul 2002 13:45:56 -0400 (EDT) Received: from host213-122-69-118.in-addr.btopenworld.com ([213.122.69.118] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 17P5Fo-0000Vu-00; Mon, 01 Jul 2002 18:46:24 +0100 Message-ID: <00a301c22127$76aebf00$0200000a@tkw> From: "Pete Cordell" To: "Cullen Jennings" , Cc: "Jonathan Rosenberg" References: Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat Date: Mon, 1 Jul 2002 18:24:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Simply because it is the agreed strategy of the pre-midcom design group to define something called SPAN. It may not look like SPAN-A, and it may look more like TURN, but there is a way to go before that happens. Much of the mentioned the lack of consensus has been down to a lack of reading rather than any identified technical issues, so I suggest we go with the agreed name rather than starting a bun fight before we've identified and discussed any technical problems. To do otherwise is just creating ill will at a time we don't need it (at least I'm assuming that people don't want it at this stage). Pete. ----- Original Message ----- From: "Cullen Jennings" To: "Pete Cordell" ; Cc: "Jonathan Rosenberg" Sent: 28 June 2002 19:35 Subject: RE: [Sip] Proposed change in draft-ietf-sip-nat > > My read of the SPAN document was it did not even represent consensus of the > design team much less the midcom WG. > > Why should references to TURN or SPAM be changed to just SPAN? > > Thanks, Cullen > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Pete > > Cordell > > Sent: Friday, June 28, 2002 2:16 AM > > To: Jonathan Rosenberg; sip@ietf.org > > Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat > > > > > > Sounds reasonable except that to be in line with the pre-midcom / midcom > > work all references to TURN should be to SPAN (Simple Protocol for > > Augmenting NATs), at least for the time being. > > > > For those that are interested, a candidate for SPAN is at: > > > > http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt > > > > But be advised that this is iteration 1 and so subject to change. > > > > Pete. > > > > ----- Original Message ----- > > From: "Jonathan Rosenberg" > > To: > > Sent: 28 June 2002 06:06 > > Subject: [Sip] Proposed change in draft-ietf-sip-nat > > > > > > > Folks, > > > > > > I would like to propose a change in draft-ietf-sip-nat. > > > > > > Right now, this document specifies two very independent and orthogonal > > > things. One of them is the rport parameter. This is a Via param that > > > makes sure that the SIP response gets routed back to the source IP and > > > port where the request came from. Without it, SIP over UDP doesn't work > > > through any NATs. It allows SIP to work like most other protocols in > > > terms of its port usage. I think its uncontroversial and should move > > > forward as is. > > > > > > THe other aspect is the Translate header. Its aimed at making > > > registrations work through NAT. However, there are several problems with > > > the Translate header right now: > > > > > > 1. It "competes" with other solutions, such as STUN and TURN/SPAN, which > > > would allow for incoming INVITEs through NAT without any SIP specific > > > extensions. > > > > > > 2. It tries to optimize for the full-cone case, by including a parameter > > > that indicates whether the client is behind a full-cone or symmetric > > > NAT. I would rather not pollute SIP with this kind of NAT-specific > > > stuff; rather, relegate it to STUN/TURN. > > > > > > 3. UDP registrations through NAT are really troublesome. They require > > > very frequent re-registrations to maintain the binding (under a minute). > > > This poses a serious load. If you have to use UDP, a STUN or TURN > > > solution is much better, since refreshes of the NAT bindings would occur > > > through those protocols, rather than SIP, and they scale much better. > > > So, if you consider TCP (which works even better still, since you don't > > > need to refresh the registration in order to keep the binding active), > > > the problem is not really translating the contact header as it is TCP > > > connection reuse for incoming requests. Indeed, the same problem occurs > > > in record-routing - you want to be able to specify to your peer to reuse > > > the connection for incoming requests. Thats not even a nat-specific > > > thing; its just a capability that, if we had a better story on, would be > > > useful for NAT. > > > > > > > > > As a result, I would propose that draft-ietf-sip-nat move forward with > > > just the rport stuff, and we look at the registration problem > > > separately. I would like a solution for SIP that didn't depend on > > > STUN/TURN, but I have convinced myself that this solution needs to be > > > TCP-based, and that it is best viewed as a problem of connection reuse. > > > ROhan has posted a requirement draft on that topic. > > > > > > Flame away.... > > > > > > -Jonathan R. > > > > > > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PH: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 17:42:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05519 for ; Mon, 1 Jul 2002 17:42:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14068 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 17:43:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12775; Mon, 1 Jul 2002 17:22:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12638 for ; Mon, 1 Jul 2002 17:22:02 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04029; Mon, 1 Jul 2002 17:21:13 -0400 (EDT) From: Tim.Moran@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g61LPaj16461; Mon, 1 Jul 2002 16:25:36 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Jul 2002 16:21:59 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Jul 2002 16:21:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 1 Jul 2002 16:21:17 -0500 Message-ID: <278B6B0D76698D45BBA872CD23DD496ADD60CB@daebe004.NOE.Nokia.com> Thread-Topic: Event Filtering Thread-Index: AcIhRTzTMoBotQQTTnyMMEkCGb+H0Q== To: , , , , Cc: , X-OriginalArrivalTime: 01 Jul 2002 21:21:18.0218 (UTC) FILETIME=[3D265EA0:01C22145] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA12641 Subject: [Sip] Event Filtering Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Adam/Robert/Siriram/Jonathan/Henning et. al, I don't watch the SIP list as much as I do the simple and sipping lists when a colleague told me of this discussion (extracted most of it from the SIP mail archive) to which I respond. I hope I haven't violated any rules by cc'ing the sipping list. Before diving into the technical, would this thread be more appropriate on the SIPPING list? Is it possible to define a useful general-purpose filtering mechanism? Yes - and No. If you mean one set of software that fits all - no. However, there is a good bit that can which includes: the structure, the verbs (operators) and maybe base type operations. There are some operations that don't rely on types defined in the applciation package. Time based operations are universally applicable (never say never and never say universally). There seems to be some interest to investigate the requirements and start the design(I'll use the term arhitecture). Architecture was chosen in the draft since we did not want to go so far as picking the implementation language (XML, SOAP, CPL, XSLT, ...). Personally, I do not care as long as it is reasonable. Admittedly, the XML we submitted in the appendix seemed like a reasonable compromise. Setting a realistic scope is an admirable goal. I get a little concerned when we say minimum functionality or realistic scope given what Jonathan proposed. What is minimum for one package will not be the same for another package - necessarily. I also point out that the architecture includes mechanisms to indicate what is not supported. Nowhere is it required to implement all the functions/operators etc. Each application/package will support what it wants to. There are hooks we defined for extensibility. However, this should be the exception and not the rule. Drawing the line for the base set of operations and extensions (as done in the draft) will be a bit tricky - but doable given the needs of the industry. For example, maybe all you need is an equality and a not operator. However, this will not satisfy the need of a watcher wanting to know when the list of buddies is greater than x or location has changed more than y. The math operators I concede are icing - but someone ma! y prove me wrong on this. Point is, what does it hurt if we now go ahead and definea fairly complete set of verbs? So far, the requirements I have seen proposed are: Rate limiting (time based & state/attribute change based){when} and content filtering {what}. I suggest a BAR BOF be held in Japan to discuss this further, e.g. a design team. Also, last I heard the moran-arch-draft was not on the agenda for Japan. Should it be? Regards, Tim Moran. Nokia Inc. To: Jonathan Rosenberg > * Subject: Re: [Sip] RE: Event Filtering * From: Henning Schulzrinne > * Date: Sun, 30 Jun 2002 16:26:50 -0400 * CC: Sriram Parameswar >, sip@ietf.org * List-Id: Session Initiation Protocol * Organization: Columbia University * References: > <3D1AC5E2.4030302@dynamicsoft.com > * Sender: sip-admin@ietf.org * User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 Jonathan Rosenberg wrote: > I acutally like the idea of a more generic filter/trigger mechanism that > would apply cross-packages. The tradeoff is one of generality vs. > complexity. The single mechanism will be more general, but probably more > complex than an event-specific one. How much more complex? Impossible to > say, of course. I generally favor generality, so if its not to omuch > more complex, I think its a good thing. However, unless you plan on > enumerating the set of filters and triggers allowed in a package, I > suspect that the general one won't be that much more complex. Saying > "only send me notifies once an hour on alternate thursdays, if the value > of the foo parameter is bar" is going to be complex in any case. CPL with the calsch extensions makes expressing alternate Thursdays very easy :-) > > I think the Moran draft is a good start, but not quite there yet. Part > of the problem is scope. What exactly do we wish to support, in terms of > filter/trigger policies? You don't want to boil the ocean with the first > version. I think that, if we go for a general solution, we should do > JUST enough to meet the *real* problems people are trying to solve, and > we can make it extensible to handle more down the road. > > I would postulate that, realistically, the scope of triggers is going to > be limited to: > > * waiting for a certain event to occur within a certain state, > * waiting for a certain variable to take a certain value > > Things like the mathematical and temporal conditions are interesting, > but I doubt would really be used in practice. Similarly, the filtering > conditions are probably limited to asking for notifications to contain > only certain variables. > > With a well scoped set of requirements, as I have proposed above, I > think you can get a pretty straightforward language that would apply > cross-packages. > > I'll also note that, if we assume that all notifications contain XML as > bodies (I know its not true, bear with me), then the filter could > possibly be an XSLT document. This might be overkill. For things that > are not XML, you'd need to specify an XML mapping for it to work (yuck). > Just a thought. > > So, I would propose that, in order to make progress on this issue, we > agree upon a realistic scope for these things, in terms of requirements > on filters and triggers, and then we can see how complex the > general-purpose filtering language is. We've also looked at extending CPL for presence (draft-wu-cpl-presence, I thin). The question is whether the same model makes sense for events. I don't think XSLT is the right choice. If anything, you want something like the XML Query language where you can formulate conditions on XML bodies. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 18:15:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06983 for ; Mon, 1 Jul 2002 18:15:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15371 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 18:16:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14354; Mon, 1 Jul 2002 17:52:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23981 for ; Mon, 1 Jul 2002 13:46:45 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21698 for ; Mon, 1 Jul 2002 13:45:56 -0400 (EDT) Received: from host213-122-69-118.in-addr.btopenworld.com ([213.122.69.118] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 17P5Fq-0000Vu-00; Mon, 01 Jul 2002 18:46:27 +0100 Message-ID: <00a401c22127$78079840$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , "Cullen Jennings" Cc: References: <3D1CC624.5050304@dynamicsoft.com> Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat Date: Mon, 1 Jul 2002 18:32:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jonathan Rosenberg" To: "Cullen Jennings" > > > Cullen Jennings wrote: > > My read of the SPAN document was it did not even represent consensus of > > the > > design team much less the midcom WG. > > Correct. Indeed and that's what the document says, so why the need to comment here? To go further, I am waiting VERY patiently for comments to come in for discussion. Much effort has been put in on my part to reach consensus using many small steps to try and bring the team along as a whole and I will continue to work with that goal in mind. Rest assured that this does not mean imposing my will on others, but where I believe I have valid technical issues, I will present them and look forward to them being discussed in an open (and technical) way. > > > > Why should references to TURN or SPAM be changed to just SPAN? > > More importantly, this issue is totally irrelevant to this thread. > Draft-ietf-sip-nat will have references to neither TURN, nor SPAN, nor > STUN. Connection reuse has nothing to do with it either. THe only place > TURN/SPAN/STUN should show up is the nat-scenarios document. That one is > on the backburner until these issues are sorted out, and is not what > this thread is about in any case. More than likely. So why not acknowledge the editorial error (which requires no action) and move on. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 1 18:46:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08214 for ; Mon, 1 Jul 2002 18:46:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17657 for sip-archive@odin.ietf.org; Mon, 1 Jul 2002 18:47:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16153; Mon, 1 Jul 2002 18:24:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16075 for ; Mon, 1 Jul 2002 18:24:43 -0400 (EDT) Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07324 for ; Mon, 1 Jul 2002 18:23:53 -0400 (EDT) Message-ID: <20020701222440.73975.qmail@web11601.mail.yahoo.com> Received: from [131.107.3.78] by web11601.mail.yahoo.com via HTTP; Mon, 01 Jul 2002 15:24:40 PDT Date: Mon, 1 Jul 2002 15:24:40 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] Event Filtering To: Tim.Moran@nokia.com, hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sriramp@nortelnetworks.com, adam@dynamicsoft.com, rsparks@dynamicsoft.com Cc: sipping@ietf.org, sip@ietf.org In-Reply-To: <278B6B0D76698D45BBA872CD23DD496ADD60CB@daebe004.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I tend to agree with Henning that if we focus on a solution for XML documents, then XML Query seems like the best candidate. The million dollar question is whether this is an appropriate scope of the problem. A BAR BOF on the topic seems like a good idea. Please include me on any scheduling e-mails for this :) Cheers sean > I suggest a BAR BOF be held in Japan to discuss > this further, e.g. a design team. Also, last I > heard the moran-arch-draft was not on the agenda for > Japan. Should it be? > Regards, > Tim Moran. Nokia Inc. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 2 00:47:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16637 for ; Tue, 2 Jul 2002 00:47:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA03320 for sip-archive@odin.ietf.org; Tue, 2 Jul 2002 00:48:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02301; Tue, 2 Jul 2002 00:23:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02272 for ; Tue, 2 Jul 2002 00:23:51 -0400 (EDT) Received: from btlmail.bplmail.com (PPP-89-47.bng.vsnl.net.in [202.54.89.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16166 for ; Tue, 2 Jul 2002 00:22:59 -0400 (EDT) Received: from [10.10.13.95] (helo=RaviRaj) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 17PF9b-0005wJ-00 for ; Tue, 02 Jul 2002 09:50:39 +0530 Message-ID: <002401c22180$73756880$5f0d0a0a@SIGMA> From: "Ranjit Avasarala" To: "sip-ietf" Date: Tue, 2 Jul 2002 09:55:09 +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 Content-Transfer-Encoding: 7bit Subject: [Sip] query on NOTIFY syntax Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi as per draft-ietf-sip-refer-05.txt , the Content Type in NOTIFY is message/sipfrag and contains the header Subscription-State But as per draft-rosenberg-sip-reg-00)1).txt, the Content Type in NOTIFY is application/reginfo+xml which one should be used? Actually my requirement is while implementing the feature of automatic callback by user A. user A subscribes to this feature and user A should be notified by the server when user B is free. I use Event: autoCallBackUserB In NOTIFY: subscription-state: "init" / "active" TIA Ranjit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 2 01:07:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16868 for ; Tue, 2 Jul 2002 01:07:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA07432 for sip-archive@odin.ietf.org; Tue, 2 Jul 2002 01:08:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03264; Tue, 2 Jul 2002 00:45:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03233 for ; Tue, 2 Jul 2002 00:45:53 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16605 for ; Tue, 2 Jul 2002 00:45:04 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g624jIYH026581; Tue, 2 Jul 2002 00:45:20 -0400 (EDT) Message-ID: <3D212FDC.1010002@dynamicsoft.com> Date: Tue, 02 Jul 2002 00:45:16 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: matrix@dasecurenetworks.com CC: Sean Olson , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] refreshing NAT binding for SIP with UDP registrations References: <3D1D0822.8FF164DC@infravast.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chris Martin wrote: > Jonathan Rosenberg wrote: > To clarify the latter comment SIP traversal solutions for the enterprise > that involves keep alives or topology discovery on enterprise firewalls > may be considered a violation of enterprise security policy, not to > mention the excess traffic, which is typically hunted down to be > silenced on many of these types of networks, and lastly the potential > risk of providing additional vulnerabilities to the internal network > that are yet unknown. Many infrastructures do not want internal users > having knowlege of the topology. Placing the ability to do so on a > client to determine this information may be frowned upon as well. I can only assume you are talking about STUN. STUN doesn't discover topology, it just determines whether or not there exist one or more NATs between the client and the public Internet. > > Anyway the firewall vendors have begun to provide SIP solutions to > address this now, so it is becoming a moot point. MIDCOM may provide a > way to offer additional support for many items other than firewalls, > such as load balancing devices etc, so this has much merit, but a > traversal solution, IMHO, is not necessary or acceptable, except in the > SOHO realm, if that. I disagree. You are assuming that the only solution an enterprise would find viable is an ALG or a midcom-controllable firewall. I think it is legitimate for an enterprise to decide to deploy SIP using one of several other approaches, all of which are documented in draft-ietf-sipping-nat-scenarios. One of these, for example, involves the deployment of a SIP server in the DMZ, along with a configuration change in the firewall. I claim that it should be possible to configure the firewall to support SIP without requiring that configuration to be excessively permissive; this basically means that SIP should be workable with client initiated "connections", much like many other application protocols, and that is the aim of this draft. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 2 04:02:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28129 for ; Tue, 2 Jul 2002 04:02:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20911 for sip-archive@odin.ietf.org; Tue, 2 Jul 2002 04:03:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18270; Tue, 2 Jul 2002 03:29:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18239 for ; Tue, 2 Jul 2002 03:29:37 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27460 for ; Tue, 2 Jul 2002 03:28:46 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g627TVRb020422; Tue, 2 Jul 2002 09:29:31 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g627TUa9019832; Tue, 2 Jul 2002 10:29:30 +0300 (EET DST) Message-ID: <3D21565A.91BE1512@lmf.ericsson.se> Date: Tue, 02 Jul 2002 10:29:30 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bert Culpepper CC: "'Alexeitsev, D'" , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <00a701c22124$fb98a760$7b97d697@bculpepperpc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Bert, Great mail! Thanks! > >However, there is no specific "remote ringback session" in > >SIP. You establish a generic early dialiog, by sending an > >offer and receiving an answer, > > > >[DA]As the offer/answer draft says: one "MUST be prepared to > >receive media" after the sending of the offer, so it does not > >require for UAC to receive an answer in order to start the > >media playback (as the early media, in my understanding, > >always come from the UAS i.e. ringback tone, announcement,... > >and not other way around) > > > We want the UAC to render received media once it's sent an offer to > prevent clipping. We need this, it causes an unacceptable user > experience if we don't do this. In addition, we don't want to require > the UAS to provide "call progress" media, we have the 180 for it to > indicate the callee is being alerted, the UAC can convey this state to > the caller through local ringback or whatever. It's been > proposed/discussed/and I believe there's consensus that a UAS will send > 183 (or 180 recently) with SDP when it intends to present media that > should be rendered to the caller. (Now this is not required of the UAS > but it is "polite" in that it informs the UAC of its intentions.) The > expected UAC behavior is for it to stop "ringback" indication at this > point. [CHH] True. But, this is the case where the UAC first generates local ringback, then starts receiving remote early media, and the case I've brought up is the oposit. Also, what you wrote was very much true until the media mode indicators (sendrecv, inactive etc) were introduced to SIP. Now, if a UAC sends an INVITE with "inactive", is it still a MUST for the UAC to be able to receive media at that point? One of the reason to use "inactive" was to PREVENT early media, so... > Now there's the case when the UAS is doing something more with the > session, and stops sending media to the UAC. In this case, the caller > will not see/hear any "call progress". What's being asked for now is > clarification on how to "ask" the UAC to again generate call progress > indication. It's been suggested that another 18x without SDP indicate > this scenario. As Christer indicated, there are some I-Ds that describe > this behavior. [CHH] To clarify, the drafts I refer to is bis-09 and the ISUP/SIP mapping draft. > There was a period in time where there seemed to be consensus in the WG on > this. However, offer-answer, unify, ... I-Ds > have since come along that more rigorously define "early dialogs", > meaning of SDP, etc. And again, the presence of SDP in 18x has nothing > to do with when a UAC should generate or expect session progress > indications. [CHH] True, and that is the reason I asked if the SDP as an ringback indicator (which it IS used as in some drafts) is a good idea in the first place. Like Bert said, those drafts were written long before anyone had heard of any offer/answer rules etc... > AFAIK, it's not possible in SIP to indicate to a UAC that > it should stop rendering media and go back to local generation of > progress indication. Nor do we want to try to do this in SIP. [CHH] If that is the case, the text in the drafts I refered to should be rewritten. I guess what you propose is: "When the UAC receives the 180 it does the ringback decission based on if there is an early media session established, and the state of it (sendrecv, inactive,...) - NOT based on if there is a SPD in the 180 or not (of course, the SDP in 180 may be the SDP used to establish the early media session, but that is a separate issue)." > IMHO, services/applications that will generate early media and then stop > have the responsibility to make the caller's user experience acceptable > (i.e., by playing an announcement, music, or whatever). In Christer's > B2BUA example, the B2BUA's UAC assumes the responsibility to provide > call progress indication to its user (which is another UAC). [CHH] If that's fine with those who are going to build/use such applications, it's fine with me :) I assumed, however, that people don't want the B2BUA to generate ringback tones on behalf of the SIP phones... And, I also think it could be a relatively common SIP application, so I don't think we're talking about a strange and weird scenarios... > We should only recommend that a UAC generate a local indication upon > receipt of a 180 and then stop upon receipt of media (which it should > render). Services such as Christer's example must take it upon > themselves to provide an acceptable user experience. Otherwise we add > complexity to the protocol and degrade both interoperability and user > experience. [CHH] I don't think the UAC shall "stop upon receipt of media". If the UAS starts sending media, it shall also send a 18x with an answer to the offer sent in INVITE to establish an early media session (or, an UPDATE it the early session already exists, but in "inactive" mode). I also would like to get a clarification if the offer/answer rules in bis-09 "allow" us to establish an early media session by sending the answer in an unreliable 18x? > This is what I'd propose be the "official" clarification. My 2 cents > anyway. [CHH] That's what I asked for :) Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 2 07:14:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03323 for ; Tue, 2 Jul 2002 07:14:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03438 for sip-archive@odin.ietf.org; Tue, 2 Jul 2002 07:15:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00581; Tue, 2 Jul 2002 06:36:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00548 for ; Tue, 2 Jul 2002 06:36:21 -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 GAA01921; Tue, 2 Jul 2002 06:35:30 -0400 (EDT) Message-Id: <200207021035.GAA01921@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 02 Jul 2002 06:35:30 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-sctp-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The Stream Control Transmission Protocol as a Transport for for the Session Initiation Protocol Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo Filename : draft-ietf-sip-sctp-03.txt Pages : 8 Date : 01-Jul-02 This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport between SIP entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sctp-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-sctp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sctp-03.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: <20020701152837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sctp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sctp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701152837.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 2 08:37:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06090 for ; Tue, 2 Jul 2002 08:37:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07801 for sip-archive@odin.ietf.org; Tue, 2 Jul 2002 08:38:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06121; Tue, 2 Jul 2002 08:07:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24081 for ; Tue, 2 Jul 2002 04:58:49 -0400 (EDT) Received: from web20508.mail.yahoo.com (web20508.mail.yahoo.com [216.136.226.143]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28874 for ; Tue, 2 Jul 2002 04:58:01 -0400 (EDT) Message-ID: <20020702085848.35399.qmail@web20508.mail.yahoo.com> Received: from [61.1.171.51] by web20508.mail.yahoo.com via HTTP; Tue, 02 Jul 2002 01:58:48 PDT Date: Tue, 2 Jul 2002 01:58:48 -0700 (PDT) From: Saroj Kumar To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Question on SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I have the following data. User name: 5088855003 Password: 5088855003 Realm : BroadWorks Uri: sip:10.15.66.133 Algorithm: MD5 Nonce: 1024027759288 I am using the following code for calculation of Response. char * pszNonce = "1024027759288"; char * pszCNonce = ""; char * pszUser = "5088855003"; char * pszRealm = "BroadWorks"; char * pszPass = "5088855003"; char * pszAlg = "md5"; char szNonceCount[9] = ""; char * pszMethod ="Get; char * pszQop =""; char * pszURI ="sip:10.15.66.133"; HASHHEX HA1; HASHHEX HA2 = ""; HASHHEX Response; DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce,pszCNonce, HA1); DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop, pszMethod, pszURI, HA2, Response); printf("Response = %s\n", Response); and getting the out put as 725a9146fa0eb8bd8fd709086f190c01 but I am expecting the result as b0f6dbce82b1fe5f9adf5d124179ec2a. Whatever examples I got in the net cNonce value is used, but in this case I don't have the cNonce as there is no qop. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 2 14:59:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08484 for ; Tue, 2 Jul 2002 14:59:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17290 for sip-archive@odin.ietf.org; Tue, 2 Jul 2002 15:00:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14274; Tue, 2 Jul 2002 14:16:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12523 for ; Tue, 2 Jul 2002 13:55:37 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04263; Tue, 2 Jul 2002 13:54:45 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 2 Jul 2002 10:55:00 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 10:55:00 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 2 Jul 2002 10:55:00 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 2 Jul 2002 10:54:59 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 2 Jul 2002 10:55:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Jul 2002 10:54:59 -0700 Message-ID: Thread-Topic: draft-mahy-sipping-connect-reuse-reqs-00 Thread-Index: AcIh8ZULkFLlsUEES4ScDqstLgWSkA== From: "Sean Olson" To: , , X-OriginalArrivalTime: 02 Jul 2002 17:55:00.0805 (UTC) FILETIME=[960CC750:01C221F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA12524 Subject: [Sip] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit This is a very interesting problem. Should the requirements include the ability to deal with intermediaries such as NAT/firewalls that may not strictly be SIP entities? Also, I wonder if the proxy-proxy connection problem is as critical as the UAC-proxy connection reuse problem. Might SCTP be a better solution for proxy-proxy connection management? Thanks, Sean Olson Microsoft http://www.microsoft.com/rtc _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 2 15:14:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09589 for ; Tue, 2 Jul 2002 15:14:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18318 for sip-archive@odin.ietf.org; Tue, 2 Jul 2002 15:15:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16009; Tue, 2 Jul 2002 14:36:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15977 for ; Tue, 2 Jul 2002 14:36:33 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.ivbnetworksolutions.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07015 for ; Tue, 2 Jul 2002 14:35:38 -0400 (EDT) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id NAA02236 for ; Tue, 02 Jul 2002 13:43:44 -0500 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Tue, 2 Jul 2002 13:30:08 -0500 Received: from bculpepperpc ([151.214.151.123]) by 172.16.16.64; Tue, 02 Jul 2002 13:35:41 -0500 From: "Bert Culpepper" To: "'Christer Holmberg'" Cc: "'Alexeitsev, D'" , Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Tue, 2 Jul 2002 14:34:49 -0400 Message-ID: <00cc01c221f7$27b30e80$7b97d697@bculpepperpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3D21565A.91BE1512@lmf.ericsson.se> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Christer, more of my comments below... Christer Holmberg wrote: > > Hi Bert, > > Great mail! Thanks! > > > >However, there is no specific "remote ringback session" in > > >SIP. You establish a generic early dialiog, by sending an > > >offer and receiving an answer, > > > > > >[DA]As the offer/answer draft says: one "MUST be prepared to > > >receive media" after the sending of the offer, so it does not > > >require for UAC to receive an answer in order to start the > > >media playback (as the early media, in my understanding, > > >always come from the UAS i.e. ringback tone, announcement,... > > >and not other way around) > > > > > > We want the UAC to render received media once it's sent an offer to > > prevent clipping. We need this, it causes an unacceptable user > > experience if we don't do this. In addition, we don't want > to require > > the UAS to provide "call progress" media, we have the 180 for it to > > indicate the callee is being alerted, the UAC can convey > this state to > > the caller through local ringback or whatever. It's been > > proposed/discussed/and I believe there's consensus that a > UAS will send > > 183 (or 180 recently) with SDP when it intends to present media that > > should be rendered to the caller. (Now this is not > required of the UAS > > but it is "polite" in that it informs the UAC of its > intentions.) The > > expected UAC behavior is for it to stop "ringback" > indication at this > > point. > > [CHH] True. But, this is the case where the UAC first generates local > ringback, then starts receiving remote early media, and the case > I've brought up is the oposit. > > Also, what you wrote was very much true until the media mode > indicators > (sendrecv, inactive etc) were introduced to SIP. Now, if a > UAC sends an > INVITE with "inactive", is it still a MUST for the UAC to be > able to receive > media at that point? One of the reason to use "inactive" was > to PREVENT > early media, so... Yes, the ability to now use "inactive" changes things. But if a UAC indicates "inactive" then there is no means to send the corresponding media streams. And the caller then can not see/hear far-end media-based progress indications. > > > Now there's the case when the UAS is doing something more with the > > session, and stops sending media to the UAC. In this case, > the caller > > will not see/hear any "call progress". What's being asked > for now is > > clarification on how to "ask" the UAC to again generate > call progress > > indication. It's been suggested that another 18x without > SDP indicate > > this scenario. As Christer indicated, there are some I-Ds > that describe > > this behavior. > > [CHH] To clarify, the drafts I refer to is bis-09 and the > ISUP/SIP mapping > draft. > > > There was a period in time where there seemed to be > consensus in the WG on > > this. However, offer-answer, unify, ... I-Ds > > have since come along that more rigorously define "early dialogs", > > meaning of SDP, etc. And again, the presence of SDP in 18x > has nothing > > to do with when a UAC should generate or expect session progress > > indications. > > [CHH] True, and that is the reason I asked if the SDP as an ringback > indicator (which it IS used as in some drafts) is a good idea > in the first > place. Like Bert said, those drafts were written long before > anyone had > heard of any offer/answer rules etc... I've glanced through bis-09 for a discussion on UAC behavior for 18x and didn't find anything on when or when not to generate ringback locally. The SIP/ISUP I-D describes this for PSTN gateways. Being that that I-D is dealing with PSTN interworking (where the far end typically provides audible call progress indications) a convention is needed that addresses when local vs. far-end call progress indication is needed. I'm a little behind in my SIP-ISUP reading but I think the precedures described therein apply to PSTN gateways and not general SIP UAs. Also, PSTN interworking is a distinct enough scenario that additional semantics (for 180 vs. 183 and presence of SDP) are OK (but only as far as gateways are concerned). > > > AFAIK, it's not possible in SIP to indicate to a UAC that > > it should stop rendering media and go back to local generation of > > progress indication. Nor do we want to try to do this in SIP. > > [CHH] If that is the case, the text in the drafts I refered > to should be > rewritten. I guess what you propose is: > > "When the UAC receives the 180 it does the ringback decission > based on if > there is an early media session established, and the state of > it (sendrecv, > inactive,...) - NOT based on if there is a SPD in the 180 or > not (of course, > the SDP in 180 may be the SDP used to establish the early > media session, but > that is a separate issue)." Again, I didn't find this kind of discussion in bis-09. I myself think some guidance (as you suggest above) would be helpful in a some I-D. Otherwise we have to debate this aspect on mailing lists :) > > > IMHO, services/applications that will generate early media > and then stop > > have the responsibility to make the caller's user > experience acceptable > > (i.e., by playing an announcement, music, or whatever). In > Christer's > > B2BUA example, the B2BUA's UAC assumes the responsibility to provide > > call progress indication to its user (which is another UAC). > > [CHH] If that's fine with those who are going to build/use such > applications, it's fine with me :) I assumed, however, that > people don't > want the B2BUA to generate ringback tones on behalf of the > SIP phones... > And, I also think it could be a relatively common SIP > application, so I > don't think we're talking about a strange and weird scenarios... Well, I think the B2BUA has to "manage" the callee in this case, given the absence within the protocol to tell a UAC to generate ringback (in the general case). I think it would be a useful capability but doubt attaching additional semantics to SDP presence and/or 180/183 is the way to do it. Currently it's only a MAY in bis-09 that a UAC generates local ringback upon receipt of a 180 anyway. > > > We should only recommend that a UAC generate a local indication upon > > receipt of a 180 and then stop upon receipt of media (which > it should > > render). Services such as Christer's example must take it upon > > themselves to provide an acceptable user experience. > Otherwise we add > > complexity to the protocol and degrade both > interoperability and user > > experience. > > [CHH] I don't think the UAC shall "stop upon receipt of > media". If the UAS > starts sending media, it shall also send a 18x with an answer > to the offer > sent in INVITE to establish an early media session (or, an > UPDATE it the > early session already exists, but in "inactive" mode). Again, AFAIK a UAS can send media to the UAC after receiving the UAC's SDP. No response is required to be sent back to the UAC. Sending a response with SDP is the "polite" thing to do IMHO as it's an explicit indication that the UAS will send media (and allows RTP/RTCP to "work"). I believe UAC behavior here is an largely an implementation issue, and what I said are my views on what will provide an acceptable user experience in the general case. If the SIP WG wants to define "operational semantics" for some protocol scenarios I'm OK with that. The subject of this thread is a good one IMHO, and I remember a time when this was discussed. > > I also would like to get a clarification if the offer/answer > rules in bis-09 > "allow" us to establish an early media session by sending the > answer in an > unreliable 18x? My read indicates answers MUST be in a reliable response, which is only 200 in bis-09. This is stated pretty clearly IMHO. I'm not sure what a "early media session" is but if you want to complete the offer-answer exchange prior to sending/receiving a 200 OK, then there's the 100-rel extension (as I'm sure you're aware :). Best regards, Bert > > > This is what I'd propose be the "official" clarification. > My 2 cents > > anyway. > > [CHH] That's what I asked for :) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 2 15:36:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10926 for ; Tue, 2 Jul 2002 15:36:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19725 for sip-archive@odin.ietf.org; Tue, 2 Jul 2002 15:36:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16907; Tue, 2 Jul 2002 14:53:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16878 for ; Tue, 2 Jul 2002 14:53:28 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08044 for ; Tue, 2 Jul 2002 14:52:38 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g62IqgCB014469; Tue, 2 Jul 2002 14:52:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 14:52:52 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2AA@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Ranjit Avasarala'" , sip-ietf Subject: RE: [Sip] query on NOTIFY syntax Date: Tue, 2 Jul 2002 14:52:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The content type depends on the package being used. draft-ietf-sip-refer-05 defines one package; draft-rosenberg-sip-reg-01 defines a different one. Your proposal to use a brand-new and feature-specific event package of "autoCallBackUserB" is unlikely to get any traction at all. There is, however, an event package that is being defined that includes all the functionality you need for an auto-callback feature. See draft-ietf-sipping-dialog-package-00. /a > -----Original Message----- > From: Ranjit Avasarala [mailto:ranjit.avasarala@bplmail.com] > Sent: Monday, July 01, 2002 23:25 > To: sip-ietf > Subject: [Sip] query on NOTIFY syntax > > > Hi > as per draft-ietf-sip-refer-05.txt , the Content Type in > NOTIFY is > message/sipfrag and contains the header Subscription-State > > But as per draft-rosenberg-sip-reg-00)1).txt, the Content > Type in NOTIFY is > application/reginfo+xml > > which one should be used? > > Actually my requirement is while implementing the feature of automatic > callback by user A. user A subscribes to this feature and > user A should be > notified by the server when user B is free. > > I use Event: autoCallBackUserB > > In NOTIFY: subscription-state: "init" / "active" > > TIA > Ranjit > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 3 03:43:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00894 for ; Wed, 3 Jul 2002 03:43:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18129 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 03:44:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14667; Wed, 3 Jul 2002 02:49:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14639 for ; Wed, 3 Jul 2002 02:49:52 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29880 for ; Wed, 3 Jul 2002 02:49:03 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g636npRb014333 for ; Wed, 3 Jul 2002 08:49:51 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g636noa9003895 for ; Wed, 3 Jul 2002 09:49:50 +0300 (EET DST) Message-ID: <3D229E8E.3046D203@lmf.ericsson.se> Date: Wed, 03 Jul 2002 09:49:50 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] To tags for stateless responses Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi! A small clarification question on generation of To tags: Bis-09 says that responses can be sent stateless (ie no transaction is created), but that retransmits of the request MUST create the same response every time - including the To tag. Now, one way to achieve this is to calculate the To tag as a hash from some headers in the request. However, chapter 19.3 in bis-09 says that the tag must be "cryptographically random with at least 32 bits of randomness". To me that means that we must also use some kind of random number when we create the hash, but how are we now going to make sure the result is the same every time (even if the header hash will be the same the random number will be different every time)??? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 3 05:41:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02641 for ; Wed, 3 Jul 2002 05:41:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA24623 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 05:42:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22985; Wed, 3 Jul 2002 05:07:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22955 for ; Wed, 3 Jul 2002 05:07:56 -0400 (EDT) Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02076 for ; Wed, 3 Jul 2002 05:07:07 -0400 (EDT) Received: from [10.10.13.95] (helo=RaviRaj) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 17Pg2t-0000lI-00; Wed, 03 Jul 2002 14:33:31 +0530 Message-ID: <016501c22271$23b1d120$5f0d0a0a@SIGMA> From: "Ranjit Avasarala" To: Cc: "sip-ietf" Date: Wed, 3 Jul 2002 14:38:04 +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 Content-Transfer-Encoding: 7bit Subject: [Sip] syntax of NOTIFY Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Jonathan As per draft the MIME type in NOTIFY should be application/reginfo+xml. but in draft on REFER MIME type for NOTIFy is given as message/sipfrag. so which one should be used? in my case say I want to register a particular event in the server, so can I use SUBSCRIBE / NOTIFY pair? with just plain mesaage and no xml. Thanks Ranjit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 3 05:50:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02724 for ; Wed, 3 Jul 2002 05:50:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA24746 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 05:51:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23127; Wed, 3 Jul 2002 05:10:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23096 for ; Wed, 3 Jul 2002 05:10:35 -0400 (EDT) Received: from seimg0.sei.co.jp (seimg0e.sei.co.jp [133.153.22.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02099 for ; Wed, 3 Jul 2002 05:09:43 -0400 (EDT) Received: from sei-is.sei.co.jp (sei-is.sei.co.jp [133.153.208.201]) by seimg0.sei.co.jp (8.11.6/3.7W) with ESMTP id g639AOd27763 for ; Wed, 3 Jul 2002 18:10:24 +0900 Received: from seimh1.seimh.sei.co.jp by sei-is.sei.co.jp (8.8.8/3.6W-02/02/99) id SAA00985; Wed, 3 Jul 2002 18:10:24 +0900 (JST) Received: from pop2.osaka.sei.co.jp ([133.153.206.3]) by seimh1.seimh.sei.co.jp (8.11.6/3.7W) with ESMTP id g6399FX20716 for ; Wed, 3 Jul 2002 18:09:15 +0900 Received: from [133.153.240.225] by pop2.osaka.sei.co.jp (8.8.8/R8-sei-generic/solaris-1.0-02/27/98) with ESMTP id SAA11943; Wed, 3 Jul 2002 18:10:18 +0900 (JST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 03 Jul 2002 18:10:06 +0900 From: Eiji Tomimura To: Message-ID: In-Reply-To: <20020702085848.35399.qmail@web20508.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question about ABNF for SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dear all, I have a question regarding ABNF for SIP. In bis-09, it defines that : rfc1123-date = wkday "," date1 SP time SP "GMT" Though, in RFC2616 "HTTP/1.1", it defines that: rfc1123-date = wkday "," SP date1 SP time SP "GMT" Is it intentional? Or, is it a bug of either side? Becauses our SIP layer is based on RFC2616 format, it reject Date header follows the format of bis-09 as syntax error. So I'm wondering which format should we use. Thanks in advance. Regards, - Eiji Tomimura -- Eiji Tomimura Senior Engineer Communications Technology Dept., Information Technology R&D Laboratories Sumitomo Electric Industries, Ltd. Phone: +81-6-6466-5643 Fax: +81-6-6466-5732 Email: tomimura@sei.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 3 07:23:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05773 for ; Wed, 3 Jul 2002 07:23:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01194 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 07:24:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26789; Wed, 3 Jul 2002 06:31:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26746 for ; Wed, 3 Jul 2002 06:31:03 -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 GAA03741; Wed, 3 Jul 2002 06:30:14 -0400 (EDT) Message-Id: <200207031030.GAA03741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Jul 2002 06:30:14 -0400 Subject: [Sip] I-D ACTION:draft-mahy-sip-join-and-fork-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Session Inititation Protocol (SIP) 'Join' Header Author(s) : R. Mahy, D. Petrie Filename : draft-mahy-sip-join-and-fork-01.txt Pages : 14 Date : 02-Jul-02 This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Barge-In', answering-machine-style 'Message Screening' and 'Call Center Monitoring'. Note that definition of these example features is non- normative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-sip-join-and-fork-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mahy-sip-join-and-fork-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mahy-sip-join-and-fork-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702151504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-sip-join-and-fork-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-sip-join-and-fork-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151504.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 3 08:03:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07898 for ; Wed, 3 Jul 2002 08:03:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03828 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 08:04:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01011; Wed, 3 Jul 2002 07:15:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00987 for ; Wed, 3 Jul 2002 07:15:55 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05544 for ; Wed, 3 Jul 2002 07:15:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Question about ABNF for SIP Date: Wed, 3 Jul 2002 06:15:01 -0500 Message-ID: <7E06D3212981524CA10D2A114937C41484AE62@NREXCH.netrake.net> Thread-Topic: [Sip] Question about ABNF for SIP Thread-Index: AcIic6ir/2YaSDwgTQGvom8tNEuPVAADxWKQ From: "Rob Phillips" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA00988 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit The problem is with the bis-09 definition. Check the examples in bis-09: from those, it's obvious the rule should be: rfc1123-date = wkday "," SP date1 SP time SP "GMT" - rob -----Original Message----- From: Eiji Tomimura [mailto:tomimura@sei.co.jp] Sent: Wednesday, July 03, 2002 4:10 AM To: sip@ietf.org Subject: [Sip] Question about ABNF for SIP Dear all, I have a question regarding ABNF for SIP. In bis-09, it defines that : rfc1123-date = wkday "," date1 SP time SP "GMT" Though, in RFC2616 "HTTP/1.1", it defines that: rfc1123-date = wkday "," SP date1 SP time SP "GMT" Is it intentional? Or, is it a bug of either side? Becauses our SIP layer is based on RFC2616 format, it reject Date header follows the format of bis-09 as syntax error. So I'm wondering which format should we use. Thanks in advance. Regards, - Eiji Tomimura -- Eiji Tomimura Senior Engineer Communications Technology Dept., Information Technology R&D Laboratories Sumitomo Electric Industries, Ltd. Phone: +81-6-6466-5643 Fax: +81-6-6466-5732 Email: tomimura@sei.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 08:30:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09473 for ; Wed, 3 Jul 2002 08:30:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05569 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 08:31:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03018; Wed, 3 Jul 2002 07:55:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11197 for ; Tue, 2 Jul 2002 22:31:26 -0400 (EDT) Received: from services1.dasecurenetworks.com (adsl-64-217-197-215.dsl.rcsntx.swbell.net [64.217.197.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29277 for ; Tue, 2 Jul 2002 22:30:38 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services1.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g6326UV11548; Tue, 2 Jul 2002 21:06:31 -0500 Message-ID: <3D22696D.F703582B@infravast.com> Date: Tue, 02 Jul 2002 22:03:09 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: matrix@dasecurenetworks.com CC: Jonathan Rosenberg , Sean Olson , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] refreshing NAT binding for SIP with UDP registrations References: <3D1D0822.8FF164DC@infravast.com> <3D212FDC.1010002@dynamicsoft.com> <3D226474.2AF12C62@infravast.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chris Martin wrote: > > Jonathan Rosenberg wrote: > > > > Chris Martin wrote: > > > Jonathan Rosenberg wrote: > > > > > To clarify the latter comment SIP traversal solutions for the enterprise > > > that involves keep alives or topology discovery on enterprise firewalls > > > may be considered a violation of enterprise security policy, not to > > > mention the excess traffic, which is typically hunted down to be > > > silenced on many of these types of networks, and lastly the potential > > > risk of providing additional vulnerabilities to the internal network > > > that are yet unknown. Many infrastructures do not want internal users > > > having knowlege of the topology. Placing the ability to do so on a > > > client to determine this information may be frowned upon as well. > > > > I can only assume you are talking about STUN. STUN doesn't discover > > topology, it just determines whether or not there exist one or more NATs > > between the client and the public Internet. > > I am not focusing on one implementation over another...many of them > provide this level of vulnerability. A client that uses mechanisms to > ascertain information of topology is an additional risk that many > enterprise, or for that matter any responsible network administrator, > would permit to be implemented. ^ Would not permit > > > > > > > > > Anyway the firewall vendors have begun to provide SIP solutions to > > > address this now, so it is becoming a moot point. MIDCOM may provide a > > > way to offer additional support for many items other than firewalls, > > > such as load balancing devices etc, so this has much merit, but a > > > traversal solution, IMHO, is not necessary or acceptable, except in the > > > SOHO realm, if that. > > > > I disagree. > > > > You are assuming that the only solution an enterprise would find viable > > is an ALG or a midcom-controllable firewall. I think it is legitimate > > for an enterprise to decide to deploy SIP using one of several other > > approaches, all of which are documented in > > draft-ietf-sipping-nat-scenarios. One of these, for example, involves > > the deployment of a SIP server in the DMZ, along with a configuration > > change in the firewall. > > Why deploy a SIP proxy in the DMZ if you can deploy or upgrade a > firewall that provides SIP functionality? The solutions being devloped > today range from ALG's to B2BUA type firewall solutions. In many cases > the B2BUA's can also act as standalone proxy/registrars at a minimum > cost, and they are capable of interoperability with external SIP > proxies. > > > I claim that it should be possible to configure > > the firewall to support SIP without requiring that configuration to be > > excessively permissive > > Thats exactly what I said about what the firewall vendors are doing...it > is not complicated and it is not overly permissive, and it does not > require additional physical proxy in the DMZ to provide the desired > functionality. > > Hence, the SIP enabled firewalls that are being developed and deployed > currently by well known and emerging vendors. These solutions provide > far better solutions that fit the enterprise model than those that > provide a discovery or traversal mechanism or the requirement of > additional boxes on the enterprise.. > > >; this basically means that SIP should be workable > > with client initiated "connections", much like many other application > > protocols, and that is the aim of this draft. > > Nothing like adding a denial of service tool to all of ones internal > clients. > > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 08:35:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09833 for ; Wed, 3 Jul 2002 08:35:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05780 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 08:36:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03578; Wed, 3 Jul 2002 08:00:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03539 for ; Wed, 3 Jul 2002 08:00:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07782 for ; Wed, 3 Jul 2002 07:59:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA18488; Wed, 3 Jul 2002 08:00:15 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA06493; Wed, 3 Jul 2002 08:00:17 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jul 2002 08:00:16 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B55F2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Eiji Tomimura'" , sip@ietf.org Subject: RE: [Sip] Question about ABNF for SIP Date: Wed, 3 Jul 2002 08:00:16 -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@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This problem has been reported before. We fixed it in the text of the forthcoming RFC. The SP is added. Brian > -----Original Message----- > From: Eiji Tomimura [mailto:tomimura@sei.co.jp] > Sent: Wednesday, July 03, 2002 5:10 AM > To: sip@ietf.org > Subject: [Sip] Question about ABNF for SIP > > > Dear all, > > I have a question regarding ABNF for SIP. > > In bis-09, it defines that : > rfc1123-date = wkday "," date1 SP time SP "GMT" > > Though, in RFC2616 "HTTP/1.1", it defines that: > rfc1123-date = wkday "," SP date1 SP time SP "GMT" > > Is it intentional? Or, is it a bug of either side? > > Becauses our SIP layer is based on RFC2616 format, it reject > Date header > follows the format of bis-09 as syntax error. So I'm > wondering which format > should we use. > > Thanks in advance. > > Regards, > - Eiji Tomimura > > -- > Eiji Tomimura > Senior Engineer > Communications Technology Dept., Information Technology R&D > Laboratories > Sumitomo Electric Industries, Ltd. > Phone: +81-6-6466-5643 Fax: +81-6-6466-5732 Email: > tomimura@sei.co.jp > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 09:24:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09835 for ; Wed, 3 Jul 2002 08:35:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05789 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 08:36:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03030; Wed, 3 Jul 2002 07:55:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09742 for ; Tue, 2 Jul 2002 22:09:51 -0400 (EDT) Received: from services1.dasecurenetworks.com (adsl-64-217-197-215.dsl.rcsntx.swbell.net [64.217.197.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28618 for ; Tue, 2 Jul 2002 22:09:02 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services1.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g631jHV11518; Tue, 2 Jul 2002 20:45:18 -0500 Message-ID: <3D226474.2AF12C62@infravast.com> Date: Tue, 02 Jul 2002 21:41:56 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: matrix@dasecurenetworks.com, Sean Olson , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] refreshing NAT binding for SIP with UDP registrations References: <3D1D0822.8FF164DC@infravast.com> <3D212FDC.1010002@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Chris Martin wrote: > > Jonathan Rosenberg wrote: > > > To clarify the latter comment SIP traversal solutions for the enterprise > > that involves keep alives or topology discovery on enterprise firewalls > > may be considered a violation of enterprise security policy, not to > > mention the excess traffic, which is typically hunted down to be > > silenced on many of these types of networks, and lastly the potential > > risk of providing additional vulnerabilities to the internal network > > that are yet unknown. Many infrastructures do not want internal users > > having knowlege of the topology. Placing the ability to do so on a > > client to determine this information may be frowned upon as well. > > I can only assume you are talking about STUN. STUN doesn't discover > topology, it just determines whether or not there exist one or more NATs > between the client and the public Internet. I am not focusing on one implementation over another...many of them provide this level of vulnerability. A client that uses mechanisms to ascertain information of topology is an additional risk that many enterprise, or for that matter any responsible network administrator, would permit to be implemented. > > > > > Anyway the firewall vendors have begun to provide SIP solutions to > > address this now, so it is becoming a moot point. MIDCOM may provide a > > way to offer additional support for many items other than firewalls, > > such as load balancing devices etc, so this has much merit, but a > > traversal solution, IMHO, is not necessary or acceptable, except in the > > SOHO realm, if that. > > I disagree. > > You are assuming that the only solution an enterprise would find viable > is an ALG or a midcom-controllable firewall. I think it is legitimate > for an enterprise to decide to deploy SIP using one of several other > approaches, all of which are documented in > draft-ietf-sipping-nat-scenarios. One of these, for example, involves > the deployment of a SIP server in the DMZ, along with a configuration > change in the firewall. Why deploy a SIP proxy in the DMZ if you can deploy or upgrade a firewall that provides SIP functionality? The solutions being devloped today range from ALG's to B2BUA type firewall solutions. In many cases the B2BUA's can also act as standalone proxy/registrars at a minimum cost, and they are capable of interoperability with external SIP proxies. > I claim that it should be possible to configure > the firewall to support SIP without requiring that configuration to be > excessively permissive Thats exactly what I said about what the firewall vendors are doing...it is not complicated and it is not overly permissive, and it does not require additional physical proxy in the DMZ to provide the desired functionality. Hence, the SIP enabled firewalls that are being developed and deployed currently by well known and emerging vendors. These solutions provide far better solutions that fit the enterprise model than those that provide a discovery or traversal mechanism or the requirement of additional boxes on the enterprise.. >; this basically means that SIP should be workable > with client initiated "connections", much like many other application > protocols, and that is the aim of this draft. Nothing like adding a denial of service tool to all of ones internal clients. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 09:41:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13057 for ; Wed, 3 Jul 2002 09:41:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10810 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 09:41:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08085; Wed, 3 Jul 2002 09:10:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08053 for ; Wed, 3 Jul 2002 09:10:04 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11287 for ; Wed, 3 Jul 2002 09:09:14 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g63D9xRb028616; Wed, 3 Jul 2002 15:09:59 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g63D9wa9006160; Wed, 3 Jul 2002 16:09:58 +0300 (EET DST) Message-ID: <3D22F7A6.4A64FFAA@lmf.ericsson.se> Date: Wed, 03 Jul 2002 16:09:58 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bert Culpepper CC: "'Alexeitsev, D'" , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <00cc01c221f7$27b30e80$7b97d697@bculpepperpc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Bert, As a conclusion to this discussion my proposal for a clarification would be that the local ringback generation depends on if a early media session has been established or not when the 180 arrives. And, IF a UAS sends early media, and then wants the UAC to generate local ringback, it first have to put the early media on hold, using UPDATE, then send 180 (the UAC MAY now generate local ringback, since there is no early media), and when the called party answers the UAS will first send a new UPDATE, to un-hold the media, then send 200 for the INVITE. I still think this process is very messy, and "much pain for little gain", but since that's the only way SIP allows us to do it I am not going to argue against it :) I still would like to get a clarification on the "UPDATE-and-buffering-of-200) issue I brought up, though :) Personally I see no reason why to buffer the 200, but the UAS may have to buffer the second UPDATE (used to un-hold the media) until it has completed the first UPDATE (used to put media on hold), which means there is again a chance of media clipping. Now, as Bert mentioned, the UAS may start sending early media without indicating it (sending 183 with SDP), and then still send 180 without SDP even if it sends early media, so in that case I guess there is a risk the local ringback WILL get mixed with the early media (but, we can get early media mixing in forking scenarios, anyway) - UNLESS the UAC is able to do some decissions based on detected media (I don't think that would work very well, but it's up to each implementor to decide for him/herself). Or, does anyone have another proposal? Thanks! Regards, Christer Holmberg Ericsson Finland Bert Culpepper wrote: > Hi Christer, > > more of my comments below... > > Christer Holmberg wrote: > > > > Hi Bert, > > > > Great mail! Thanks! > > > > > >However, there is no specific "remote ringback session" in > > > >SIP. You establish a generic early dialiog, by sending an > > > >offer and receiving an answer, > > > > > > > >[DA]As the offer/answer draft says: one "MUST be prepared to > > > >receive media" after the sending of the offer, so it does not > > > >require for UAC to receive an answer in order to start the > > > >media playback (as the early media, in my understanding, > > > >always come from the UAS i.e. ringback tone, announcement,... > > > >and not other way around) > > > > > > > > > We want the UAC to render received media once it's sent an offer to > > > prevent clipping. We need this, it causes an unacceptable user > > > experience if we don't do this. In addition, we don't want > > to require > > > the UAS to provide "call progress" media, we have the 180 for it to > > > indicate the callee is being alerted, the UAC can convey > > this state to > > > the caller through local ringback or whatever. It's been > > > proposed/discussed/and I believe there's consensus that a > > UAS will send > > > 183 (or 180 recently) with SDP when it intends to present media that > > > should be rendered to the caller. (Now this is not > > required of the UAS > > > but it is "polite" in that it informs the UAC of its > > intentions.) The > > > expected UAC behavior is for it to stop "ringback" > > indication at this > > > point. > > > > [CHH] True. But, this is the case where the UAC first generates local > > ringback, then starts receiving remote early media, and the case > > I've brought up is the oposit. > > > > Also, what you wrote was very much true until the media mode > > indicators > > (sendrecv, inactive etc) were introduced to SIP. Now, if a > > UAC sends an > > INVITE with "inactive", is it still a MUST for the UAC to be > > able to receive > > media at that point? One of the reason to use "inactive" was > > to PREVENT > > early media, so... > > Yes, the ability to now use "inactive" changes things. But if a UAC > indicates "inactive" then there is no means to send the corresponding > media streams. And the caller then can not see/hear far-end media-based > progress indications. > > > > > > Now there's the case when the UAS is doing something more with the > > > session, and stops sending media to the UAC. In this case, > > the caller > > > will not see/hear any "call progress". What's being asked > > for now is > > > clarification on how to "ask" the UAC to again generate > > call progress > > > indication. It's been suggested that another 18x without > > SDP indicate > > > this scenario. As Christer indicated, there are some I-Ds > > that describe > > > this behavior. > > > > [CHH] To clarify, the drafts I refer to is bis-09 and the > > ISUP/SIP mapping > > draft. > > > > > There was a period in time where there seemed to be > > consensus in the WG on > > > this. However, offer-answer, unify, ... I-Ds > > > have since come along that more rigorously define "early dialogs", > > > meaning of SDP, etc. And again, the presence of SDP in 18x > > has nothing > > > to do with when a UAC should generate or expect session progress > > > indications. > > > > [CHH] True, and that is the reason I asked if the SDP as an ringback > > indicator (which it IS used as in some drafts) is a good idea > > in the first > > place. Like Bert said, those drafts were written long before > > anyone had > > heard of any offer/answer rules etc... > > I've glanced through bis-09 for a discussion on UAC behavior for 18x and > didn't find anything on when or when not to generate ringback locally. > The SIP/ISUP I-D describes this for PSTN gateways. Being that that I-D > is dealing with PSTN interworking (where the far end typically provides > audible call progress indications) a convention is needed that addresses > when local vs. far-end call progress indication is needed. I'm a little > behind in my SIP-ISUP reading but I think the precedures described > therein apply to PSTN gateways and not general SIP UAs. Also, PSTN > interworking is a distinct enough scenario that additional semantics > (for 180 vs. 183 and presence of SDP) are OK (but only as far as > gateways are concerned). > > > > > > AFAIK, it's not possible in SIP to indicate to a UAC that > > > it should stop rendering media and go back to local generation of > > > progress indication. Nor do we want to try to do this in SIP. > > > > [CHH] If that is the case, the text in the drafts I refered > > to should be > > rewritten. I guess what you propose is: > > > > "When the UAC receives the 180 it does the ringback decission > > based on if > > there is an early media session established, and the state of > > it (sendrecv, > > inactive,...) - NOT based on if there is a SPD in the 180 or > > not (of course, > > the SDP in 180 may be the SDP used to establish the early > > media session, but > > that is a separate issue)." > > Again, I didn't find this kind of discussion in bis-09. I myself think > some guidance (as you suggest above) would be helpful in a some I-D. > Otherwise we have to debate this aspect on mailing lists :) > > > > > > IMHO, services/applications that will generate early media > > and then stop > > > have the responsibility to make the caller's user > > experience acceptable > > > (i.e., by playing an announcement, music, or whatever). In > > Christer's > > > B2BUA example, the B2BUA's UAC assumes the responsibility to provide > > > call progress indication to its user (which is another UAC). > > > > [CHH] If that's fine with those who are going to build/use such > > applications, it's fine with me :) I assumed, however, that > > people don't > > want the B2BUA to generate ringback tones on behalf of the > > SIP phones... > > And, I also think it could be a relatively common SIP > > application, so I > > don't think we're talking about a strange and weird scenarios... > > Well, I think the B2BUA has to "manage" the callee in this case, given > the absence within the protocol to tell a UAC to generate ringback (in > the general case). I think it would be a useful capability but doubt > attaching additional semantics to SDP presence and/or 180/183 is the way > to do it. Currently it's only a MAY in bis-09 that a UAC generates > local ringback upon receipt of a 180 anyway. > > > > > > We should only recommend that a UAC generate a local indication upon > > > receipt of a 180 and then stop upon receipt of media (which > > it should > > > render). Services such as Christer's example must take it upon > > > themselves to provide an acceptable user experience. > > Otherwise we add > > > complexity to the protocol and degrade both > > interoperability and user > > > experience. > > > > [CHH] I don't think the UAC shall "stop upon receipt of > > media". If the UAS > > starts sending media, it shall also send a 18x with an answer > > to the offer > > sent in INVITE to establish an early media session (or, an > > UPDATE it the > > early session already exists, but in "inactive" mode). > > Again, AFAIK a UAS can send media to the UAC after receiving the UAC's > SDP. No response is required to be sent back to the UAC. Sending a > response with SDP is the "polite" thing to do IMHO as it's an explicit > indication that the UAS will send media (and allows RTP/RTCP to "work"). > > I believe UAC behavior here is an largely an implementation issue, and > what I said are my views on what will provide an acceptable user > experience in the general case. If the SIP WG wants to define > "operational semantics" for some protocol scenarios I'm OK with that. > The subject of this thread is a good one IMHO, and I remember a time > when this was discussed. > > > > > I also would like to get a clarification if the offer/answer > > rules in bis-09 > > "allow" us to establish an early media session by sending the > > answer in an > > unreliable 18x? > > My read indicates answers MUST be in a reliable response, which is only > 200 in bis-09. This is stated pretty clearly IMHO. I'm not sure what a > "early media session" is but if you want to complete the offer-answer > exchange prior to sending/receiving a 200 OK, then there's the 100-rel > extension (as I'm sure you're aware :). > > Best regards, > Bert > > > > > > This is what I'd propose be the "official" clarification. > > My 2 cents > > > anyway. > > > > [CHH] That's what I asked for :) > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 14:45:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28429 for ; Wed, 3 Jul 2002 14:45:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01766 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 14:45:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21735; Wed, 3 Jul 2002 12:03:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21685 for ; Wed, 3 Jul 2002 12:03:47 -0400 (EDT) Received: from brmx1.fl.icn.siemens.com ([12.147.96.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19626 for ; Wed, 3 Jul 2002 12:02:59 -0400 (EDT) Received: from boca210a.boca.ssc.siemens.com (boca210a.boca.ssc.siemens.com [165.218.12.110]) by brmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id MAA12356; Wed, 3 Jul 2002 12:01:45 -0400 (EDT) Received: by boca210a.boca.ssc.siemens.com with Internet Mail Service (5.5.2653.19) id <311P3DJ4>; Wed, 3 Jul 2002 12:01:45 -0400 Message-ID: From: "Mahey, Sonit" To: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] p-asserted-identity security harmful Date: Wed, 3 Jul 2002 12:01:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, Pardon me for jumping in late in this discussion. I am missing the rationale behind the choice of TLS as opposed to IPSec. However, one issue still remains pertinet to both - that of PKI. Packet Cable incidently, adopts Kerberos as key management on a few interfaces. First off, is SIP trying to mandate something for security? If yes, why not adopt IPSec and use Kerberos for Key management, just like PacketCable? Thanks. - sonit Sonit Mahey, Systems Architect, Siemens TGOS, *: 10 Technology Park Dr., Westford, MA 01886 ': 978.923.3271 *: Sonit.Mahey@icn.siemens.com http://www.siemens.com -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, July 03, 2002 11:41 AM To: sip@ietf.org Subject: [Sip] p-asserted-identity security harmful From Section 11.3 of draft-ietf-sip-asserted-identity-01: > Connections between nodes within the Trust Domain and between UAs and > nodes in the Trust Domain MUST use TLS using a cipher suite of > RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in the > trust domain MUST be performed and confidentiality MUST be negotiated. > It's just come to my attention that TLS was mandated in the asserted identity draft. Not only was TLS mandated, but certain cipher suites and _AUTHENTICATION_ mechanisms were made necessary not only to implement, but to deploy. This is utterly bogus. This also places new requirements on UA's, which are not part of the base SIP spec. That too is bogus, and has been slipped in with no discussion. First, it ignores the possible use of IPsec as an alternate mechanism to protect the bits on the wire, but far more bogus doesn't allow for the proper latitude with authentication mechanisms needed in real life. I know that a lot of people here think that the PKI kool aide is going to solve world thirst, but reality has shown that to be a complete myth. SIP should not be mandating things for *deployment* which are manifestly undeployable as the only possible mechanism. Thirdly, it places new requirements on UA's of not only implementation, but *deployment* as well. This is extremely harmful. This section should either be struck in its entirety, or refer back to the base SIP spec's proxy requirements (which are likely to be harmful too, but at least the damage will be limited to a single document). Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 14:48:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28711 for ; Wed, 3 Jul 2002 14:48:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02292 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 14:49:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18924; Wed, 3 Jul 2002 11:41:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18895 for ; Wed, 3 Jul 2002 11:41:02 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18675 for ; Wed, 3 Jul 2002 11:40:14 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g63FeVvb014391 for ; Wed, 3 Jul 2002 08:40:31 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABZ52670; Wed, 3 Jul 2002 08:37:46 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20201; Wed, 3 Jul 2002 08:40:31 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15651.6895.188504.414727@thomasm-u1.cisco.com> Date: Wed, 3 Jul 2002 08:40:31 -0700 (PDT) To: sip@ietf.org 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! Content-Transfer-Encoding: 7bit Subject: [Sip] p-asserted-identity security harmful Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit From Section 11.3 of draft-ietf-sip-asserted-identity-01: > Connections between nodes within the Trust Domain and between UAs and > nodes in the Trust Domain MUST use TLS using a cipher suite of > RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in the > trust domain MUST be performed and confidentiality MUST be negotiated. > It's just come to my attention that TLS was mandated in the asserted identity draft. Not only was TLS mandated, but certain cipher suites and _AUTHENTICATION_ mechanisms were made necessary not only to implement, but to deploy. This is utterly bogus. This also places new requirements on UA's, which are not part of the base SIP spec. That too is bogus, and has been slipped in with no discussion. First, it ignores the possible use of IPsec as an alternate mechanism to protect the bits on the wire, but far more bogus doesn't allow for the proper latitude with authentication mechanisms needed in real life. I know that a lot of people here think that the PKI kool aide is going to solve world thirst, but reality has shown that to be a complete myth. SIP should not be mandating things for *deployment* which are manifestly undeployable as the only possible mechanism. Thirdly, it places new requirements on UA's of not only implementation, but *deployment* as well. This is extremely harmful. This section should either be struck in its entirety, or refer back to the base SIP spec's proxy requirements (which are likely to be harmful too, but at least the damage will be limited to a single document). Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 14:57:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29286 for ; Wed, 3 Jul 2002 14:57:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03388 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 14:58:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28575; Wed, 3 Jul 2002 14:14:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28544 for ; Wed, 3 Jul 2002 14:14:23 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25317 for ; Wed, 3 Jul 2002 14:13:33 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g63Gq2r33417; Wed, 3 Jul 2002 11:52:02 -0500 (CDT) Message-ID: <3D232B9B.7060407@dynamicsoft.com> Date: Wed, 03 Jul 2002 11:51:39 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org References: <5.1.0.14.0.20020703142040.033c0fb8@iptel.org> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: MESSAGE advertising in REGISTERs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Certainly it will be needed to make many server related scenarios work. It is optional because MESSAGE can also be used in a pure end-to-end mode without assuming that such servers exist. For example, a MESSAGE UAC may discover the contact for a MESSAGE UAS from presence information (i.e. a contact in a presence doc), then send the MESSAGE request directly with no intervening servers. In this architecture, there is not necessarily a need to advertise support at a registrar. Jiri Kuthan wrote: > Can someone tell me why the MESSAGE I-D mandates advertising > of support in REGISTERs of a MESSAGE-capable UAC only *optionally*? > > Making it optional gains little knowledge to a SIP server -- a server > does not know anything it could reliably use in its processing logic. > > Think of a SIP server which acts as a proxy server and message store. > If it knew, that downstream UAS was not capable of processing MESSAGEs, > it could immediately store an incoming MESSAGE, send 202 upstream, > and relay the message to first UAC which registers and advertises support > for MESSAGE in REGISTER. > > Because the server does not know it, it has to relay unnecessarily > a message to an upstream UAS, which will deny it. Then, whenever > a REGISTER arrives, the server will try to dump message store to it, > (hoping a UAC capable of MESSAGE registered) resulting in quite > uneffective behaviour. > > -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 14:57:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29303 for ; Wed, 3 Jul 2002 14:57:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03434 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 14:58:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26386; Wed, 3 Jul 2002 13:52:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26311 for ; Wed, 3 Jul 2002 13:51:58 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23762 for ; Wed, 3 Jul 2002 13:51:09 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g63Hd5CB020554; Wed, 3 Jul 2002 13:39:05 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 13:39:16 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2B2@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Ranjit Avasarala'" , Jonathan Rosenberg Cc: sip-ietf Subject: RE: [Sip] syntax of NOTIFY Date: Wed, 3 Jul 2002 13:39:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Ranjit: I answered your question already, both on the list and in a mail sent directly to you. Please read and understand what I sent before asking your question again. /a > -----Original Message----- > From: Ranjit Avasarala [mailto:ranjit.avasarala@bplmail.com] > Sent: Wednesday, July 03, 2002 4:08 > To: jdrosen@dynamicsoft.com > Cc: sip-ietf > Subject: [Sip] syntax of NOTIFY > > > Hi Jonathan > > As per draft the MIME type in NOTIFY should be > application/reginfo+xml. > but in draft on REFER MIME type for NOTIFy is given as > message/sipfrag. > > so which one should be used? > > in my case say I want to register a particular event in the > server, so can I > use SUBSCRIBE / NOTIFY pair? > with just plain mesaage and no xml. > > Thanks > Ranjit > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 15:02:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29640 for ; Wed, 3 Jul 2002 15:02:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04603 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 15:03:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28997; Wed, 3 Jul 2002 14:20:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28937 for ; Wed, 3 Jul 2002 14:20:19 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25765 for ; Wed, 3 Jul 2002 14:19:29 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g63IKGr39440; Wed, 3 Jul 2002 13:20:16 -0500 (CDT) Message-ID: <3D234048.8080502@dynamicsoft.com> Date: Wed, 03 Jul 2002 13:19:52 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org References: <5.1.0.14.0.20020703142040.033c0fb8@iptel.org> <5.1.0.14.0.20020703200900.00b3d110@iptel.org> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: MESSAGE advertising in REGISTERs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit What if there is no registrar? Jiri Kuthan wrote: > Though advertising MESSAGE capability in REGISTERs does > not hurt in any scenario, not advertising hurts in some. > That's why I would much prefer having it as a MUST. > > -Jiri > > At 06:51 PM 7/3/2002, Ben Campbell wrote: > >>Certainly it will be needed to make many server related scenarios work. It is optional because MESSAGE can also be used in a pure end-to-end mode without assuming that such servers exist. For example, a MESSAGE UAC may discover the contact for a MESSAGE UAS from presence information (i.e. a contact in a presence doc), then send the MESSAGE request directly with no intervening servers. In this architecture, there is not necessarily a need to advertise support at a registrar. >> >>Jiri Kuthan wrote: >> >>>Can someone tell me why the MESSAGE I-D mandates advertising >>>of support in REGISTERs of a MESSAGE-capable UAC only *optionally*? >>>Making it optional gains little knowledge to a SIP server -- a server does not know anything it could reliably use in its processing logic. >>>Think of a SIP server which acts as a proxy server and message store. >>>If it knew, that downstream UAS was not capable of processing MESSAGEs, >>>it could immediately store an incoming MESSAGE, send 202 upstream, >>>and relay the message to first UAC which registers and advertises support >>>for MESSAGE in REGISTER. >>>Because the server does not know it, it has to relay unnecessarily a message to an upstream UAS, which will deny it. Then, whenever a REGISTER arrives, the server will try to dump message store to it, >>>(hoping a UAC capable of MESSAGE registered) resulting in quite >>>uneffective behaviour. >>>-Jiri >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 15:07:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00079 for ; Wed, 3 Jul 2002 15:07:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05272 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 15:08:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28507; Wed, 3 Jul 2002 14:13:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28474 for ; Wed, 3 Jul 2002 14:13:20 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25243 for ; Wed, 3 Jul 2002 14:12:30 -0400 (EDT) Received: from jku2.fokus.gmd.de (port-212-202-172-117.reverse.qdsl-home.de [212.202.172.117]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g63ICeC29579; Wed, 3 Jul 2002 20:12:40 +0200 Message-Id: <5.1.0.14.0.20020703200900.00b3d110@iptel.org> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Jul 2002 20:12:37 +0200 To: Ben Campbell From: Jiri Kuthan Cc: sip@ietf.org In-Reply-To: <3D232B9B.7060407@dynamicsoft.com> References: <5.1.0.14.0.20020703142040.033c0fb8@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Re: MESSAGE advertising in REGISTERs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Though advertising MESSAGE capability in REGISTERs does not hurt in any scenario, not advertising hurts in some. That's why I would much prefer having it as a MUST. -Jiri At 06:51 PM 7/3/2002, Ben Campbell wrote: >Certainly it will be needed to make many server related scenarios work. It is optional because MESSAGE can also be used in a pure end-to-end mode without assuming that such servers exist. For example, a MESSAGE UAC may discover the contact for a MESSAGE UAS from presence information (i.e. a contact in a presence doc), then send the MESSAGE request directly with no intervening servers. In this architecture, there is not necessarily a need to advertise support at a registrar. > >Jiri Kuthan wrote: >>Can someone tell me why the MESSAGE I-D mandates advertising >>of support in REGISTERs of a MESSAGE-capable UAC only *optionally*? >>Making it optional gains little knowledge to a SIP server -- a server does not know anything it could reliably use in its processing logic. >>Think of a SIP server which acts as a proxy server and message store. >>If it knew, that downstream UAS was not capable of processing MESSAGEs, >>it could immediately store an incoming MESSAGE, send 202 upstream, >>and relay the message to first UAC which registers and advertises support >>for MESSAGE in REGISTER. >>Because the server does not know it, it has to relay unnecessarily a message to an upstream UAS, which will deny it. Then, whenever a REGISTER arrives, the server will try to dump message store to it, >>(hoping a UAC capable of MESSAGE registered) resulting in quite >>uneffective behaviour. >>-Jiri > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 16:24:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04919 for ; Wed, 3 Jul 2002 16:24:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11470 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 16:25:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09939; Wed, 3 Jul 2002 16:01:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09165 for ; Wed, 3 Jul 2002 15:56:32 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03442; Wed, 3 Jul 2002 15:55:35 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g63JuPE27020; Wed, 3 Jul 2002 12:56:25 -0700 (PDT) Message-Id: <200207031956.g63JuPE27020@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 03 Jul 2002 12:56:24 -0700 Subject: [Sip] RFC 3265 on Session Initiation Protocol (SIP)-Specific Event Notification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3265 Title: Session Initiation Protocol (SIP)-Specific Event Notification Author(s): A. B. Roach Status: Standards Track Date: June 2002 Mailbox: adam@dynamicsoft.com Pages: 38 Characters: 89005 Obsoletes: 2543 I-D Tag: draft-ietf-sip-events-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3265.txt This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Concrete uses of the mechanism described in this document may be standardized in the future. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020703125449.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3265 --OtherAccess Content-Type: Message/External-body; name="rfc3265.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020703125449.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 16:32:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05341 for ; Wed, 3 Jul 2002 16:32:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12289 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 16:33:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09883; Wed, 3 Jul 2002 16:01:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09088 for ; Wed, 3 Jul 2002 15:54:29 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03356; Wed, 3 Jul 2002 15:53:33 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g63JsLE26626; Wed, 3 Jul 2002 12:54:22 -0700 (PDT) Message-Id: <200207031954.g63JsLE26626@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 03 Jul 2002 12:54:21 -0700 Subject: [Sip] RFC 3264 on An Offer/Answer Model with the Session Description Protocol (SDP) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3264 Title: An Offer/Answer Model with Session Description Protocol (SDP) Author(s): J. Rosenberg, H. Schulzrinne Status: Standards Track Date: June 2002 Mailbox: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Pages: 25 Characters: 60854 Obsoletes: 2543 I-D Tag: draft-ietf-mmusic-sdp-offer-answer-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3264.txt This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020703125236.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3264 --OtherAccess Content-Type: Message/External-body; name="rfc3264.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020703125236.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 16:32:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05353 for ; Wed, 3 Jul 2002 16:32:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12300 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 16:33:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09818; Wed, 3 Jul 2002 16:01:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08640 for ; Wed, 3 Jul 2002 15:47:49 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02983; Wed, 3 Jul 2002 15:46:55 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g63JliE22635; Wed, 3 Jul 2002 12:47:44 -0700 (PDT) Message-Id: <200207031947.g63JliE22635@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 03 Jul 2002 12:47:44 -0700 Subject: [Sip] RFC 3261 on SIP: Session Initiation Protocol Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3261 Title: SIP: Session Initiation Protocol Author(s): J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler Status: Standards Track Date: June 2002 Mailbox: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, Gonzalo.Camarillo@ericsson.com, alan.johnston@wcom.com, jon.peterson@neustar.com, rsparks@dynamicsoft.com, mjh@icir.org, schooler@research.att.com Pages: 266 Characters: 647976 Obsoletes: 2543 I-D Tag: draft-ietf-sip-rfc2543bis-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3261.txt This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020703124440.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3261 --OtherAccess Content-Type: Message/External-body; name="rfc3261.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020703124440.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 16:32:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05370 for ; Wed, 3 Jul 2002 16:32:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12316 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 16:33:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09844; Wed, 3 Jul 2002 16:01:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08809 for ; Wed, 3 Jul 2002 15:50:07 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03181; Wed, 3 Jul 2002 15:49:12 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g63Jo1E25100; Wed, 3 Jul 2002 12:50:01 -0700 (PDT) Message-Id: <200207031950.g63Jo1E25100@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 03 Jul 2002 12:50:01 -0700 Subject: [Sip] RFC 3262 on Reliability of Provisional Responses in the Session Initiation Protocol (SIP) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3262 Title: Reliability of Provisional Responses in Session Initiation Protocol (SIP) Author(s): jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Status: Standards Track Date: June 2002 Mailbox: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Pages: 14 Characters: 29643 Obsoletes: 2543 I-D Tag: draft-ietf-sip-100rel-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3262.txt This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020703124812.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3262 --OtherAccess Content-Type: Message/External-body; name="rfc3262.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020703124812.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 16:35:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05486 for ; Wed, 3 Jul 2002 16:35:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12412 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 16:35:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09857; Wed, 3 Jul 2002 16:01:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06627 for ; Wed, 3 Jul 2002 08:58:13 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10681 for ; Wed, 3 Jul 2002 08:57:23 -0400 (EDT) Received: from jku2.iptel.org (port-212-202-172-117.reverse.qdsl-home.de [212.202.172.117]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g63CveC23839; Wed, 3 Jul 2002 14:57:40 +0200 Message-Id: <5.1.0.14.0.20020703142040.033c0fb8@iptel.org> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Jul 2002 14:57:37 +0200 To: sip@ietf.org From: Jiri Kuthan Cc: bcampbell@dynamicsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] MESSAGE advertising in REGISTERs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Can someone tell me why the MESSAGE I-D mandates advertising of support in REGISTERs of a MESSAGE-capable UAC only *optionally*? Making it optional gains little knowledge to a SIP server -- a server does not know anything it could reliably use in its processing logic. Think of a SIP server which acts as a proxy server and message store. If it knew, that downstream UAS was not capable of processing MESSAGEs, it could immediately store an incoming MESSAGE, send 202 upstream, and relay the message to first UAC which registers and advertises support for MESSAGE in REGISTER. Because the server does not know it, it has to relay unnecessarily a message to an upstream UAS, which will deny it. Then, whenever a REGISTER arrives, the server will try to dump message store to it, (hoping a UAC capable of MESSAGE registered) resulting in quite uneffective behaviour. -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 16:35:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05508 for ; Wed, 3 Jul 2002 16:35:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12429 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 16:36:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09737; Wed, 3 Jul 2002 16:01:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08969 for ; Wed, 3 Jul 2002 15:52:20 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03287; Wed, 3 Jul 2002 15:51:25 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g63JqEE25831; Wed, 3 Jul 2002 12:52:14 -0700 (PDT) Message-Id: <200207031952.g63JqEE25831@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 03 Jul 2002 12:52:14 -0700 Subject: [Sip] RFC 3263 on Session Initiation Protocol (SIP): Locating SIP Servers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3263 Title: Session Initiation Protocol (SIP): Locating SIP Servers Author(s): J. Rosenberg, H. Schulzrinne Status: Standards Track Date: June 2002 Mailbox: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Pages: 17 Characters: 42310 Obsoletes: 2543 I-D Tag: draft-ietf-sip-srv-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3263.txt The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020703125030.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3263 --OtherAccess Content-Type: Message/External-body; name="rfc3263.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020703125030.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 16:41:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05857 for ; Wed, 3 Jul 2002 16:41:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13039 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 16:41:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10863; Wed, 3 Jul 2002 16:13:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10729 for ; Wed, 3 Jul 2002 16:11:56 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04218; Wed, 3 Jul 2002 16:11:01 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g63KBoE03075; Wed, 3 Jul 2002 13:11:50 -0700 (PDT) Message-Id: <200207032011.g63KBoE03075@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 03 Jul 2002 13:11:50 -0700 Subject: [Sip] RFC 3266 on Support for IPv6 in Session Description Protocol Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3266 Title: Support for IPv6 in Session Description Protocol (SDP) Author(s): S. Olson, G. Camarillo, A. B. Roach Status: Standards Track Date: June 2002 Mailbox: seanol@microsoft.com, Gonzalo.Camarillo@ericsson.com, adam@dynamicsoft.com Pages: 5 Characters: 8693 Updates: 2327 I-D Tag: draft-ietf-mmusic-sdp-ipv6-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3266.txt This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020703131008.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3266 --OtherAccess Content-Type: Message/External-body; name="rfc3266.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020703131008.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 3 19:07:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11938 for ; Wed, 3 Jul 2002 19:07:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01525 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 19:07:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15372; Wed, 3 Jul 2002 17:24:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10922 for ; Wed, 3 Jul 2002 16:14:45 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04387; Wed, 3 Jul 2002 16:13:50 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g63KEdE04273; Wed, 3 Jul 2002 13:14:39 -0700 (PDT) Message-Id: <200207032014.g63KEdE04273@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 03 Jul 2002 13:14:39 -0700 Subject: [Sip] RFC 3267 on Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3267 Title: Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs Author(s): J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie Status: Standards Track Date: June 2002 Mailbox: Johan.Sjoberg@ericsson.com, Magnus.Westerlund@ericsson.com, ari.lakaniemi@nokia.com, qxie1@email.mot.com Pages: 49 Characters: 110652 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-amr-13.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3267.txt This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020703131216.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3267 --OtherAccess Content-Type: Message/External-body; name="rfc3267.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020703131216.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 3 20:13:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14824 for ; Wed, 3 Jul 2002 20:13:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04144 for sip-archive@odin.ietf.org; Wed, 3 Jul 2002 20:14:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03081; Wed, 3 Jul 2002 19:48:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03051 for ; Wed, 3 Jul 2002 19:48:53 -0400 (EDT) Received: from clareexch.cgu.edu (clare_mail.cgu.edu [134.173.10.221]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13647 for ; Wed, 3 Jul 2002 19:48:02 -0400 (EDT) Received: by clareexch with Internet Mail Service (5.5.2650.21) id <31NWHNTL>; Wed, 3 Jul 2002 16:44:00 -0700 Message-ID: <832C142DE336D611892000B0D0F3944B5B284C@clareexch> From: Samir Chatterjee To: "'sip@ietf.org'" Subject: [Sip] Out of band authentication Date: Wed, 3 Jul 2002 16:43:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Can someone point us to I-Ds, drafts, RFCs or articles that talk about out-of-band authentication in SIP? I am looking for methods beyond HTTP-digest style that is recommended. Is there any detail description of using RADIUS, DIAMETER? Also, is anyone aware of single-sign-on authentication in SIP with enterprise directories? Thanks Samir Dr. Samir Chatterjee Associate Professor School of Information Science Claremont Graduate University 130 East Ninth Street, Claremont, CA 91711-6190 (Ph) 909-607-4651; (Fax) 909-621-8564 Email:samir.chatterjee@cgu.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 04:44:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11686 for ; Thu, 4 Jul 2002 04:44:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA04829 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 04:45:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02961; Thu, 4 Jul 2002 04:18:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02927 for ; Thu, 4 Jul 2002 04:18:34 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11274 for ; Thu, 4 Jul 2002 04:17:43 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g648J3i13276 for ; Thu, 4 Jul 2002 11:19:03 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Jul 2002 11:18:31 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 11:18:31 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 11:18:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 4 Jul 2002 11:18:30 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203B4@esebe019.NOE.Nokia.com> Thread-Topic: [Sip-implementors] List of bugs in bis09 Thread-Index: AcINiHOwNUuATqZhRl2DxuRI5/JhRQVqnVZQ To: , X-OriginalArrivalTime: 04 Jul 2002 08:18:31.0414 (UTC) FILETIME=[61FE1160:01C22333] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA02928 Subject: [Sip] RE: [Sip-implementors] List of bugs in bis09 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, Has this been done yet? I would be nice to get a list of changes from bis-09 to RFC3261 (and perhaps all the other new RFCs that had some changes to them in the 48 hour period). Regards, Hisham > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Thursday, June 06, 2002 9:28 PM > To: sharad@bhartitelesoft.com > Cc: sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] List of bugs in bis09 > > > Other than the list, no. At least not right now. > > There is an open issues report at > http://www.softarmor.com/sipwg/issues, but it doesn't > display bugs that have been reported and just need to be > resolved. I'll look into building something that does. > > RjS > > On Thu, 2002-06-06 at 01:39, Sharad Goklani wrote: > > Hi All, > > > > Does a list of filed bugs/issues in bis09 exist somewhere ? > > > > Thanks, > > Sharad > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 08:56:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16451 for ; Thu, 4 Jul 2002 08:56:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA17287 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 08:57:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15941; Thu, 4 Jul 2002 08:18:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15909 for ; Thu, 4 Jul 2002 08:18:32 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15971 for ; Thu, 4 Jul 2002 08:17:42 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 4 Jul 2002 14:17:11 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <3H1PB2MN>; Thu, 4 Jul 2002 14:17:59 +0200 Message-Id: From: "Alexeitsev, D" To: bert.culpepper@intervoice-brite.com Cc: sip@ietf.org, christer.holmberg@lmf.ericsson.se Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Thu, 4 Jul 2002 14:17:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello Bert, Christer Thank you for the clarifications Some comments inline Again, AFAIK a UAS can send media to the UAC after receiving the UAC's SDP. No response is required to be sent back to the UAC. Sending a response with SDP is the "polite" thing to do IMHO as it's an explicit indication that the UAS will send media (and allows RTP/RTCP to "work"). [DA] That was my understanding as well. I think, that in some scenarios, it is better to wait for the answer before playback for the prevention of receiving media from hosts that are not invited to the session. Even by the cost of user convenience. My read indicates answers MUST be in a reliable response, which is only 200 in bis-09. This is stated pretty clearly IMHO. I'm not sure what a "early media session" is but if you want to complete the offer-answer exchange prior to sending/receiving a 200 OK, then there's the 100-rel extension (as I'm sure you're aware :). [DA] Is the use of the TCP/SCTP is good enough to say that e2e provisional responses with answer are reliable? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 10:40:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18398 for ; Thu, 4 Jul 2002 10:40:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA23004 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 10:40:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21413; Thu, 4 Jul 2002 10:15:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21382 for ; Thu, 4 Jul 2002 10:15:22 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17787 for ; Thu, 4 Jul 2002 10:14:31 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 4 Jul 2002 14:15:45 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 4 Jul 2002 15:16:39 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE01809578@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [SIP, Transport] Does sent on TCP (when msg too big) also occurs on server side? Thread-Index: AcIjZWn1m3bWF0V8Rie3/uAcjgOPog== From: "Gilles Compienne" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA21383 Subject: [Sip] [SIP, Transport] Does sent on TCP (when msg too big) also occurs on server side? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello, I have a question about the fact that we should send a message through TCP if its size is too big for UDP. This is specified for the client side (point 18.1.1), however no comment about it is made for the server side. Does it means that, if we receive a request through UDP, the response (point 18.2.2) should be done through UDP even if the message is too big for UDP (so ignoring the rule given in 18.1.1). I agree that it implies that our response is bigger than the resquest but I think nothing forbide these kind of situations Thanks for your help. Regards, Gilles Compienne. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 10:47:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18707 for ; Thu, 4 Jul 2002 10:47:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA23286 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 10:47:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21695; Thu, 4 Jul 2002 10:19:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21664 for ; Thu, 4 Jul 2002 10:19:53 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.ivbnetworksolutions.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17856 for ; Thu, 4 Jul 2002 10:19:01 -0400 (EDT) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id JAA00682 for ; Thu, 04 Jul 2002 09:27:15 -0500 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Thu, 4 Jul 2002 09:13:32 -0500 Received: from bculpepperpc ([151.214.91.240]) by 172.16.16.64; Thu, 04 Jul 2002 09:19:11 -0500 From: "Bert Culpepper" To: "'Christer Holmberg'" Cc: "'Alexeitsev, D'" , Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Thu, 4 Jul 2002 10:18:25 -0400 Message-ID: <000001c22365$a9682900$6600a8c0@bculpepperpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <3D22F7A6.4A64FFAA@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Christer, comments below. Christer Holmberg wrote: > > Hi Bert, > > As a conclusion to this discussion my proposal for a > clarification would be > that the local ringback generation depends on if a early > media session has > been established or not when the 180 arrives. > > And, IF a UAS sends early media, and then wants the UAC to > generate local > ringback, it first have to put the early media on hold, using > UPDATE, then > send 180 (the UAC MAY now generate local ringback, since > there is no early > media), and when the called party answers the UAS will first > send a new > UPDATE, to un-hold the media, then send 200 for the INVITE. I > still think > this process is very messy, and "much pain for little gain", but since > that's the only way SIP allows us to do it I am not going to > argue against > it :) I agree with you. But with what's written in bis-09 and other I-Ds there's no guarantee on what the UAC will do with this sequence of messages as far as rendering session progress. I believe the issue here is how to provide a good user experience and as long as the UAC presents some indication of what's going on in the signaling the user shouldn't get confused. > > I still would like to get a clarification on the > "UPDATE-and-buffering-of-200) issue I brought up, though :) > Personally I see > no reason why to buffer the 200, but the UAS may have to > buffer the second > UPDATE (used to un-hold the media) until it has completed the > first UPDATE > (used to put media on hold), which means there is again a > chance of media > clipping. Well, I believe the purpose of UPDATE is to modify session state prior to the INVITE transaction completing. Given this, I would say UPDATE transactions have to complete before the INVITE transaction completes. And yes, there is a chance of clipping here. So to prevent this, if the UAS only indicates that it will stop sending media the UAC will still render received media if/when it arrives. Some additional session update is needed anyway to have the UAC send its media to the new destination right? This seems to be a case of 3pcc where we need the UAC to *not* change its SDP during these transactions. Regards, Bert > > Now, as Bert mentioned, the UAS may start sending early media without > indicating it (sending 183 with SDP), and then still send 180 > without SDP > even if it sends early media, so in that case I guess there > is a risk the > local ringback WILL get mixed with the early media (but, we > can get early > media mixing in forking scenarios, anyway) - UNLESS the UAC > is able to do > some decissions based on detected media (I don't think that > would work very > well, but it's up to each implementor to decide for him/herself). > > Or, does anyone have another proposal? > > Thanks! > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 11:04:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19175 for ; Thu, 4 Jul 2002 11:04:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24380 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 11:05:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23207; Thu, 4 Jul 2002 10:44:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23169 for ; Thu, 4 Jul 2002 10:44:36 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.ivbnetworksolutions.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18605 for ; Thu, 4 Jul 2002 10:43:47 -0400 (EDT) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id JAA00711 for ; Thu, 04 Jul 2002 09:52:01 -0500 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Thu, 4 Jul 2002 09:38:17 -0500 Received: from bculpepperpc ([151.214.91.240]) by 172.16.16.64; Thu, 04 Jul 2002 09:43:43 -0500 From: "Bert Culpepper" To: "'Alexeitsev, D'" Cc: , Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Thu, 4 Jul 2002 10:42:57 -0400 Message-ID: <000101c22369$176e0660$6600a8c0@bculpepperpc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, comments below... Alexeitsev, D wrote: > > Hello Bert, Christer > > Thank you for the clarifications > > Some comments inline > > Again, AFAIK a UAS can send media to the UAC after receiving the UAC's > SDP. No response is required to be sent back to the UAC. Sending a > response with SDP is the "polite" thing to do IMHO as it's an explicit > indication that the UAS will send media (and allows RTP/RTCP > to "work"). > > [DA] That was my understanding as well. I think, that in some > scenarios, it is better to wait for the answer before > playback for the prevention of receiving media from hosts > that are not invited to the session. Even by the cost of user > convenience. Yes, this has been discussed before :) I think this can be handled for Christer's scenario if the B2BUA completes the initial INVITE transaction and uses reINVITE instead of UPDATE to provide the service. Again, the B2BUA will have to manage the caller's user experience in this case. > > My read indicates answers MUST be in a reliable response, > which is only > 200 in bis-09. This is stated pretty clearly IMHO. I'm not > sure what a > "early media session" is but if you want to complete the offer-answer > exchange prior to sending/receiving a 200 OK, then there's the 100-rel > extension (as I'm sure you're aware :). > > [DA] Is the use of the TCP/SCTP is good enough to say that > e2e provisional responses with answer are reliable? I don't think so for "reliable provisional responses". Retransmissions are not needed when using TCP but a PRACK from the UAC is still needed for "reliable provisional responses". Regards, Bert > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 11:14:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19377 for ; Thu, 4 Jul 2002 11:14:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24795 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 11:15:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23652; Thu, 4 Jul 2002 10:55:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23623 for ; Thu, 4 Jul 2002 10:55:41 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18940 for ; Thu, 4 Jul 2002 10:54:53 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 4 Jul 2002 16:54:22 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <3H1PBPF7>; Thu, 4 Jul 2002 16:55:10 +0200 Message-Id: From: "Alexeitsev, D" To: bert.culpepper@intervoice-brite.com Cc: sip@ietf.org Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Thu, 4 Jul 2002 16:55:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, comment inline > [DA] Is the use of the TCP/SCTP is good enough to say that > e2e provisional responses with answer are reliable? I don't think so for "reliable provisional responses". Retransmissions are not needed when using TCP but a PRACK from the UAC is still needed for "reliable provisional responses". [DA] I mean, that the 100rel is only needed for the UDP. The reliable transport protocols do not need a help from session control protocols. Greetings, Denis Alexeitsev _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 12:09:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20396 for ; Thu, 4 Jul 2002 12:09:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28620 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 12:10:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26313; Thu, 4 Jul 2002 11:49:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26282 for ; Thu, 4 Jul 2002 11:49:02 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19893 for ; Thu, 4 Jul 2002 11:48:13 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g64Fn0rU014088; Thu, 4 Jul 2002 17:49:00 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g64Fn0a9005992; Thu, 4 Jul 2002 18:49:00 +0300 (EET DST) Message-ID: <3D246E6C.F48B1DDD@lmf.ericsson.se> Date: Thu, 04 Jul 2002 18:49:00 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gilles Compienne CC: sip@ietf.org Subject: Re: [Sip] [SIP, Transport] Does sent on TCP (when msg too big) also occurs on server side? References: <45730E094814E44488F789C1CDED27AE01809578@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The transaction should use the same transport (that's my understanding, at least), which means the response uses the same transport as the response. It is true that the response may be bigger than the request (eg if the 200 response to a INVITE without SDP), but bis-09 DOES take that into consideration, saying that the maximum size for a request is smaller than the actual maximum size for a SIP UDP message, so that there is "room" for the response to use UDP too, even if the response is bigger than the request. IF, however, the response becomes too big for UDP, I guess that COULD be indicated to the UAC in an error response to the request, but I currently don't remember which error code (if such even exists...) should be used to indicate that. It was discussed once, but you may want to check the archieve for details... Regards, Christer Holmberg Ericsson Finland Gilles Compienne wrote: > Hello, > > I have a question about the fact that we should send a message through TCP if its size is too big for UDP. This is specified for the client side (point 18.1.1), however no comment about it is made for the server side. > > Does it means that, if we receive a request through UDP, the response (point 18.2.2) should be done through UDP even if the message is too big for UDP (so ignoring the rule given in 18.1.1). > > I agree that it implies that our response is bigger than the resquest but I think nothing forbide these kind of situations > > Thanks for your help. > > Regards, > > Gilles Compienne. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 12:10:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20411 for ; Thu, 4 Jul 2002 12:10:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28643 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 12:10:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26082; Thu, 4 Jul 2002 11:38:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26046 for ; Thu, 4 Jul 2002 11:38:50 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.ivbnetworksolutions.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19777 for ; Thu, 4 Jul 2002 11:38:02 -0400 (EDT) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id KAA00795 for ; Thu, 04 Jul 2002 10:46:15 -0500 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Thu, 4 Jul 2002 10:32:31 -0500 Received: from bculpepperpc ([151.214.91.240]) by 172.16.16.64; Thu, 04 Jul 2002 10:37:54 -0500 From: "Bert Culpepper" To: "'Alexeitsev, D'" Cc: Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Thu, 4 Jul 2002 11:37:08 -0400 Message-ID: <000701c22370$a9001760$6600a8c0@bculpepperpc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Denis, I don't know that the use of TCP is a substitute for 100rel. PRACK provides knowledge that the receiver's UA "processed" the provisional response. TCP only guarantees the message was received at the host. I may be off-base here, if so others can correct me. Regards, Bert Alexeitsev, D wrote: > > Hello, > > comment inline > > > [DA] Is the use of the TCP/SCTP is good enough to say that > > e2e provisional responses with answer are reliable? > > I don't think so for "reliable provisional responses". > Retransmissions > are not needed when using TCP but a PRACK from the UAC is still needed > for "reliable provisional responses". > > [DA] I mean, that the 100rel is only needed for the UDP. The > reliable transport protocols do not need a help from session > control protocols. > > Greetings, > Denis Alexeitsev > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 12:10:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20431 for ; Thu, 4 Jul 2002 12:10:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28691 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 12:11:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26221; Thu, 4 Jul 2002 11:45:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26190 for ; Thu, 4 Jul 2002 11:45:07 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19849 for ; Thu, 4 Jul 2002 11:44:18 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g64FhFrU013193; Thu, 4 Jul 2002 17:43:16 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g64FhEa9005634; Thu, 4 Jul 2002 18:43:14 +0300 (EET DST) Message-ID: <3D246D12.7F3F84C3@lmf.ericsson.se> Date: Thu, 04 Jul 2002 18:43:14 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alexeitsev, D" CC: bert.culpepper@intervoice-brite.com, sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Alexeitsev, I think I get your point :) I'll try to answer. Like Bert said, when TCP is used, "reliable provisional response" from a SIP point of view means that the response is allowed to contain an offer/answer. An "unreliable provisional response", EVEN if sent reliably from a transport layer (TCP) point of view, means that it is NOT allowed to contain an offer/answer (it MAY contain, but the same SDP has to be sent later anyway). Now, you could argue that every 18x sent using TCP should always be considered as a "reliable provisional response" from a SIP point of view, and that PRACK is never needed. Now, that WOULD probably work fine - IF: 1. ...PRACK was only used for what it originally was supposed to be used for - making sure provisional responses are delivered reliably and in order. HOWEVER, nowadays PRACK also has defined offer/answer rules, which means we in some cases MUST use it to send SDP (for example if a reliable 18x contains an offer, the PRACK MUST contain the response, so the PRACK MUST be sent). 2. ...there would never be a TCP/UDP conversion in an intermediate proxy. Now the proxy would have to generate the PRACKs on the hop where UDP is used. 3. ...the SIP APPLICATION would be transport aware. Currently (as I can remember) only the transaction handler, which needs to know if to retransmit messages or not, needs to be transport aware. Now, if you want to argue that it's better to make SIP application transport aware, than sending "useless" PRACKs in the network, and you want proxies to start generating PRACKs, I do NOT want to take part in that discussion :) Regards, Christer Holmberg Ericsson Finland "Alexeitsev, D" wrote: > Hello, > > comment inline > > > [DA] Is the use of the TCP/SCTP is good enough to say that > > e2e provisional responses with answer are reliable? > > I don't think so for "reliable provisional responses". Retransmissions > are not needed when using TCP but a PRACK from the UAC is still needed > for "reliable provisional responses". > > [DA] I mean, that the 100rel is only needed for the UDP. The reliable transport protocols do not need a help from session control protocols. > > Greetings, > Denis Alexeitsev > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 12:27:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20764 for ; Thu, 4 Jul 2002 12:27:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29176 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 12:28:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28543; Thu, 4 Jul 2002 12:07:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28514 for ; Thu, 4 Jul 2002 12:07:07 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20355 for ; Thu, 4 Jul 2002 12:06:18 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 4 Jul 2002 16:07:31 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] [SIP, Transport] Does sent on TCP (when msg too big) also occurs on server side? Date: Thu, 4 Jul 2002 17:08:25 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE018C23B2@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] [SIP, Transport] Does sent on TCP (when msg too big) also occurs on server side? Thread-Index: AcIjctbssOThuiTnRQKt7XTE8m6kvAAAXlRw From: "James Undery" To: "Christer Holmberg" , "Gilles Compienne" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA28515 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > The transaction should use the same transport (that's my > understanding, at least), which means the response uses the > same transport as the response. > > It is true that the response may be bigger than the request > (eg if the 200 response to a INVITE without SDP), but bis-09 > DOES take that into consideration, saying that the maximum > size for a request is smaller than the > actual maximum size for a SIP UDP message, so that there is > "room" for the response to use UDP too, even if the response > is bigger than the request. > > IF, however, the response becomes too big for UDP, I guess > that COULD be indicated to the UAC in an error response to > the request, but I currently don't remember which error code > (if such even exists...) should be used to > indicate that. It was discussed once, but you may want to > check the archieve for details... The trouble with your suggestion of an error (and it's documented in bug#184) is that you can't always return and error. Admittedly it's far fetched but a 200 response to an INVITE crosses the 64k boundary, how can you send an error without messing up the UAS. James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 13:36:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21771 for ; Thu, 4 Jul 2002 13:36:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02034 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 13:37:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00772; Thu, 4 Jul 2002 13:02:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00745 for ; Thu, 4 Jul 2002 13:02:41 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21347 for ; Thu, 4 Jul 2002 13:01:52 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g64H2eRb002933; Thu, 4 Jul 2002 19:02:40 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g64H2da9011231; Thu, 4 Jul 2002 20:02:39 +0300 (EET DST) Message-ID: <3D247FB0.F1485FED@lmf.ericsson.se> Date: Thu, 04 Jul 2002 20:02:40 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: Gilles Compienne , sip@ietf.org Subject: Re: [Sip] [SIP, Transport] Does sent on TCP (when msg too big) also occurs on server side? References: <45730E094814E44488F789C1CDED27AE018C23B2@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi James, James Undery wrote: > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > The transaction should use the same transport (that's my > > understanding, at least), which means the response uses the > > same transport as the response. > > > > It is true that the response may be bigger than the request > > (eg if the 200 response to a INVITE without SDP), but bis-09 > > DOES take that into consideration, saying that the maximum > > size for a request is smaller than the > > actual maximum size for a SIP UDP message, so that there is > > "room" for the response to use UDP too, even if the response > > is bigger than the request. > > > > IF, however, the response becomes too big for UDP, I guess > > that COULD be indicated to the UAC in an error response to > > the request, but I currently don't remember which error code > > (if such even exists...) should be used to > > indicate that. It was discussed once, but you may want to > > check the archieve for details... > > The trouble with your suggestion of an error (and it's documented in bug#184) is that you can't always return and error. Admittedly it's far fetched but a 200 response to an INVITE crosses the 64k boundary, how can you send an error without messing up the UAS. It's not a suggestion - it's the closest to a suggestion I can think of :) As you said yourself, it's an existing and unfixed bug, so I guess there really is no good solution at the moment. The problem, of course, is that if the UAS sends a 4xx response it will most likely also release the call it just established (I assume that's what you meant by saying that "it will mess up the UAS"). That, of course, is stupid since the called party just has picked up the hook (the reason why the 200 is sent), and is most likely going to receive a NEW INVITE (now using TCP) very soon anyway. The best thing would be if the UAS can figure out how big the 200 is going to be before it even alerts the called party, or at least before the called party picks up the phone. In a "manyfolks" scenario I guess that will work, but probably not as well in cases where the called party is alerted as soon as the INVITE is received... Anyway, as you say, it's "far fetched", and I guess the assumption is that a 200 will never be too big. But, never forget Murphy's law... :) Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 15:52:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23773 for ; Thu, 4 Jul 2002 15:52:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06885 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 15:52:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05837; Thu, 4 Jul 2002 15:28:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05805 for ; Thu, 4 Jul 2002 15:28:07 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23302 for ; Thu, 4 Jul 2002 15:27:17 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g64JRSA05262; Thu, 4 Jul 2002 15:27:28 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 14:27:23 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA810A02DD@STNTEXCH2> From: "Peterson, Jon" To: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] p-asserted-identity security harmful Date: Thu, 4 Jul 2002 14:27:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Um, did you perhaps not see the word 'Example' in the title of section 11? The document only requires that a Spec(T) be defined, and provides one in section 11 for illustrative purposes. Or as it says in the beginning of section 11: The remainder of this section presents an example Spec(T), which is not normative in any way. Thanks as always for your reasoned analysis of our work in this group. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, July 03, 2002 8:41 AM > To: sip@ietf.org > Subject: [Sip] p-asserted-identity security harmful > > > > From Section 11.3 of draft-ietf-sip-asserted-identity-01: > > > Connections between nodes within the Trust Domain and > between UAs and > > nodes in the Trust Domain MUST use TLS using a cipher suite of > > RSA_WITH_AES_128_CBC_SHA1. Mutual authentication > between nodes in the > > trust domain MUST be performed and confidentiality MUST > be negotiated. > > > > > It's just come to my attention that TLS was > mandated in the asserted identity draft. Not only > was TLS mandated, but certain cipher suites and > _AUTHENTICATION_ mechanisms were made necessary > not only to implement, but to deploy. This is > utterly bogus. This also places new requirements > on UA's, which are not part of the base SIP spec. > That too is bogus, and has been slipped in with > no discussion. > > First, it ignores the possible use of IPsec as an > alternate mechanism to protect the bits on the > wire, but far more bogus doesn't allow for the > proper latitude with authentication mechanisms > needed in real life. I know that a lot of people > here think that the PKI kool aide is going to > solve world thirst, but reality has shown that to > be a complete myth. SIP should not be mandating > things for *deployment* which are manifestly > undeployable as the only possible mechanism. > Thirdly, it places new requirements on UA's of not > only implementation, but *deployment* as > well. This is extremely harmful. > > This section should either be struck in its > entirety, or refer back to the base SIP spec's > proxy requirements (which are likely to be harmful > too, but at least the damage will be limited to a > single document). > > Mike > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 16:01:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23922 for ; Thu, 4 Jul 2002 16:01:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07475 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 16:02:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06628; Thu, 4 Jul 2002 15:38:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06596 for ; Thu, 4 Jul 2002 15:38:11 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23457 for ; Thu, 4 Jul 2002 15:37:21 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g64JbbhI028042; Thu, 4 Jul 2002 12:37:37 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABZ72652; Thu, 4 Jul 2002 12:34:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA20620; Thu, 4 Jul 2002 12:37:36 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15652.41984.294506.256017@thomasm-u1.cisco.com> Date: Thu, 4 Jul 2002 12:37:36 -0700 (PDT) To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] p-asserted-identity security harmful In-Reply-To: <15A2739B7DAA624D8091C65981D7DA810A02DD@STNTEXCH2> References: <15A2739B7DAA624D8091C65981D7DA810A02DD@STNTEXCH2> 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! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jon, I am not the only one who was confused by this and before you start copping attitude you might consider whether REQUIREMENTS LANGUAGE in EXAMPLES is a recipe for an understandable document. Mike Peterson, Jon writes: > Um, did you perhaps not see the word 'Example' in the title of section 11? > The document only requires that a Spec(T) be defined, and provides one in > section 11 for illustrative purposes. Or as it says in the beginning of > section 11: > > The remainder of this section presents an example Spec(T), which is > not normative in any way. > > Thanks as always for your reasoned analysis of our work in this group. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Wednesday, July 03, 2002 8:41 AM > > To: sip@ietf.org > > Subject: [Sip] p-asserted-identity security harmful > > > > > > > > From Section 11.3 of draft-ietf-sip-asserted-identity-01: > > > > > Connections between nodes within the Trust Domain and > > between UAs and > > > nodes in the Trust Domain MUST use TLS using a cipher suite of > > > RSA_WITH_AES_128_CBC_SHA1. Mutual authentication > > between nodes in the > > > trust domain MUST be performed and confidentiality MUST > > be negotiated. > > > > > > > > > It's just come to my attention that TLS was > > mandated in the asserted identity draft. Not only > > was TLS mandated, but certain cipher suites and > > _AUTHENTICATION_ mechanisms were made necessary > > not only to implement, but to deploy. This is > > utterly bogus. This also places new requirements > > on UA's, which are not part of the base SIP spec. > > That too is bogus, and has been slipped in with > > no discussion. > > > > First, it ignores the possible use of IPsec as an > > alternate mechanism to protect the bits on the > > wire, but far more bogus doesn't allow for the > > proper latitude with authentication mechanisms > > needed in real life. I know that a lot of people > > here think that the PKI kool aide is going to > > solve world thirst, but reality has shown that to > > be a complete myth. SIP should not be mandating > > things for *deployment* which are manifestly > > undeployable as the only possible mechanism. > > Thirdly, it places new requirements on UA's of not > > only implementation, but *deployment* as > > well. This is extremely harmful. > > > > This section should either be struck in its > > entirety, or refer back to the base SIP spec's > > proxy requirements (which are likely to be harmful > > too, but at least the damage will be limited to a > > single document). > > > > Mike > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 16:32:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24341 for ; Thu, 4 Jul 2002 16:32:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08536 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 16:33:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07533; Thu, 4 Jul 2002 16:03:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07502 for ; Thu, 4 Jul 2002 16:03:34 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23955 for ; Thu, 4 Jul 2002 16:02:43 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g64K33YH028118; Thu, 4 Jul 2002 16:03:03 -0400 (EDT) Message-ID: <3D24A9F5.4030307@dynamicsoft.com> Date: Thu, 04 Jul 2002 16:03:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas CC: "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] p-asserted-identity security harmful References: <15652.41984.294506.256017@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You are, of course, correct that requirements language in examples is odd and potentially confusing. However, spec(T), of which this is an example, is supposed to be a specification itself - defining exactly what it means for an identity to be asserted. -Jonathan R. Michael Thomas wrote: > Jon, > > I am not the only one who was confused by this and > before you start copping attitude you might > consider whether REQUIREMENTS LANGUAGE in EXAMPLES > is a recipe for an understandable document. > > Mike > > Peterson, Jon writes: > > Um, did you perhaps not see the word 'Example' in the title of > section 11? > > The document only requires that a Spec(T) be defined, and provides > one in > > section 11 for illustrative purposes. Or as it says in the beginning > of > > section 11: > > > > The remainder of this section presents an example Spec(T), which > is > > not normative in any way. > > > > Thanks as always for your reasoned analysis of our work in this > group. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Wednesday, July 03, 2002 8:41 AM > > > To: sip@ietf.org > > > Subject: [Sip] p-asserted-identity security harmful > > > > > > > > > > > > From Section 11.3 of draft-ietf-sip-asserted-identity-01: > > > > > > > Connections between nodes within the Trust Domain and > > > between UAs and > > > > nodes in the Trust Domain MUST use TLS using a cipher suite of > > > > RSA_WITH_AES_128_CBC_SHA1. Mutual authentication > > > between nodes in the > > > > trust domain MUST be performed and confidentiality MUST > > > be negotiated. > > > > > > > > > > > > > It's just come to my attention that TLS was > > > mandated in the asserted identity draft. Not only > > > was TLS mandated, but certain cipher suites and > > > _AUTHENTICATION_ mechanisms were made necessary > > > not only to implement, but to deploy. This is > > > utterly bogus. This also places new requirements > > > on UA's, which are not part of the base SIP spec. > > > That too is bogus, and has been slipped in with > > > no discussion. > > > > > > First, it ignores the possible use of IPsec as an > > > alternate mechanism to protect the bits on the > > > wire, but far more bogus doesn't allow for the > > > proper latitude with authentication mechanisms > > > needed in real life. I know that a lot of people > > > here think that the PKI kool aide is going to > > > solve world thirst, but reality has shown that to > > > be a complete myth. SIP should not be mandating > > > things for *deployment* which are manifestly > > > undeployable as the only possible mechanism. > > > Thirdly, it places new requirements on UA's of not > > > only implementation, but *deployment* as > > > well. This is extremely harmful. > > > > > > This section should either be struck in its > > > entirety, or refer back to the base SIP spec's > > > proxy requirements (which are likely to be harmful > > > too, but at least the damage will be limited to a > > > single document). > > > > > > Mike > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 16:46:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24542 for ; Thu, 4 Jul 2002 16:46:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08985 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 16:47:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07725; Thu, 4 Jul 2002 16:17:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07695 for ; Thu, 4 Jul 2002 16:17:36 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24128 for ; Thu, 4 Jul 2002 16:16:46 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g64KH3YH028125; Thu, 4 Jul 2002 16:17:04 -0400 (EDT) Message-ID: <3D24AD3D.8040505@dynamicsoft.com> Date: Thu, 04 Jul 2002 16:17:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org, bcampbell@dynamicsoft.com Subject: Re: [Sip] MESSAGE advertising in REGISTERs References: <5.1.0.14.0.20020703142040.033c0fb8@iptel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jiri Kuthan wrote: > Can someone tell me why the MESSAGE I-D mandates advertising > of support in REGISTERs of a MESSAGE-capable UAC only *optionally*? Because the system will function without a proxy knowing this ahead of time. To date, we have not mandated the use of caller preferences (which is where this comes from) in other sip extensions, such as UPDATE, PRACK. I think presence mentions that you SHOULD do this, but not RFC 3265 (i.e., it doesnt apply to all events). Indeed, since not all methods are mandatory even in baseline SIP, and indeed, rfc3261 doesn't actually mandate anything but OPTIONS, we already have the case that a proxy doesn't know the methods of the UAs that register to it. > > Making it optional gains little knowledge to a SIP server -- a server > does not know anything it could reliably use in its processing logic. Sure it does. If it is there, it knows that the UA does or does not support MESSAGE. Its just that its not always there. > > Think of a SIP server which acts as a proxy server and message store. > If it knew, that downstream UAS was not capable of processing MESSAGEs, > it could immediately store an incoming MESSAGE, send 202 upstream, > and relay the message to first UAC which registers and advertises support > for MESSAGE in REGISTER. > > Because the server does not know it, it has to relay unnecessarily > a message to an upstream UAS, which will deny it. That doesn't seem so bad. If it bothers you, send an OPTIONS to the UA once it registers. > Then, whenever > a REGISTER arrives, the server will try to dump message store to it, > (hoping a UAC capable of MESSAGE registered) resulting in quite > uneffective behaviour. Well, that is only one way to handle transmission of undelivered messages to a UA when it comes online. For many reasons, it is not the best way, I think. A better way is allow a UA to query to see if it has any undelivered messages when it registers, and then pull them as needed. This works better in wireless, too. Even if the UA does support MESSAGE, it may not want all of them the moment it connects. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 4 16:48:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24581 for ; Thu, 4 Jul 2002 16:48:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09017 for sip-archive@odin.ietf.org; Thu, 4 Jul 2002 16:49:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07799; Thu, 4 Jul 2002 16:21:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07770 for ; Thu, 4 Jul 2002 16:21:44 -0400 (EDT) Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24169 for ; Thu, 4 Jul 2002 16:20:53 -0400 (EDT) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni02mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020613.01) with SMTP id g64KLhZ12182 for ; Thu, 4 Jul 2002 16:21:43 -0400 (EDT) Message-ID: <27b101c22398$69c31930$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: Date: Thu, 4 Jul 2002 16:21:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_27AE_01C22376.E278DD00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] Rewording of definitions in Section 6 of RFC 2543-bis09 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_27AE_01C22376.E278DD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Johnathan, These are the following things which I feel should be reworded for = better understanding: Section 6, rfc2543bis-09 1. definition of B2BUA on line 610 and definition of UA on line 753 = doesnt reflect any differences between the two. 2. definition of "Call Stateful" on line 618 and "Stateful Proxy" on = line 720 also doesnt differentiate between the two. 3. definition of "Loose Routing" on line 658 and "Strict Routing" on = line 727 also doesnt give a clear picture of the difference between the = two. a good example good be the way "Loop" on line 653 and "Spiral" on line = 713 has been defined. It clearly shows the difference between the two. Please let me hear what the WG feels about it. Thanks, Prabhas ------=_NextPart_000_27AE_01C22376.E278DD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Johnathan,
These are the following things which I = feel should=20 be reworded for better understanding:
 
 Section 6, = rfc2543bis-09
 
1. definition of B2BUA on line 610 and = definition=20 of UA on line 753 doesnt reflect any differences between the = two.
 
2. definition of "Call Stateful" on = line 618=20 and  "Stateful Proxy" on line 720 also doesnt differentiate between = the=20 two.
 
3. definition of "Loose Routing" on = line 658 and=20 "Strict Routing" on line 727 also doesnt give a clear picture of the = difference=20 between the two.
 
a good example good be the way "Loop" = on line 653=20 and "Spiral" on line 713 has been defined. It clearly shows the = difference=20 between the two.
 
Please let me hear what the WG feels = about=20 it.
 
Thanks,
 
Prabhas
------=_NextPart_000_27AE_01C22376.E278DD00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 5 06:11:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16345 for ; Fri, 5 Jul 2002 06:11:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21698 for sip-archive@odin.ietf.org; Fri, 5 Jul 2002 06:12:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20361; Fri, 5 Jul 2002 05:45:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20330 for ; Fri, 5 Jul 2002 05:44:59 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16021 for ; Fri, 5 Jul 2002 05:44:09 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA11344; Fri, 5 Jul 2002 11:44:40 +0200 (MET DST) Received: from mchh169e.mch4.siemens.de ([139.21.130.176]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA05994; Fri, 5 Jul 2002 11:44:55 +0200 (MET DST) Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 11:44:56 +0200 Message-ID: From: Euchner Martin ICN M SR 3 To: "'Jonathan Rosenberg'" , Michael Thomas , Euchner Martin ICN M SR 3 Cc: "Peterson, Jon" , sip@ietf.org Subject: RE: [Sip] p-asserted-identity security harmful Date: Fri, 5 Jul 2002 11:44:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Now I'm confused even more as this sounds like the Spec(T) example is in fact of more mandatory nature. 11.2 Authentication requirements Users MUST be authenticated using SIP Digest Authentication. First of all, I do not see any reason why to mandate SIP digest Authentication for this draft. Doing that would tie this draft forever to digest, but would not allow any other SIP authentication mechanism. I recommend to reword as a SHOULD at least and offering a MAY for other (SIP-09) authentication methods. I guess what is perhaps intended is simply that "Users MUST/SHOULD be authenticated". My understanding of this draft is, that the draft assumes that users have been authenticated (although even this can be weak in a trusted domain). The draft describes a means how to populate the privacy-ID information but certainly does not describe how to secure SIP. 11.3 Security requirements Connections between nodes within the Trust Domain and between UAs and nodes in the Trust Domain MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in the trust domain MUST be performed and confidentiality MUST be negotiated. Further, I really do not understand and do not see any value why this drafts actually profiles TLS cipher suites allowing only RSA_AES128, but does not allow any other defined TLS cipher suites. The defined TLS cipher suites have been chosen with care and for good reasons; TLS has its inherent security capability negotiation, that works just fine. Then, as pointed out by Michael, the MUST mandate for mutual TLS is counterproductive: if there is mutual TLS authentication, then digest authentication is completely redundant. On the other hand, it >>should<< be allowed to have proxy-sided TLS authentication combined with some other authentication, and of course other authentication methods should not be ruled out. Finally, I completely agree with Michael's proposal, that sections 11.2 and 11.3 be completely revised, making them aligned with what SIP-09 spec says about authentication and security (although that is problematic as well) and leaving sufficient degree of freedom for future extensions. This privacy draft shall not attempt to define its own SIP Security baseline. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 47713 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, July 04, 2002 10:03 PM To: Michael Thomas Cc: Peterson, Jon; sip@ietf.org Subject: Re: [Sip] p-asserted-identity security harmful You are, of course, correct that requirements language in examples is odd and potentially confusing. However, spec(T), of which this is an example, is supposed to be a specification itself - defining exactly what it means for an identity to be asserted. -Jonathan R. Michael Thomas wrote: > Jon, > > I am not the only one who was confused by this and > before you start copping attitude you might > consider whether REQUIREMENTS LANGUAGE in EXAMPLES > is a recipe for an understandable document. > > Mike > > Peterson, Jon writes: > > Um, did you perhaps not see the word 'Example' in the title of > section 11? > > The document only requires that a Spec(T) be defined, and provides > one in > > section 11 for illustrative purposes. Or as it says in the beginning > of > > section 11: > > > > The remainder of this section presents an example Spec(T), which > is > > not normative in any way. > > > > Thanks as always for your reasoned analysis of our work in this > group. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Wednesday, July 03, 2002 8:41 AM > > > To: sip@ietf.org > > > Subject: [Sip] p-asserted-identity security harmful > > > > > > > > > > > > From Section 11.3 of draft-ietf-sip-asserted-identity-01: > > > > > > > Connections between nodes within the Trust Domain and > > > between UAs and > > > > nodes in the Trust Domain MUST use TLS using a cipher suite of > > > > RSA_WITH_AES_128_CBC_SHA1. Mutual authentication > > > between nodes in the > > > > trust domain MUST be performed and confidentiality MUST > > > be negotiated. > > > > > > > > > > > > > It's just come to my attention that TLS was > > > mandated in the asserted identity draft. Not only > > > was TLS mandated, but certain cipher suites and > > > _AUTHENTICATION_ mechanisms were made necessary > > > not only to implement, but to deploy. This is > > > utterly bogus. This also places new requirements > > > on UA's, which are not part of the base SIP spec. > > > That too is bogus, and has been slipped in with > > > no discussion. > > > > > > First, it ignores the possible use of IPsec as an > > > alternate mechanism to protect the bits on the > > > wire, but far more bogus doesn't allow for the > > > proper latitude with authentication mechanisms > > > needed in real life. I know that a lot of people > > > here think that the PKI kool aide is going to > > > solve world thirst, but reality has shown that to > > > be a complete myth. SIP should not be mandating > > > things for *deployment* which are manifestly > > > undeployable as the only possible mechanism. > > > Thirdly, it places new requirements on UA's of not > > > only implementation, but *deployment* as > > > well. This is extremely harmful. > > > > > > This section should either be struck in its > > > entirety, or refer back to the base SIP spec's > > > proxy requirements (which are likely to be harmful > > > too, but at least the damage will be limited to a > > > single document). > > > > > > Mike > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 5 10:51:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27878 for ; Fri, 5 Jul 2002 10:51:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06208 for sip-archive@odin.ietf.org; Fri, 5 Jul 2002 10:52:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04448; Fri, 5 Jul 2002 10:18:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04417 for ; Fri, 5 Jul 2002 10:18:32 -0400 (EDT) Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com [192.84.19.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26515 for ; Fri, 5 Jul 2002 10:17:39 -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 HAA11169 for ; Fri, 5 Jul 2002 07:17:53 -0700 (PDT) Received: from acm.org (ronin.8x8.com [192.84.17.139]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id HAA07306 for ; Fri, 5 Jul 2002 07:17:51 -0700 (PDT) Message-ID: <3D25AA8F.8040908@acm.org> Date: Fri, 05 Jul 2002 07:17:51 -0700 From: Marc Petit-Huguenin Organization: 8x8, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 X-Accept-Language: en MIME-Version: 1.0 To: IETF SIP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Congratulations Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit As a SIP implementor, I would like to thanks and congratulate the authors and the WG for their work on the RFC326[1-6]. -- Marc Petit-Huguenin Home: mailto:marc@petit-huguenin.org Work: mailto:petithug@8x8.com "So much to do and so little time" The Joker - Batman (The Movie) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 5 14:49:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10322 for ; Fri, 5 Jul 2002 14:48:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18919 for sip-archive@odin.ietf.org; Fri, 5 Jul 2002 14:49:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17868; Fri, 5 Jul 2002 14:22:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17836 for ; Fri, 5 Jul 2002 14:22:53 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08593 for ; Fri, 5 Jul 2002 14:22:03 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g65IMNYH028403 for ; Fri, 5 Jul 2002 14:22:23 -0400 (EDT) Message-ID: <3D25E3DD.4000106@dynamicsoft.com> Date: Fri, 05 Jul 2002 14:22:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] update to draft-ietf-sip-nat Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I posted an update to draft-ietf-sip-nat. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-nat-02.txt As agreed on the list, the Translate header is gone. Its just rport now, resulting in a very short and suite specification. The plan is for connection reuse to fill the role of the Translate header. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 5 14:52:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10546 for ; Fri, 5 Jul 2002 14:52:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19047 for sip-archive@odin.ietf.org; Fri, 5 Jul 2002 14:53:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17637; Fri, 5 Jul 2002 14:15:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17606 for ; Fri, 5 Jul 2002 14:15:26 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08236 for ; Fri, 5 Jul 2002 14:14:35 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g65IEuYH028396 for ; Fri, 5 Jul 2002 14:14:56 -0400 (EDT) Message-ID: <3D25E21E.6060301@dynamicsoft.com> Date: Fri, 05 Jul 2002 14:14:54 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] update to session timer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I posted an update to the session timer specification before the I-D deadline. It should appear in the archives shortly. Until it does, you can grab it at: http://www.jdrosen.net/papers/draft-ietf-sip-session-timer-09.txt Changes since -08: * added UPDATE as a valid method to use session timer. * changed default reason phrase of 422 to "Session Interval too Small" as part of an improvement in consistency of terminology. * introduced the term "session refresh request" to refer to INVITE or UPDATE. * deleted repetitive normative text in the sections defining the Min-SE and Session-Expires header fields. * General update for bis, including grammar, Table 2/3 structure, terminology. * removed text on mandatory inclusion of from tags, and on rejecting requests that are received with tags but that don't match a dialog. All of that is in bis. * Proxies used to be able to add a refresher parameter with value uas into a Session-Expires header field, if the header field was not present and was added by the proxy. This is redundant, and was the only case where the proxy could set the refresher parameter. Instead of this useless exception, the specification now makes a blanket statement that proxies can't insert or modify the refresher parameter. * added IANA considerations * removed old examples section, per sip-guidelines, included a new one with a complete ladder diagram, full messages, and reduced the number of different example flows. This document is now in excellent shape, I believe. I really went through it with a fine tooth comb to make it consistent. I do not think the above changes (the only significant one was usage of UPDATE) warrants a new WGLC, since the change was agreed on the list. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 5 15:05:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11520 for ; Fri, 5 Jul 2002 15:05:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19863 for sip-archive@odin.ietf.org; Fri, 5 Jul 2002 15:06:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17805; Fri, 5 Jul 2002 14:21:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17774 for ; Fri, 5 Jul 2002 14:21:05 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08511 for ; Fri, 5 Jul 2002 14:20:14 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g65IKZYH028400 for ; Fri, 5 Jul 2002 14:20:35 -0400 (EDT) Message-ID: <3D25E371.8080303@dynamicsoft.com> Date: Fri, 05 Jul 2002 14:20:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] update to caller preferences Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I submitted an update to the caller preferences specification. It should appear in the archives shortly. Until it does, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-06.txt The changes are substantial: * complete rewrite to be based on rfc2533. It amazes me how much of the work we did was already done. Fortunately, this results primarily in a change in presentation, and less of a change in the syntax and overall behavior from a black box perspective. * The media contact parameter is now only used to indicate top level MIME types (audio, video, message), and not full MIME types. Indicating full MIME types is done through the existing "type" feature tag, defined in RFC 2913. THis will break interop with people using the media contact parameter. * Added new "automata" and "events" caller preferences tags. * As a consequence of using an ordered token to represent priorities, we no longer have the ability to handle unknown priorities as equal to normal (I don't think). In addition, a UA can now register multiple priorities, although this is redundant, since the matching operation is the same as before - the call will be routed to a UA which has indicated it supports a priority equal to, or higher than, the priority in the Priority header of the INVITE. * The q value has to appear as the last parameter in the Accept-Contact or Reject-Contact header fields. * The Accept-COntact and Reject-Contact header field can contain explicit preferences for methods and events, even though a proxy computes implicit preferences based on the request (based on the request method and Event header field value, respectively). Explicit preferences always override implicitly derived ones. * Providing preferences for URI are still allowed. However, since they are done as part of the RFC 2533 matching procedure, the scope is restricted. Matches are only done on the user part and domain part. The matching rule is case sensitive match for both. The ability to match on the user part only, and not the domain, has been removed. * The specification used to differentiate between the features expressible in a registration, and those expressable in an Accept-Contact and Reject-Contact. All of those restrictions are removed. Both express feature sets, and can contain the same things. As an example, the spec used to forbid a Contact header in a REGISTER like: Contact: sip:1.2.3.4;mobility="!fixed" since it had a negation. This restriction is removed. * Eliminated the use of the & construct in the Accept-Contact and Reject-Contact header fields. This signficantly changes the scope of feature predicates that can be constructed. An open issue is whether to bring it back by simply allowing for an actual rfc2533 expression in the Accept-Contact header. There are a number of open issues in the spec, all of which are called out. Comments are appreciated on them. Having done the rewrite based on 2533, I am quite happy it was done. Its a significant improvement in the specification. The document is much shorter - don't let the page count fool you; much of it is IANA registrations. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 5 16:13:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15359 for ; Fri, 5 Jul 2002 16:13:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA22454 for sip-archive@odin.ietf.org; Fri, 5 Jul 2002 16:14:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21026; Fri, 5 Jul 2002 15:46:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20995 for ; Fri, 5 Jul 2002 15:46:07 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13454 for ; Fri, 5 Jul 2002 15:45:15 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g65JjXYH028462; Fri, 5 Jul 2002 15:45:34 -0400 (EDT) Message-ID: <3D25F75A.9060504@dynamicsoft.com> Date: Fri, 05 Jul 2002 15:45:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Euchner Martin ICN M SR 3 CC: Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] p-asserted-identity security harmful References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Euchner Martin ICN M SR 3 wrote: > Now I'm confused even more as this sounds like the Spec(T) example is in > fact of more mandatory nature. No, no, no. p-asserted-identity basically has proxies "declaring" the identity of the originator of the request. In order for a proxy to determine what this means, each domain has to define, FOR THAT DOMAIN, how the identity was determined, and how its securely transmitted between proxies. This is not a written specification, or an IETF specification. Its more of an enterprise policy. A proxy in a domain has to know what the enterprise policy for that domain is, in order to know how to properly interpret the asserited identity. Spec(T) is the enterprise policy. The specification gives an example of such a policy. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 5 17:23:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19065 for ; Fri, 5 Jul 2002 17:23:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25543 for sip-archive@odin.ietf.org; Fri, 5 Jul 2002 17:24:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23992; Fri, 5 Jul 2002 16:58:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23961 for ; Fri, 5 Jul 2002 16:58:45 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17423 for ; Fri, 5 Jul 2002 16:57:53 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g65KvxF26056; Fri, 5 Jul 2002 16:57:59 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 15:57:54 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA810A02E4@STNTEXCH2> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , Euchner Martin ICN M SR 3 Cc: Michael Thomas , sip@ietf.org Subject: RE: [Sip] p-asserted-identity security harmful Date: Fri, 5 Jul 2002 15:57:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Let me add to Jonathan's comments that the asserted-identity draft will be an Informational RFC that declares only P- headers (as specified by the sipchange process), and as such it is not empowered to make any kind of normative amendments to RFC3261. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, July 05, 2002 12:46 PM > To: Euchner Martin ICN M SR 3 > Cc: Michael Thomas; Peterson, Jon; sip@ietf.org > Subject: Re: [Sip] p-asserted-identity security harmful > > > > > Euchner Martin ICN M SR 3 wrote: > > Now I'm confused even more as this sounds like the Spec(T) > example is in > > fact of more mandatory nature. > > No, no, no. > > p-asserted-identity basically has proxies "declaring" the identity of > the originator of the request. In order for a proxy to determine what > this means, each domain has to define, FOR THAT DOMAIN, how > the identity > was determined, and how its securely transmitted between > proxies. This > is not a written specification, or an IETF specification. Its > more of an > enterprise policy. A proxy in a domain has to know what the > enterprise > policy for that domain is, in order to know how to properly interpret > the asserited identity. Spec(T) is the enterprise policy. The > specification gives an example of such a policy. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jul 6 01:10:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03129 for ; Sat, 6 Jul 2002 01:10:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA17333 for sip-archive@odin.ietf.org; Sat, 6 Jul 2002 01:10:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA10833; Sat, 6 Jul 2002 00:43:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA10802 for ; Sat, 6 Jul 2002 00:43:46 -0400 (EDT) Received: from webmail30.rediffmail.com (webmail30.rediffmail.com [202.54.124.145] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02750 for ; Sat, 6 Jul 2002 00:42:55 -0400 (EDT) Received: (qmail 7337 invoked by uid 510); 6 Jul 2002 04:43:07 -0000 Date: 6 Jul 2002 04:43:07 -0000 Message-ID: <20020706044307.7336.qmail@webmail30.rediffmail.com> Received: from unknown (203.197.251.7) by rediffmail.com via HTTP; 06 Jul 2002 04:43:07 -0000 MIME-Version: 1.0 From: "Ashhar Farhan" Reply-To: "Ashhar Farhan" To: sip@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Sip] sip examples in the draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org the sip draft contains a number of examples of calls towards the begining and the end. in these, the ip addresses and the domain names are not clearly associated with systems. 1) in the figure 1 example, alice's pc is not clearly marked as pc33.altanta.com, nor is the atlanta.com proxy labelled as atlanta.com (a purist might consider that the proxy is named sip.atlanta.com). further down, the hosts bibbox3.site3.atlanta.com and server10.biloxi.com are not marked in the figure 1 trapezium either. it might be a good idea to write the ip addresses and the FQDN of all the hosts in the network diagram. this is of special relevance because the basic fields like From:, To:, Via:, Contact: and SIP-URL are often confusing to a novice. 2) Section 26.2 gives a number of examples. the ip addresses in these are given without any reference to which hosts they refer to in the figure. - farhan _________________________________________________________ There is always a better job for you at Monsterindia.com. Go now http://monsterindia.rediff.com/jobs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jul 6 11:12:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23066 for ; Sat, 6 Jul 2002 11:12:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13517 for sip-archive@odin.ietf.org; Sat, 6 Jul 2002 11:13:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12565; Sat, 6 Jul 2002 10:53:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12536 for ; Sat, 6 Jul 2002 10:53:10 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22673 for ; Sat, 6 Jul 2002 10:52:19 -0400 (EDT) Received: from jku2.fokus.gmd.de (port-213-20-128-193.reverse.qdsl-home.de [213.20.128.193]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g66EqQC29471; Sat, 6 Jul 2002 16:52:26 +0200 Message-Id: <5.1.0.14.0.20020706164113.00b3d6b8@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 06 Jul 2002 16:51:11 +0200 To: Jonathan Rosenberg , Jiri Kuthan From: Jiri Kuthan Subject: Re: [Sip] MESSAGE advertising in REGISTERs Cc: sip@ietf.org, bcampbell@dynamicsoft.com In-Reply-To: <3D24AD3D.8040505@dynamicsoft.com> References: <5.1.0.14.0.20020703142040.033c0fb8@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I still don't understand why you're opposed to mandatory advertising MESSAGE support in REGISTERs -- I'm not aware of a harm and I am aware of a benefit in some scenarios. Sending a message to a destination which could be known from its ads not to accept it is simply an unnecessary inefficiency. Of course, I'm not worried about scenarios to which you refered and in which this capability is useless. -Jiri At 10:17 PM 7/4/2002, Jonathan Rosenberg wrote: >Jiri Kuthan wrote: >>Can someone tell me why the MESSAGE I-D mandates advertising >>of support in REGISTERs of a MESSAGE-capable UAC only *optionally*? > >Because the system will function without a proxy knowing this ahead of time. To date, we have not mandated the use of caller preferences (which is where this comes from) in other sip extensions, such as UPDATE, PRACK. I think presence mentions that you SHOULD do this, but not RFC 3265 (i.e., it doesnt apply to all events). > >Indeed, since not all methods are mandatory even in baseline SIP, and indeed, rfc3261 doesn't actually mandate anything but OPTIONS, we already have the case that a proxy doesn't know the methods of the UAs that register to it. > >>Making it optional gains little knowledge to a SIP server -- a server does not know anything it could reliably use in its processing logic. > >Sure it does. If it is there, it knows that the UA does or does not support MESSAGE. Its just that its not always there. > >>Think of a SIP server which acts as a proxy server and message store. >>If it knew, that downstream UAS was not capable of processing MESSAGEs, >>it could immediately store an incoming MESSAGE, send 202 upstream, >>and relay the message to first UAC which registers and advertises support >>for MESSAGE in REGISTER. >>Because the server does not know it, it has to relay unnecessarily a message to an upstream UAS, which will deny it. > >That doesn't seem so bad. > >If it bothers you, send an OPTIONS to the UA once it registers. > > > >>Then, whenever a REGISTER arrives, the server will try to dump message store to it, >>(hoping a UAC capable of MESSAGE registered) resulting in quite >>uneffective behaviour. > >Well, that is only one way to handle transmission of undelivered messages to a UA when it comes online. For many reasons, it is not the best way, I think. A better way is allow a UA to query to see if it has any undelivered messages when it registers, and then pull them as needed. This works better in wireless, too. Even if the UA does support MESSAGE, it may not want all of them the moment it connects. > > >-Jonathan R. > > > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PH: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 7 12:36:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25576 for ; Sun, 7 Jul 2002 12:36:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14095 for sip-archive@odin.ietf.org; Sun, 7 Jul 2002 12:37:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12020; Sun, 7 Jul 2002 12:10:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11993 for ; Sun, 7 Jul 2002 12:10:51 -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 MAA24073; Sun, 7 Jul 2002 12:09:57 -0400 (EDT) Message-Id: <200207071609.MAA24073@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Sun, 07 Jul 2002 12:09:56 -0400 Subject: [Sip] I-D ACTION:draft-peterson-sip-identity-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) Author(s) : J. Peterson Filename : draft-peterson-sip-identity-01.txt Pages : 29 Date : 05-Jul-02 The existing mechanisms for expressing identity in the Session Initiation Protocol oftentimes do not permit an administrative domain to verify securely the identity of the originator of a request. This document recommends practices and conventions for authenticating end users, and proposes a way to distribute secure authenticated identities within SIP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-sip-identity-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-peterson-sip-identity-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-peterson-sip-identity-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705141730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-peterson-sip-identity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-peterson-sip-identity-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705141730.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 7 12:56:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26339 for ; Sun, 7 Jul 2002 12:56:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14883 for sip-archive@odin.ietf.org; Sun, 7 Jul 2002 12:56:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13946; Sun, 7 Jul 2002 12:34:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13540 for ; Sun, 7 Jul 2002 12:34:00 -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 MAA25356; Sun, 7 Jul 2002 12:33:06 -0400 (EDT) Message-Id: <200207071633.MAA25356@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Sun, 07 Jul 2002 12:33:06 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-sec-agree-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : Security Mechanism Agreement for SIP Sessions Author(s) : J. Arkko et al. Filename : draft-ietf-sip-sec-agree-04.txt Pages : 17 Date : 05-Jul-02 SIP has a number of security mechanisms. Some of them have been built in to the SIP protocol, such as HTTP authentication or secure attachments. These mechanisms have even alternative algorithms and parameters. SIP does not currently provide any mechanism for selecting which security mechanisms to use between two entities. In particular, even if some mechanisms such as OPTIONS were used to make this selection, the selection would be vulnerable against the Bidding-Down attack. This document defines three header fields for negotiating the security mechanisms within SIP between a SIP entity and its next SIP hop. A SIP entity applying this mechanism must always require some minimum security (i.e. integrity protection) from all communicating parties in order to secure the negotiation, but the negotiation can agree on which specific minimum security is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-sec-agree-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sec-agree-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705142509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sec-agree-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sec-agree-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705142509.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 7 12:58:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26430 for ; Sun, 7 Jul 2002 12:58:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14938 for sip-archive@odin.ietf.org; Sun, 7 Jul 2002 12:59:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13835; Sun, 7 Jul 2002 12:34:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13515 for ; Sun, 7 Jul 2002 12:33:58 -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 MAA25366; Sun, 7 Jul 2002 12:33:07 -0400 (EDT) Message-Id: <200207071633.MAA25366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Sun, 07 Jul 2002 12:33:07 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-callerprefs-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities Author(s) : H. Schulzrinne, J. Rosenberg Filename : draft-ietf-sip-callerprefs-06.txt Pages : 28 Date : 05-Jul-02 This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which URIs a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request headers, Accept-Contact, Reject- Contact and Request-Disposition, which specify the caller's preferences. The extension also defines new parameters for the Contact header that describe the characterstics of a UA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-callerprefs-06.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-callerprefs-06.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: <20020705142521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-callerprefs-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-callerprefs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705142521.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 7 13:01:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26543 for ; Sun, 7 Jul 2002 13:01:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15480 for sip-archive@odin.ietf.org; Sun, 7 Jul 2002 13:02:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13896; Sun, 7 Jul 2002 12:34:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13504 for ; Sun, 7 Jul 2002 12:33:58 -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 MAA25345; Sun, 7 Jul 2002 12:33:06 -0400 (EDT) Message-Id: <200207071633.MAA25345@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Sun, 07 Jul 2002 12:33:05 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-nat-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing Author(s) : J. Rosenberg, J. Weinberger, H. Schulzrinne Filename : draft-ietf-sip-nat-02.txt Pages : 8 Date : 05-Jul-02 The Session Initiation Protocol (SIP) operates over UDP and TCP. When used with UDP, responses to requests are returned to the source address the request came from, but from the port written into the topmost Via header of the request. This behavior is not desirable in many cases, most notably, when the client is behind a NAT. This extension defines a new parameter for the Via header, called rport, that allows a client to request that the server send the response back to the source IP address and port where the request came from. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-nat-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-nat-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-nat-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: <20020705142459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-nat-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-nat-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705142459.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 7 13:03:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26564 for ; Sun, 7 Jul 2002 13:03:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15546 for sip-archive@odin.ietf.org; Sun, 7 Jul 2002 13:04:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13986; Sun, 7 Jul 2002 12:34:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13553 for ; Sun, 7 Jul 2002 12:34:01 -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 MAA25376; Sun, 7 Jul 2002 12:33:08 -0400 (EDT) Message-Id: <200207071633.MAA25376@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Sun, 07 Jul 2002 12:33:08 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-09.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : Session Initiation Protocol Extension for Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-09.txt Pages : 25 Date : 05-Jul-02 This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new header fields, Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-session-timer-09.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-session-timer-09.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: <20020705142532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705142532.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 7 21:52:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17137 for ; Sun, 7 Jul 2002 21:52:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA04344 for sip-archive@odin.ietf.org; Sun, 7 Jul 2002 21:53:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03784; Sun, 7 Jul 2002 21:35:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03754 for ; Sun, 7 Jul 2002 21:35:06 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16016 for ; Sun, 7 Jul 2002 21:34:14 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g681YlN19298; Sun, 7 Jul 2002 20:34:47 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Jul 2002 20:34:34 -0500 Message-ID: From: "Sriram Parameswar" To: "'seanol@microsoft.com'" , "'sip@ietf.org'" Date: Sun, 7 Jul 2002 20:34:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2261F.9BB72D30" Subject: [Sip] draft-olson-sip-content-indirect-mech-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C2261F.9BB72D30 Content-Type: text/plain; charset="iso-8859-1" Sean, Well written draft! In Section 3.6 'Specifying the type of the indirect content' - it must be clearly noted that when including the content-type of the indirect content in the payload - there must be Content headers specifying that payload. Along with some textual description added to section 3.6, the example in that section will change to look something like: Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.bogus.com/the-indirect-content" Content-Type: text/plain Content-Length: ... Content-Type: application/sdp You may also want to add a small section on how this mechanism satisfies the requirements laid down in the requirements document (draft-ietf-sipping-content-indirect-00). Just as an after thought, the additional Content-Type may also be message/sipfrag instead of text/plain. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C2261F.9BB72D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-olson-sip-content-indirect-mech-00

Sean,

Well written draft!  In = Section 3.6 'Specifying the type of the = indirect content' - it must be clearly noted that when including the = content-type of the indirect content in the payload - there must be = Content headers specifying that payload. Along with some textual = description added to section 3.6,  the example in that section = will change to look something like:

Content-Type: message/external-body; = access-type=3D"URL"; expiration=3D"Mon, 24 June 2002 = 09:00:00 GMT"; URL=3D"http://www.bogus.com/the-indirect-content" =

Content-Type: text/plain
Content-Length: ...
<CRLF>
Content-Type: application/sdp =
<CRLF>
You may also want to add a small = section on how this mechanism satisfies the requirements laid down in = the requirements document (draft-ietf-sipping-content-indirect-00). = Just as an after thought, the additional Content-Type may also be = message/sipfrag instead of text/plain.

Regards,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: = 972-685-8540
Interactive Multimedia Server (IMS) = Fax: 972-684-3986
Nortel Networks, Richardson = USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C2261F.9BB72D30-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 8 01:34:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24813 for ; Mon, 8 Jul 2002 01:34:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA22905 for sip-archive@odin.ietf.org; Mon, 8 Jul 2002 01:35:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20050; Mon, 8 Jul 2002 01:12:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19992 for ; Mon, 8 Jul 2002 01:12:52 -0400 (EDT) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24206 for ; Mon, 8 Jul 2002 01:11:59 -0400 (EDT) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id g685Ci926713 for ; Mon, 8 Jul 2002 07:12:44 +0200 Received: from vies194a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g685Chan007734 for ; Mon, 8 Jul 2002 07:12:43 +0200 (MET DST) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <321KAXQA>; Mon, 8 Jul 2002 07:12:42 +0200 Message-ID: From: Postmann Erwin To: "'sip@ietf.org'" Date: Mon, 8 Jul 2002 07:12:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2263E.15FBDA50" Subject: [Sip] SIP and multicast Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C2263E.15FBDA50 Content-Type: text/plain; charset="iso-8859-1" Dear SIP experts, I have a question regarding the support of multicast within SIP: How is it possible to establish a connection towards a group of different users in parallel? Is it possible to send a SIP INVITE/MESSAGE message to a multicast address, in such a way that members of this multicast group can receive them in parallel? Best regards Erwin Postmann SIEMENS AG Austria Program and System Engineering Mobile Communication Systems Systems, Standardisation and Technology Autokaderstrasse 29 A-1210 Vienna Tel: +43.5.1707.21398 Fax: +43.5.1707.51924 GSM: +43.676.4915686 email: erwin.postmann@siemens.com Important Note: This e-mail may contain trade secrets or privileged, undisclosed or confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. Siemens Aktiengesellschaft ------_=_NextPart_001_01C2263E.15FBDA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+U0lQIGFu ZCBtdWx0aWNhc3Q8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9MiBG QUNFPSJBcmlhbCI+RGVhciBTSVAgZXhwZXJ0cyw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+SSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBzdXBwb3J0 IG9mIG11bHRpY2FzdCB3aXRoaW4gU0lQOjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y IEZBQ0U9IkFyaWFsIj5Ib3cgaXMgaXQgcG9zc2libGUgdG8gZXN0YWJsaXNoIGEgY29ubmVjdGlv biB0b3dhcmRzIGEgZ3JvdXAgb2YgZGlmZmVyZW50IHVzZXJzIGluIHBhcmFsbGVsPyA8L0ZPTlQ+ DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SXMgaXQgcG9zc2libGUgdG8g c2VuZCBhIFNJUCBJTlZJVEUvTUVTU0FHRSBtZXNzYWdlIHRvIGEgbXVsdGljYXN0IGFkZHJlc3Ms IGluIHN1Y2ggYSB3YXkgdGhhdCBtZW1iZXJzIG9mIHRoaXMgbXVsdGljYXN0IGdyb3VwIGNhbiBy ZWNlaXZlIHRoZW0gaW4gcGFyYWxsZWw/PC9GT05UPjwvUD4NCjxCUj4NCjxCUj4NCg0KPFA+PEZP TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5CZXN0IHJlZ2FyZHM8L0ZPTlQ+PEI+PC9CPg0KPC9QPg0K DQo8UD48Qj48ST48Rk9OVCBDT0xPUj0iIzAwMDA4MCIgRkFDRT0iQXJpYWwiPkVyd2luIFBvc3Rt YW5uPC9GT05UPjwvST48L0I+PEk+PC9JPg0KPC9QPg0KDQo8UD48Qj48Rk9OVCBGQUNFPSJBcmlh bCI+U0lFTUVOUyBBRyBBdXN0cmlhPC9GT05UPjwvQj4NCjxCUj48Rk9OVCBTSVpFPTEgRkFDRT0i QXJpYWwiPlByb2dyYW0gYW5kIFN5c3RlbSBFbmdpbmVlcmluZzwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTEgRkFDRT0iQXJpYWwiPk1vYmlsZSBDb21tdW5pY2F0aW9uIFN5c3RlbXMgPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+U3lzdGVtcywgU3RhbmRhcmRpc2F0aW9uIGFu ZCBUZWNobm9sb2d5PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi PkF1dG9rYWRlcnN0cmFzc2UgMjk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs Ij5BLTEyMTAgVmllbm5hPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp YWwiPlRlbDombmJzcDsmbmJzcDsmbmJzcDsgKzQzLjUuMTcwNy4yMTM5ODwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZheDombmJzcDsmbmJzcDsmbmJzcDsgKzQzLjUuMTcw Ny41MTkyNDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkdTTTombmJzcDsm bmJzcDsmbmJzcDsgKzQzLjY3Ni40OTE1Njg2PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF PSJBcmlhbCI+ZW1haWw6Jm5ic3A7IGVyd2luLnBvc3RtYW5uQHNpZW1lbnMuY29tPC9GT05UPg0K PC9QPg0KDQo8UD48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0xIEZBQ0U9IkFyaWFsIj5JbXBv cnRhbnQgTm90ZTogPC9GT05UPg0KPEJSPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTEgRkFD RT0iQXJpYWwiPlRoaXMgZS1tYWlsIG1heSBjb250YWluIHRyYWRlIHNlY3JldHMgb3IgcHJpdmls ZWdlZCwgdW5kaXNjbG9zZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLjwvRk9OVD4gDQo8 QlI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MSBGQUNFPSJBcmlhbCI+SWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IHJldmlldyw8L0ZPTlQ+Jm5ic3A7PEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj4gPC9G T05UPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTEgRkFDRT0iQXJpYWwiPmNvcHlpbmcgPC9G T05UPg0KPEJSPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTEgRkFDRT0iQXJpYWwiPm9yIGRp c3RyaWJ1dGlvbiBvZiBpdCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBQbGVhc2UgaW5mb3JtIHVz IGltbWVkaWF0ZWx5IGFuZCBkZXN0cm95IHRoZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgQ09MT1I9IiMw MDAwMDAiIFNJWkU9MSBGQUNFPSJBcmlhbCI+b3JpZ2luYWwgdHJhbnNtaXR0YWwuIFRoYW5rIHlv dSBmb3IgeW91ciBjb29wZXJhdGlvbi48L0ZPTlQ+PEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj4g PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0xIEZBQ0U9IkFy aWFsIj5TaWVtZW5zIEFrdGllbmdlc2VsbHNjaGFmdDwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPC9C T0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C2263E.15FBDA50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 8 04:24:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07817 for ; Mon, 8 Jul 2002 04:24:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA01403 for sip-archive@odin.ietf.org; Mon, 8 Jul 2002 04:25:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29937; Mon, 8 Jul 2002 03:55:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29906 for ; Mon, 8 Jul 2002 03:55:52 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07217 for ; Mon, 8 Jul 2002 03:54:59 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g687tiRb025970; Mon, 8 Jul 2002 09:55:44 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g687tha9023119; Mon, 8 Jul 2002 10:55:43 +0300 (EET DST) Message-ID: <3D29457F.AE27762C@lmf.ericsson.se> Date: Mon, 08 Jul 2002 10:55:43 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'sip@ietf.org'" Subject: Re: [Sip] Manyfolks questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark, this is addressed in the second paragraph of page 10: " Note that the rules above apply to the desired strength-tag "none" as well. This way, a user agent that supports quality of service but does not intend to use them, adds desired status lines with the strength-tag "none". Since this tag can be upgraded in the answer, as described in Section 5.2, the answerer can request quality of service reservation without a need of another offer/answer exchange. " This corresponds to your option number 2. Gonzalo Mark Watson wrote: > > If the UAC knows of no preconditions for a session, but supports the > manyfolks mechanism, what should it indicate in the INVITE in order to give > the UAS the opportunity to indicate that it has (presumably local) > preconditions ? > > 1) Indicate 'Supported: preconditions' in the INVITE, but do not include > a=cur: a=des: etc. in the SDP offer. Then the UAS can return the a=cur: > a=des: in the SDP answer. > > OR > > 2) Indicate 'Supported: preconditions' in the INVITE and include the > attributes but with desired status 'none' > > If it's (1), we need description of the answerer adding the pre-condition > attributes when they were not present in the offer. > > If it's (2), then it should be mandatory to include the pre-condition > attributes if you include 'Supported: preconditions'. > > I couldn't find either in the specification, but perhaps I didn't look hard > enough! > > Regards, > > Mark > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of 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 http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 8 07:00:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10188 for ; Mon, 8 Jul 2002 07:00:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA09104 for sip-archive@odin.ietf.org; Mon, 8 Jul 2002 07:01:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07672; Mon, 8 Jul 2002 06:31:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07641 for ; Mon, 8 Jul 2002 06:31:30 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09659 for ; Mon, 8 Jul 2002 06:30:35 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g68AVFRb006608; Mon, 8 Jul 2002 12:31:15 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g68AVEa9005258; Mon, 8 Jul 2002 13:31:15 +0300 (EET DST) Message-ID: <3D2969F1.4BBB696D@lmf.ericsson.se> Date: Mon, 08 Jul 2002 13:31:13 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'sip@ietf.org'" , "'gonzalo.camarillo@ericsson.com'" , Jonathan Rosemberg , "Vijay K. Gurbani" References: <9BF66EBF6BEFD942915B4D4D45C051F377A26A@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: SIP and SigComp draft comment. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Adam, What you are describing is what I meant the draft to say. In addition, I also agree with you that some clarification is needed, so I will add some text about it. Below you have the last paragraph of section 3. This paragraph deals with a proxy/UAC sending the first INVITE: "Regardless of whether the request is sent compressed or not, if a client would like to receive subsequent requests within the same dialog compressed, this client SHOULD add the parameter comp=sigcomp to the URI in the Contact header field if it is a user agent client. If the client is a proxy, it SHOULD add the parameter comp=sigcomp to its URI in the Record-Route header field." the paragraph above is supposed to address what you reffer to as "a proxy tailoring its Record-Route entry for B". I believe that if we do the following addition the paragraph would be clearer. OLD: ... requests within the same dialog compressed. NEW: ... requests within the same dialog in the UAS->UAC direction compressed. I will also add that if a proxy/UAC sends a request compressed (e.g., a proxy to a wireless terminals that had REGISTERED a comp=sigcomp SIP URI), it SHOULD add comp=sigcomp to its RR entry. The paragraph below is the second paragraph of section 4: " A proxy performing Record-Route inspects the Record-Route header field in the response and the Contact header field in the request that triggered this response (see example in Section 7). It looks for the URI of the next upstream (closer to the user agent client) hop in the route set. If this URI contains the parameter comp=sigcomp, the proxy SHOULD add comp=sigcomp to its entry in the Record-Route header field." The paragraph above is supposed to address the rewriting of the Record-Route entry in order to make it suitable for A's consumption. Let me know if you think something should be clarified. With the clarifications above, the example you gave will work just fine. Some people have expressed concerns about the meaning of comp=sigcomp. In the current draft it means *willingness* (clarification will be added), whereas folks have proposed that it should mean only *support*. If the parameter meant support, in scenarios like the one Adam showed: > > +---+ +----+ +----+ +----+ +---+ > | A |...| P1 |---| P2 |---| P3 |...| B | > +---+ +----+ +----+ +----+ +---+ P2 would know that P1 and P3 supported sigcomp, but it would have no data available to make the decision about whether or not to send compress messages towards both proxies. However, if the parameter means willingness, it will be clear for P2 that it does not need to compress any message. And talking into consideration that wireless terminals (3G or not) will typically REGISTER a comp=sigcomp SIP URI, the last proxy (i.e., P3) will typically know that it has to RR with comp=sigcomp in the first INVITE when it consults the registrar. Thanks for the feedback, Gonzalo Adam Roach wrote: > > There has been a bit of discussion about how to handle > Contact, Route, and Record-Route with the "comp=sigcomp" > parameter. > > There's a closely related issue that hasn't yet been touched > on, though: when the called party issues a request, the > "comp=sigcomp" headers end up being essentially in the wrong > place. > > I'll demonstrate by way of an example. > > +---+ +----+ +----+ +----+ +---+ > | A |...| P1 |---| P2 |---| P3 |...| B | > +---+ +----+ +----+ +----+ +---+ > > A and B are wireless terminals with very low bandwidth > links (and, consequently, use SigComp). P1, P2, and P3 are > all proxies on the network. > > A sends an INVITE to B. Assuming that each proxy > inserts its record-routes so that A gets the proper > route-set, you get the following at B: > > Record-Route: > Record-Route: > Record-Route: > Contact: > > This is, of course, stored in B as the route set: > ,,, > > > The response to the request delivers the same set of Record-Routes > to A, but with a contact of "sip:userb@B;comp=sigcomp": > ,,, > > > So, A's route is absolutely correct; it will compress the message > sent to P1, and P3 will compress the message sent to B. Unfortunately, > B's route is really screwy. If it obeys the "comp" parameters, B > *won't* compress any requests in this dialog, so you'll be sending > uncompressed messages over the radio link. And, in a bitter irony, > P2 will waste cycles compressing the messages sent to P1 -- which > turns out to be completely unnecessary. In fact, it exacerbates the > fact that the B -> P3 request was sent uncompressed. > > If we have the proxies tailor the route set for B, the same problem > happens, in the opposite direction. > > The solution lies in step 8, detailed in section 16.7 of > 2543bis-09. > > In this case, the proxies would tailor the inserted "Record-Routes" > in the request for B's consumption: > > Record-Route: > Record-Route: > Record-Route: > Contact: > > Then, as the INVITE response passes back through P3 and P1, they > would each modify the Record-Route headers so that they are > appropriate for A's consumption: > > Record-Route: > Record-Route: > Record-Route: > Contact: > > Even though it's described in SIP, this usage should probably be > explicitly mentioned in in the SIP SigComp draft; otherwise, we > run the risk of having nodes do strange things. > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 8 08:18:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11661 for ; Mon, 8 Jul 2002 08:18:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA12270 for sip-archive@odin.ietf.org; Mon, 8 Jul 2002 08:19:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10578; Mon, 8 Jul 2002 07:43:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10547 for ; Mon, 8 Jul 2002 07:43:25 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10999 for ; Mon, 8 Jul 2002 07:42:32 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g68BhFRb023746; Mon, 8 Jul 2002 13:43:16 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g68BhCa9010898; Mon, 8 Jul 2002 14:43:13 +0300 (EET DST) Message-ID: <3D297ACE.A364B5A4@lmf.ericsson.se> Date: Mon, 08 Jul 2002 14:43:10 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bert Culpepper CC: "'Alexeitsev, D'" , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <000701c22370$a9001760$6600a8c0@bculpepperpc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bert Culpepper wrote: > > Hi Denis, > > I don't know that the use of TCP is a substitute for 100rel. PRACK > provides knowledge that the receiver's UA "processed" the provisional > response. TCP only guarantees the message was received at the host. I > may be off-base here, if so others can correct me. PRACK is end-to-end. TCP/UDP/SCTP is hop-by-hop. That is, if you send a response using TCP you know that it will reach the next proxy, but you know nothing about the remote UA. About special casing the scenario where all the Via headers show that TCP is used, it would be adding extra complexity for a little gain (KISS). In addition, think of the interactions with remote Contact updates from TCP to UDP using re-INVITEs. Regards, Gonzalo > > Regards, > Bert > > Alexeitsev, D wrote: > > > > Hello, > > > > comment inline > > > > > [DA] Is the use of the TCP/SCTP is good enough to say that > > > e2e provisional responses with answer are reliable? > > > > I don't think so for "reliable provisional responses". > > Retransmissions > > are not needed when using TCP but a PRACK from the UAC is still needed > > for "reliable provisional responses". > > > > [DA] I mean, that the 100rel is only needed for the UDP. The > > reliable transport protocols do not need a help from session > > control protocols. > > > > Greetings, > > Denis Alexeitsev > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 8 08:24:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11866 for ; Mon, 8 Jul 2002 08:24:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA12417 for sip-archive@odin.ietf.org; Mon, 8 Jul 2002 08:25:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10932; Mon, 8 Jul 2002 07:51:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10901 for ; Mon, 8 Jul 2002 07:51:53 -0400 (EDT) Received: from esuims01.esamsungumit.com (mail.esamsungumit.com [203.122.29.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11182 for ; Mon, 8 Jul 2002 07:50:54 -0400 (EDT) Date: Mon, 8 Jul 2002 17:21:49 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <89CFEE6120A0224EA07781892EC0B48B899749@esuims01.esamsungumit.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [Sip] Re: SIP and SigComp draft comment. Thread-Index: AcImbU08mmO44hlNQxOojPwj54NcAAACCRKw From: "ShavinderPal Singh" To: , "Jonathan Rosemberg" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA10902 Subject: [Sip] Authentication for re-INVITE. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Is a SIP proxy supposed to Authenticate a re-INVITE also? If no, then if some proxy in Authenticating and it asks for Auth Info from the UA, what is the UA supposed to do? Is it mandatory that it should send the Auth Info? Please suggest! Thanks & Regards s Ph.: 091-124-6383474 (e 250) __________________________________________ I had a good grip on life, but then the handle broke. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 8 09:40:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14147 for ; Mon, 8 Jul 2002 09:40:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17295 for sip-archive@odin.ietf.org; Mon, 8 Jul 2002 09:41:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14132; Mon, 8 Jul 2002 08:59:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14107 for ; Mon, 8 Jul 2002 08:59:28 -0400 (EDT) Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12663 for ; Mon, 8 Jul 2002 08:58:33 -0400 (EDT) Received: from [10.10.13.95] (helo=ranjit) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 17RY2K-0002fb-00; Mon, 08 Jul 2002 18:24:40 +0530 Message-ID: <016a01c2267f$5e29e060$5f0d0a0a@ranjit> From: "Ranjit Avasarala" To: "ShavinderPal Singh" , , "Jonathan Rosemberg" References: <89CFEE6120A0224EA07781892EC0B48B899749@esuims01.esamsungumit.com> Subject: Re: [Sip] Authentication for re-INVITE. Date: Mon, 8 Jul 2002 18:30:00 +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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't think proxy needs to authenticate re-invite, as re-invite is used for changing session parameters of an existing call Ranjit ----- Original Message ----- From: ShavinderPal Singh To: ; Jonathan Rosemberg Sent: Monday, July 08, 2002 5:21 PM Subject: [Sip] Authentication for re-INVITE. > > Is a SIP proxy supposed to Authenticate a re-INVITE also? If no, then if > some proxy in Authenticating and it asks for Auth Info from the UA, what > is the UA supposed to do? Is it mandatory that it should send the Auth > Info? > > Please suggest! > > Thanks & Regards > s > > Ph.: 091-124-6383474 (e 250) > __________________________________________ > I had a good grip on life, but then the handle broke. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 8 09:48:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14508 for ; Mon, 8 Jul 2002 09:48:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17683 for sip-archive@odin.ietf.org; Mon, 8 Jul 2002 09:49:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15361; Mon, 8 Jul 2002 09:14:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15314 for ; Mon, 8 Jul 2002 09:14:01 -0400 (EDT) Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13266 for ; Mon, 8 Jul 2002 09:13:07 -0400 (EDT) Received: from [10.10.13.95] (helo=ranjit) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 17RYGu-0002oa-00 for ; Mon, 08 Jul 2002 18:39:44 +0530 Message-ID: <018501c22681$7918cba0$5f0d0a0a@ranjit> From: "Ranjit Avasarala" To: "sip-ietf" Date: Mon, 8 Jul 2002 18:45:04 +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 Content-Transfer-Encoding: 7bit Subject: [Sip] sip phone query Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Like when i want to register any event in server, I use SUBSCRIBE method. How is this realized in SIP Phone? How do I specify event name, etc, using a SIP Phone? Will there be any key or should I dial any digit... Thanks Ranjit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 8 12:11:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22225 for ; Mon, 8 Jul 2002 12:11:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29838 for sip-archive@odin.ietf.org; Mon, 8 Jul 2002 12:12:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26390; Mon, 8 Jul 2002 11:47:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26358 for ; Mon, 8 Jul 2002 11:47:05 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20604 for ; Mon, 8 Jul 2002 11:46:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g68FkGO7002329; Mon, 8 Jul 2002 11:46:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <32C1T5B1>; Mon, 8 Jul 2002 11:46:29 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2BE@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'ShavinderPal Singh'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Authentication for re-INVITE. Date: Mon, 8 Jul 2002 11:46:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: ShavinderPal Singh [mailto:ShavinderPal.Singh@esamsungumit.com] > > Is a SIP proxy supposed to Authenticate a re-INVITE also? This is really a question for the sip-implementors mailing list. See the bottom of this message (and every other message on this mailing list) for further details. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 8 16:10:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06386 for ; Mon, 8 Jul 2002 16:10:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20397 for sip-archive@odin.ietf.org; Mon, 8 Jul 2002 16:10:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15493; Mon, 8 Jul 2002 15:21:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15462 for ; Mon, 8 Jul 2002 15:20:58 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04097 for ; Mon, 8 Jul 2002 15:20:04 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g68JKor36201; Mon, 8 Jul 2002 14:20:51 -0500 (CDT) Message-ID: <3D29E679.7060405@dynamicsoft.com> Date: Mon, 08 Jul 2002 14:22:33 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org References: <5.1.0.14.0.20020703142040.033c0fb8@iptel.org> <5.1.0.14.0.20020703200900.00b3d110@iptel.org> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: MESSAGE advertising in REGISTERs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I do not understand why we would expect support of MESSAGE to give a client a higher requirement for registration than for clients that do not support MESSAGE. Jiri Kuthan wrote: > Though advertising MESSAGE capability in REGISTERs does > not hurt in any scenario, not advertising hurts in some. > That's why I would much prefer having it as a MUST. > > -Jiri > > At 06:51 PM 7/3/2002, Ben Campbell wrote: > >>Certainly it will be needed to make many server related scenarios work. It is optional because MESSAGE can also be used in a pure end-to-end mode without assuming that such servers exist. For example, a MESSAGE UAC may discover the contact for a MESSAGE UAS from presence information (i.e. a contact in a presence doc), then send the MESSAGE request directly with no intervening servers. In this architecture, there is not necessarily a need to advertise support at a registrar. >> >>Jiri Kuthan wrote: >> >>>Can someone tell me why the MESSAGE I-D mandates advertising >>>of support in REGISTERs of a MESSAGE-capable UAC only *optionally*? >>>Making it optional gains little knowledge to a SIP server -- a server does not know anything it could reliably use in its processing logic. >>>Think of a SIP server which acts as a proxy server and message store. >>>If it knew, that downstream UAS was not capable of processing MESSAGEs, >>>it could immediately store an incoming MESSAGE, send 202 upstream, >>>and relay the message to first UAC which registers and advertises support >>>for MESSAGE in REGISTER. >>>Because the server does not know it, it has to relay unnecessarily a message to an upstream UAS, which will deny it. Then, whenever a REGISTER arrives, the server will try to dump message store to it, >>>(hoping a UAC capable of MESSAGE registered) resulting in quite >>>uneffective behaviour. >>>-Jiri >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 04:07:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15684 for ; Tue, 9 Jul 2002 04:07:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13032 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 04:08:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10898; Tue, 9 Jul 2002 03:31:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10867 for ; Tue, 9 Jul 2002 03:31:28 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15000 for ; Tue, 9 Jul 2002 03:30:36 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g697VOrU023775; Tue, 9 Jul 2002 09:31:24 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g697VNa9008447; Tue, 9 Jul 2002 10:31:23 +0300 (EET DST) Message-ID: <3D2A914B.2EFC4BA3@lmf.ericsson.se> Date: Tue, 09 Jul 2002 10:31:23 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Salva Rey CC: sip@ietf.org Subject: Re: [Sip] Forking proxy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Since the proxy will CANCEL all the branches but the one that sent the final response, you do not really care about what happens with that provisional response that got into the race condition. Besides, the idea of reliable provisional responses is that the proxy is not aware of whether or not a particular response was sent reliably. The reliability mechanism is end-to-end. Gonzalo Salva Rey wrote: > > Hi all, > > a doubt regarding forking proxies, > > why would a proxy do if forked an INVITE request, it got back some reliable > provisional responses that established some early dialogs at the UAC, and > then one of the UAS's sends a final response 200 oK. If the other early > dialogs try to send further reliable provisional responses this wont get > through the proxy since a final response was already sent on the response > context. Should the proxy behaviour not only forward immediately 200ok > responses to INVITE, but also reliable responses ? > > best regards > Salva > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of 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 http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 04:31:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16500 for ; Tue, 9 Jul 2002 04:31:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14502 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 04:31:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12934; Tue, 9 Jul 2002 04:05:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12859 for ; Tue, 9 Jul 2002 04:05:02 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15617; Tue, 9 Jul 2002 04:04:09 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6984wRb022612; Tue, 9 Jul 2002 10:04:58 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g6984wa9010916; Tue, 9 Jul 2002 11:04:58 +0300 (EET DST) Message-ID: <3D2A9929.8F3ED2EC@lmf.ericsson.se> Date: Tue, 09 Jul 2002 11:04:57 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: rohan@cisco.com, sip@ietf.org, sipping@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean, Sean Olson wrote: > > This is a very interesting problem. Should the requirements > include the ability to deal with intermediaries such as > NAT/firewalls that may not strictly be SIP entities? Also, I > wonder if the proxy-proxy connection problem is as critical > as the UAC-proxy connection reuse problem. Might SCTP be a > better solution for proxy-proxy connection management? Both SCTP and TCP have the problem described in this draft, IMO. However, this problem would be solvable providing the proper port number in the Record-Route entry. Assuming that SIP implementations check if they have an existing connection with a transport address (destination IP address and port number) before opening another one, everything would work fine. I see that the mechanism described in the draft has the advantage of keeping the sender from worring about which ephemeral port is used to send the request. Is there any other advantage if compared with Record-Route entries with port numbers? If so, it should be discussed in the draft. In addition, I would add to the section about the problem statement that if two SIP entities establish two TCP/SCTP connections rather than one, the congestion avoidance data is not shared by the connections. This may trigger a too aggressive behavior or a too conservative behavior ehrn compared to the one achieved by using only one connection. Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 04:59:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16912 for ; Tue, 9 Jul 2002 04:59:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15823 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 04:59:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14152; Tue, 9 Jul 2002 04:30:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13980 for ; Tue, 9 Jul 2002 04:30:28 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16438; Tue, 9 Jul 2002 04:29:34 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g698UOrU011172; Tue, 9 Jul 2002 10:30:24 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g698UNa9012882; Tue, 9 Jul 2002 11:30:23 +0300 (EET DST) Message-ID: <3D2A9F1E.7D400D1E@lmf.ericsson.se> Date: Tue, 09 Jul 2002 11:30:22 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson , rohan@cisco.com, sip@ietf.org, sipping@ietf.org References: <3D2A9929.8F3ED2EC@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Before I had missed that this draft is supposed to fill the role of the old Translate header in the old sip-nat draft. I believe that this should be mentioned, since it is an important advantage over the Record-Route mechanism. Gonzalo Gonzalo Camarillo wrote: > > Sean, > > Sean Olson wrote: > > > > This is a very interesting problem. Should the requirements > > include the ability to deal with intermediaries such as > > NAT/firewalls that may not strictly be SIP entities? Also, I > > wonder if the proxy-proxy connection problem is as critical > > as the UAC-proxy connection reuse problem. Might SCTP be a > > better solution for proxy-proxy connection management? > > Both SCTP and TCP have the problem described in this draft, IMO. > > However, this problem would be solvable providing the proper port number > in the Record-Route entry. Assuming that SIP implementations check if > they have an existing connection with a transport address (destination > IP address and port number) before opening another one, everything would > work fine. > > I see that the mechanism described in the draft has the advantage of > keeping the sender from worring about which ephemeral port is used to > send the request. Is there any other advantage if compared with > Record-Route entries with port numbers? If so, it should be discussed in > the draft. > > In addition, I would add to the section about the problem statement that > if two SIP entities establish two TCP/SCTP connections rather than one, > the congestion avoidance data is not shared by the connections. This may > trigger a too aggressive behavior or a too conservative behavior ehrn > compared to the one achieved by using only one connection. > > Gonzalo > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 10:01:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25706 for ; Tue, 9 Jul 2002 10:01:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05810 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 10:02:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02567; Tue, 9 Jul 2002 09:30:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02482 for ; Tue, 9 Jul 2002 09:30:06 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24279; Tue, 9 Jul 2002 09:29:12 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g69DTwrU001337; Tue, 9 Jul 2002 15:29:58 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g69DTva9006950; Tue, 9 Jul 2002 16:29:57 +0300 (EET DST) Message-ID: <3D2AE555.A8039ADD@lmf.ericsson.se> Date: Tue, 09 Jul 2002 16:29:57 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Sean Olson , rohan@cisco.com, sip@ietf.org, sipping@ietf.org References: <3D2A9929.8F3ED2EC@lmf.ericsson.se> <3D2A9F1E.7D400D1E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, RFC3261/bis-9 mainly talks about using a single connection (or, one in each direction) for a single transaction, and the connect-reuse draft talks about being able to use a single connection for messages in both direction, for a single session. Sometimes, however, when we talk about "reuse of connection" we mean when a single connection (or, one in each direction) is used for multiple sessions. I think it would be a good idea to mention that that kind of "reuse" is out of the scope of the draft. Otherwise the draft subject should more clear indicate what kind of reuse it refers to... Of course, once a single connection is established, according to the connect-reuse draft, it MAY be used for multiple sessions, but that's not the scope of the draft, so... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 10:01:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25725 for ; Tue, 9 Jul 2002 10:01:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05841 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 10:02:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02332; Tue, 9 Jul 2002 09:26:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18203 for ; Mon, 8 Jul 2002 22:52:26 -0400 (EDT) Received: from services1.dasecurenetworks.com (adsl-64-217-197-215.dsl.rcsntx.swbell.net [64.217.197.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28087 for ; Mon, 8 Jul 2002 22:51:08 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services1.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g692TgV27235; Mon, 8 Jul 2002 21:29:46 -0500 Message-ID: <3D2A4FE5.8E0CA9CF@infravast.com> Date: Mon, 08 Jul 2002 21:52:21 -0500 From: Chris Martin Reply-To: chris@infravast.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Ranjit Avasarala CC: ShavinderPal Singh , sip@ietf.org, Jonathan Rosemberg Subject: Re: [Sip] Authentication for re-INVITE. References: <89CFEE6120A0224EA07781892EC0B48B899749@esuims01.esamsungumit.com> <016a01c2267f$5e29e060$5f0d0a0a@ranjit> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ranjit Avasarala wrote: > > I don't think proxy needs to authenticate re-invite, as re-invite is used > for changing session parameters of an existing call For this very reason you should reauthenticate...so that someone doesnt spoof a forged INVITE with bad parameters within it back to the client. > > Ranjit > ----- Original Message ----- > From: ShavinderPal Singh > To: ; Jonathan Rosemberg > Sent: Monday, July 08, 2002 5:21 PM > Subject: [Sip] Authentication for re-INVITE. > > > > > Is a SIP proxy supposed to Authenticate a re-INVITE also? If no, then if > > some proxy in Authenticating and it asks for Auth Info from the UA, what > > is the UA supposed to do? Is it mandatory that it should send the Auth > > Info? > > > > Please suggest! > > > > Thanks & Regards > > s > > > > Ph.: 091-124-6383474 (e 250) > > __________________________________________ > > I had a good grip on life, but then the handle broke. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 10:51:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27644 for ; Tue, 9 Jul 2002 10:51:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08456 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 10:52:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06693; Tue, 9 Jul 2002 10:23:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06664 for ; Tue, 9 Jul 2002 10:23:24 -0400 (EDT) Received: from fthsmtp01.cbsinc.com (fw1.covansys.com [12.162.224.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26587 for ; Tue, 9 Jul 2002 10:22:32 -0400 (EDT) Received: by fthsmtp01 with Internet Mail Service (5.5.2653.19) id <3C6QN2DL>; Tue, 9 Jul 2002 10:22:18 -0400 Message-ID: From: KANUMURI Sreeram To: "'chris@infravast.com'" , Ranjit Avasarala Cc: ShavinderPal Singh , sip@ietf.org Subject: RE: [Sip] Authentication for re-INVITE. Date: Tue, 9 Jul 2002 10:19:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > I don't think proxy needs to authenticate re-invite, as re-invite is used > for changing session parameters of an existing call >>For this very reason you should reauthenticate...so that someone doesnt >>spoof a forged INVITE with bad parameters within it back to the client. TRUE but can you tell me how can "someone spoof a forged INVITE" ?? like the call is established between the end users and it is olny session parameters change. As there is Already the authentication done. olny the UA in the call can change teh parameters with a new invite.....?? so can u make me clearer?? Sreeram > > Ranjit > ----- Original Message ----- > From: ShavinderPal Singh > To: ; Jonathan Rosemberg > Sent: Monday, July 08, 2002 5:21 PM > Subject: [Sip] Authentication for re-INVITE. > > > > > Is a SIP proxy supposed to Authenticate a re-INVITE also? If no, then if > > some proxy in Authenticating and it asks for Auth Info from the UA, what > > is the UA supposed to do? Is it mandatory that it should send the Auth > > Info? > > > > Please suggest! > > > > Thanks & Regards > > s > > > > Ph.: 091-124-6383474 (e 250) > > __________________________________________ > > I had a good grip on life, but then the handle broke. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 12:55:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03085 for ; Tue, 9 Jul 2002 12:55:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21103 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 12:56:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18743; Tue, 9 Jul 2002 12:32:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18682 for ; Tue, 9 Jul 2002 12:32:37 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02089; Tue, 9 Jul 2002 12:31:43 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g69GWXrU010662; Tue, 9 Jul 2002 18:32:33 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g69GWXa9020451; Tue, 9 Jul 2002 19:32:33 +0300 (EET DST) Message-ID: <3D2B1021.5E9E41E@lmf.ericsson.se> Date: Tue, 09 Jul 2002 19:32:33 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: Gonzalo Camarillo , rohan@cisco.com, sip@ietf.org, sipping@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Sean, > Is this really out of scope for this draft? Naturally > the more re-use you make of the connection, the more > benefit you get from re-use ;-) Of course, but in that case it should be mentioned in the draft :) The only thing the draft currently talks about the problem how to make sure a single connection is used for both directions, per session - which is a separate issue from reusing connections for multiple sessions. And, since I don't think any draft currently talks about the reuse of connections for multiple sessions (bis talks about keeping the connection open to make sure the transaction uses the same transaction), maybe it could be added to the connect-reuse draft? Just some thoughts... Regards, Christer Holmberg Ericsson Finland > > > /sean > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, July 09, 2002 6:30 AM > To: Gonzalo Camarillo > Cc: Sean Olson; rohan@cisco.com; sip@ietf.org; sipping@ietf.org > Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 > > Hi, > > RFC3261/bis-9 mainly talks about using a single connection (or, one in > each > direction) for a single transaction, and the connect-reuse draft talks > about being able to use a single connection for messages in both > direction, for a single session. Sometimes, however, when we talk about > "reuse of connection" we mean when a single connection (or, one in each > direction) is used for multiple sessions. I think it would be a good > idea to mention that that kind of "reuse" is out of the scope of the > draft. Otherwise the draft subject should more clear indicate what kind > of reuse it refers to... > > Of course, once a single connection is established, according to the > connect-reuse draft, it MAY be used for multiple sessions, but that's > not the scope of the draft, so... > > Regards, > > Christer Holmberg > Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 13:07:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03670 for ; Tue, 9 Jul 2002 13:07:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22334 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 13:08:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19486; Tue, 9 Jul 2002 12:40:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19423 for ; Tue, 9 Jul 2002 12:40:39 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02316; Tue, 9 Jul 2002 12:39:45 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g69GeZRb018940; Tue, 9 Jul 2002 18:40:35 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g69GeZa9020857; Tue, 9 Jul 2002 19:40:35 +0300 (EET DST) Message-ID: <3D2B1203.1F893978@lmf.ericsson.se> Date: Tue, 09 Jul 2002 19:40:35 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson , Gonzalo Camarillo , rohan@cisco.com, sip@ietf.org, sipping@ietf.org References: <3D2B1021.5E9E41E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Another comment, I also think it is important to remember that there MAY be scenarios, especially if a connection is used for multiple sessions, where one wants to use separate connections per each direction - even if the client indicates he wants to use the same connection for the response. Just to think of before the MUSTs are added... Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > Hi Sean, > > > Is this really out of scope for this draft? Naturally > > the more re-use you make of the connection, the more > > benefit you get from re-use ;-) > > Of course, but in that case it should be mentioned in the draft :) > > The only thing the draft currently talks about the problem how to make sure > a single connection is used for both directions, per session - which is a > separate issue from reusing connections for multiple sessions. > > And, since I don't think any draft currently talks about the reuse of > connections for multiple sessions (bis talks about keeping the connection > open to make sure the transaction uses the same transaction), maybe it > could be added to the connect-reuse draft? > > Just some thoughts... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > /sean > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, July 09, 2002 6:30 AM > > To: Gonzalo Camarillo > > Cc: Sean Olson; rohan@cisco.com; sip@ietf.org; sipping@ietf.org > > Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 > > > > Hi, > > > > RFC3261/bis-9 mainly talks about using a single connection (or, one in > > each > > direction) for a single transaction, and the connect-reuse draft talks > > about being able to use a single connection for messages in both > > direction, for a single session. Sometimes, however, when we talk about > > "reuse of connection" we mean when a single connection (or, one in each > > direction) is used for multiple sessions. I think it would be a good > > idea to mention that that kind of "reuse" is out of the scope of the > > draft. Otherwise the draft subject should more clear indicate what kind > > of reuse it refers to... > > > > Of course, once a single connection is established, according to the > > connect-reuse draft, it MAY be used for multiple sessions, but that's > > not the scope of the draft, so... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 13:40:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04767 for ; Tue, 9 Jul 2002 13:40:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24627 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 13:41:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23128; Tue, 9 Jul 2002 13:20:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23102 for ; Tue, 9 Jul 2002 13:20:44 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04266 for ; Tue, 9 Jul 2002 13:19:52 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g69HJx331522; Tue, 9 Jul 2002 12:19:59 -0500 From: "Dean Willis" To: Cc: , , Date: Tue, 9 Jul 2002 12:19:52 -0500 Message-ID: <041501c2276c$d81dfb70$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Announcing WGLC for draft-ietf-sip-session-timer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to request working group last call on the session timer draft. This should be pretty straightforward -- the -08 version was WGLCed, sent up for IETF last call, then held up waiting on RFC3261. The current -09 version has been updated for RFC3261 compliance. See: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-09.txt Or http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-session-timer-09.tx t I think we should be able to close this up by July 22. Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 13:54:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05109 for ; Tue, 9 Jul 2002 13:54:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25037 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 13:55:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23263; Tue, 9 Jul 2002 13:21:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23175 for ; Tue, 9 Jul 2002 13:20:54 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04279 for ; Tue, 9 Jul 2002 13:20:02 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g69HJv331516; Tue, 9 Jul 2002 12:19:57 -0500 From: "Dean Willis" To: Cc: , , , Date: Tue, 9 Jul 2002 12:19:52 -0500 Message-ID: <041301c2276c$d735be50$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Announce WGLC on draft-ietf-sip-guidelines Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to request that the SIP working group review the SIP Guidelines draft. See: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-05.txt Or http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-guidelines-05.txt We should be able to close this the week of July 22. Thanks -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 13:59:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05279 for ; Tue, 9 Jul 2002 13:59:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25356 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 14:00:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23191; Tue, 9 Jul 2002 13:20:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23134 for ; Tue, 9 Jul 2002 13:20:48 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04267 for ; Tue, 9 Jul 2002 13:19:52 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g69HJv331513; Tue, 9 Jul 2002 12:19:57 -0500 From: "Dean Willis" To: Cc: , , , , Date: Tue, 9 Jul 2002 12:19:52 -0500 Message-ID: <041201c2276c$d6e1aae0$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Anounce WGLC for draft-ietf-sip-sctp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Please review the SIP over SCTP draft. See: http://www.ietf.org/internet-drafts/draft-ietf-sip-sctp-03.txt Or http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-sctp-03.txt As usual, please copy comments to the authors and/or the list as appropriate. I'd like to wrap this up by the week of July 22. Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 14:04:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05445 for ; Tue, 9 Jul 2002 14:04:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25957 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 14:05:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23233; Tue, 9 Jul 2002 13:21:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23142 for ; Tue, 9 Jul 2002 13:20:50 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04273 for ; Tue, 9 Jul 2002 13:19:57 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g69HJw331519; Tue, 9 Jul 2002 12:19:58 -0500 From: "Dean Willis" To: Cc: , , , Date: Tue, 9 Jul 2002 12:19:52 -0500 Message-ID: <041401c2276c$d7e25200$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Anounce WGLC for draft-ietf-sip-callerpref Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to request the working group do a last call on the caller preferences draft. See: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-06.txt Or http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-callerprefs-06.txt If possible, I'd like to close this by July 22. Please copy the author and/or list with your comments as appropriate. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 14:08:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05690 for ; Tue, 9 Jul 2002 14:08:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26099 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 14:09:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24231; Tue, 9 Jul 2002 13:32:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19780 for ; Tue, 9 Jul 2002 12:43:01 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02503; Tue, 9 Jul 2002 12:42:07 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 09:42:30 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jul 2002 09:42:30 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 9 Jul 2002 09:42:29 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 9 Jul 2002 09:42:29 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 9 Jul 2002 09:42:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Jul 2002 09:42:28 -0700 Message-ID: Thread-Topic: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Thread-Index: AcInZ1s9fSlWSnXqT5uiIoWc9liNEwAABcSw From: "Sean Olson" To: "Christer Holmberg" , "Gonzalo Camarillo" , , , X-OriginalArrivalTime: 09 Jul 2002 16:42:29.0161 (UTC) FILETIME=[9D28D990:01C22767] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA19781 Subject: [Sip] RE: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Good point. Is this is a request or a demand by the client to re-use the connection? I think we need the possibility for the client to *demand* that the connection be re-used. There may also be situations where re-use is just an optimization. /sean -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Tuesday, July 09, 2002 9:41 AM To: Sean Olson; Gonzalo Camarillo; rohan@cisco.com; sip@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Another comment, I also think it is important to remember that there MAY be scenarios, especially if a connection is used for multiple sessions, where one wants to use separate connections per each direction - even if the client indicates he wants to use the same connection for the response. Just to think of before the MUSTs are added... Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > Hi Sean, > > > Is this really out of scope for this draft? Naturally > > the more re-use you make of the connection, the more benefit you get > > from re-use ;-) > > Of course, but in that case it should be mentioned in the draft :) > > The only thing the draft currently talks about the problem how to make > sure a single connection is used for both directions, per session - > which is a separate issue from reusing connections for multiple > sessions. > > And, since I don't think any draft currently talks about the reuse of > connections for multiple sessions (bis talks about keeping the > connection open to make sure the transaction uses the same > transaction), maybe it could be added to the connect-reuse draft? > > Just some thoughts... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > /sean > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, July 09, 2002 6:30 AM > > To: Gonzalo Camarillo > > Cc: Sean Olson; rohan@cisco.com; sip@ietf.org; sipping@ietf.org > > Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 > > > > Hi, > > > > RFC3261/bis-9 mainly talks about using a single connection (or, one > > in each > > direction) for a single transaction, and the connect-reuse draft > > talks about being able to use a single connection for messages in > > both direction, for a single session. Sometimes, however, when we > > talk about "reuse of connection" we mean when a single connection > > (or, one in each > > direction) is used for multiple sessions. I think it would be a good > > idea to mention that that kind of "reuse" is out of the scope of the > > draft. Otherwise the draft subject should more clear indicate what kind > > of reuse it refers to... > > > > Of course, once a single connection is established, according to the > > connect-reuse draft, it MAY be used for multiple sessions, but > > that's not the scope of the draft, so... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 14:11:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05801 for ; Tue, 9 Jul 2002 14:11:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26168 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 14:12:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24211; Tue, 9 Jul 2002 13:32:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17494 for ; Tue, 9 Jul 2002 12:24:32 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01785; Tue, 9 Jul 2002 12:23:38 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 09:23:56 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jul 2002 09:23:56 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 9 Jul 2002 09:23:56 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 09:23:55 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 9 Jul 2002 09:23:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Jul 2002 09:23:55 -0700 Message-ID: Thread-Topic: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Thread-Index: AcInTLqILMMi+mTFROmfdzDToCrYMwAGCnvw From: "Sean Olson" To: "Christer Holmberg" , "Gonzalo Camarillo" Cc: , , X-OriginalArrivalTime: 09 Jul 2002 16:23:55.0477 (UTC) FILETIME=[055A2850:01C22765] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA17497 Subject: [Sip] RE: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Is this really out of scope for this draft? Naturally the more re-use you make of the connection, the more benefit you get from re-use ;-) /sean -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Tuesday, July 09, 2002 6:30 AM To: Gonzalo Camarillo Cc: Sean Olson; rohan@cisco.com; sip@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Hi, RFC3261/bis-9 mainly talks about using a single connection (or, one in each direction) for a single transaction, and the connect-reuse draft talks about being able to use a single connection for messages in both direction, for a single session. Sometimes, however, when we talk about "reuse of connection" we mean when a single connection (or, one in each direction) is used for multiple sessions. I think it would be a good idea to mention that that kind of "reuse" is out of the scope of the draft. Otherwise the draft subject should more clear indicate what kind of reuse it refers to... Of course, once a single connection is established, according to the connect-reuse draft, it MAY be used for multiple sessions, but that's not the scope of the draft, so... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 14:53:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07334 for ; Tue, 9 Jul 2002 14:53:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29029 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 14:54:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26390; Tue, 9 Jul 2002 14:22:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26358 for ; Tue, 9 Jul 2002 14:22:06 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06115 for ; Tue, 9 Jul 2002 14:21:13 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g69ILl406483; Tue, 9 Jul 2002 13:21:48 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 13:21:33 -0500 Message-ID: From: "Sriram Parameswar" To: "'Sean Olson'" , sip@ietf.org Date: Tue, 9 Jul 2002 13:21:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22775.73498490" Subject: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C22775.73498490 Content-Type: text/plain; charset="iso-8859-1" Thanks Sean - I would definitely like to hear from the MIME experts - but here is an example from RFC 2017 section 3 which is more along what I suggested. I think we need to take a closer look because the current draft does borrow heavily from RFC2017: Content-type: message/external-body; access-type=URL; URL="http://www.foo.com/file" Content-type: text/html Content-Transfer-Encoding: binary THIS IS NOT REALLY THE BODY! Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Sean Olson [mailto:seanol@windows.microsoft.com] Sent: Tuesday, July 09, 2002 12:38 PM To: Parameswar, Sriram [NGC:B615:EXCH]; sip@ietf.org Subject: RE: draft-olson-sip-content-indirect-mech-00 Thanks for the comments! I will try to dissect my original example to explain what I was shooting for. I've added line numbers, plus some surrounding context to hopefully make things a little clearer. 1 INVITE sip:bob@acme.com SIP/2.0 2 Via: SIP/2.0/TCP 10.0.0.2;branch=z9hG4bK83749 3 From: ;tag=abcd 4 To: 5 Call-ID: 1@10.0.0.2 6 CSeq: 2343 INVITE 7 Content-Type: message/external-body; access-type="URL"; 8 expiration="Mon, 24 June 2002 09:00:00 GMT"; 9 URL="http://www.bogus.com/the-indirect-content" 10 Content-Length: ... 11 12 Content-Type: application/sdp 13 Line 12 is the start of the payload for this INVITE. Lines 7-9 define the content type of this payload (indirect content available at the given URL) Line 12 gives the content type of the indirect content. It is actually an entity header inside the payload (an encapsulated entity) Line 13 marks the end of the entity headers for this encapsulated entity and also marks the end of the message This is consistent with the example given in section 5.2.3 of RFC2046. I'm using MIME in the broadest sense defined in RFC2045/2046 to allow nesting or encapsulation of entities. This looks a bit strange compared to other SIP messages, but I believe it is perfectly valid MIME. I don't think we need to use message/sipfrag or even text/plain to accomplish this -- the capability to express nested entities and entity headers is part of MIME. I would be curious to hear from other MIME experts on this issue to see if I'm abusing something here. /sean -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Sunday, July 07, 2002 6:35 PM To: Sean Olson; 'sip@ietf.org' Subject: draft-olson-sip-content-indirect-mech-00 Sean, Well written draft! In Section 3.6 'Specifying the type of the indirect content' - it must be clearly noted that when including the content-type of the indirect content in the payload - there must be Content headers specifying that payload. Along with some textual description added to section 3.6, the example in that section will change to look something like: Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.bogus.com/the-indirect-content" Content-Type: text/plain Content-Length: ... Content-Type: application/sdp You may also want to add a small section on how this mechanism satisfies the requirements laid down in the requirements document (draft-ietf-sipping-content-indirect-00). Just as an after thought, the additional Content-Type may also be message/sipfrag instead of text/plain. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C22775.73498490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-olson-sip-content-indirect-mech-00

Thanks Sean - I would definitely like to hear from = the MIME experts - but here is an example from RFC 2017 section 3 which = is more along what I suggested. I think we need to take a closer look = because the current draft does borrow heavily from RFC2017:

<quote RFC2017>
    Content-type: = message/external-body; access-type=3DURL;
          &nb= sp;       URL=3D"http://www.foo.com/file"

    Content-type: text/html
    Content-Transfer-Encoding: = binary

    THIS IS NOT REALLY THE = BODY!

</quote RFC2017>

Regards,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Sean Olson [mailto:seanol@windows.micro= soft.com]
Sent: Tuesday, July 09, 2002 12:38 PM
To: Parameswar, Sriram [NGC:B615:EXCH]; = sip@ietf.org
Subject: RE: = draft-olson-sip-content-indirect-mech-00


Thanks for the comments!

I will try to dissect my original example to explain = what I was
shooting for. I've added line numbers, plus some = surrounding context
to hopefully make things a little clearer.

1   INVITE sip:bob@acme.com SIP/2.0
2   Via: SIP/2.0/TCP = 10.0.0.2;branch=3Dz9hG4bK83749
3   From: = <sip:alice@acme.com>;tag=3Dabcd
4   To: <sip:bob@acme.com>
5   Call-ID: 1@10.0.0.2
6   CSeq: 2343 INVITE
7   Content-Type: message/external-body; = access-type=3D"URL";
8          &n= bsp;      expiration=3D"Mon, 24 June 2002 = 09:00:00 GMT";
9          &n= bsp;      URL=3D"http://www.bogus.com/the-indirect-content"
10  Content-Length: ...
11  <CRLF>
12  Content-Type: application/sdp
13  <CRLF>


Line 12 is the start of the payload for this = INVITE.
Lines 7-9 define the content type of this payload = (indirect content
          = available at the given URL)

Line 12 gives the content type of the indirect = content. It is actually
        an entity = header inside the payload (an encapsulated entity)

Line 13 marks the end of the entity headers for this = encapsulated entity
        and also = marks the end of the message

This is consistent with the example given in section = 5.2.3 of RFC2046.
I'm using MIME in the broadest sense defined in = RFC2045/2046 to allow
nesting or encapsulation of entities. This looks a = bit strange compared
to other SIP messages, but I believe it is perfectly = valid MIME. I
don't think we need to use message/sipfrag or even = text/plain to
accomplish
this -- the capability to express nested entities = and entity headers is
part of MIME.
I would be curious to hear from other MIME experts = on this issue to see
if I'm
abusing something here.

/sean

-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks= .com]
Sent: Sunday, July 07, 2002 6:35 PM
To: Sean Olson; 'sip@ietf.org'
Subject: = draft-olson-sip-content-indirect-mech-00


Sean,
Well written draft!  In Section 3.6 'Specifying = the type of the indirect
content' -
it must be clearly noted that when including the = content-type of the
indirect content in the payload
- there must be Content headers specifying that = payload. Along with some
textual description added to section 3.6,
the example in that section will change to look = something like:

Content-Type: message/external-body; = access-type=3D"URL"; expiration=3D"Mon,
24 June 2002 09:00:00 GMT";
URL=3D"http://www.bogus.com/the-indirect-content" =
Content-Type: text/plain
Content-Length: ...
<CRLF>
Content-Type: application/sdp
<CRLF>

You may also want to add a small section on how this = mechanism satisfies
the requirements laid down in the requirements = document
(draft-ietf-sipping-content-indirect-00). Just as an = after thought, the
additional Content-Type may also be message/sipfrag = instead of
text/plain.

Regards,
Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C22775.73498490-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 14:57:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08693 for ; Tue, 9 Jul 2002 14:57:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29703 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 14:58:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26854; Tue, 9 Jul 2002 14:28:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24521 for ; Tue, 9 Jul 2002 13:38:20 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04723 for ; Tue, 9 Jul 2002 13:37:27 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 10:37:49 -0700 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jul 2002 10:37:48 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 9 Jul 2002 10:37:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 10:37:48 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 9 Jul 2002 10:37:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Jul 2002 10:37:47 -0700 Message-ID: Thread-Topic: draft-olson-sip-content-indirect-mech-00 Thread-Index: AcImH5516/kn1gVpR2+GlDfcdKX9GwBTBRfA From: "Sean Olson" To: "Sriram Parameswar" , X-OriginalArrivalTime: 09 Jul 2002 17:37:48.0286 (UTC) FILETIME=[578321E0:01C2276F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA24522 Subject: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Thanks for the comments! I will try to dissect my original example to explain what I was shooting for. I've added line numbers, plus some surrounding context to hopefully make things a little clearer. 1 INVITE sip:bob@acme.com SIP/2.0 2 Via: SIP/2.0/TCP 10.0.0.2;branch=z9hG4bK83749 3 From: ;tag=abcd 4 To: 5 Call-ID: 1@10.0.0.2 6 CSeq: 2343 INVITE 7 Content-Type: message/external-body; access-type="URL"; 8 expiration="Mon, 24 June 2002 09:00:00 GMT"; 9 URL="http://www.bogus.com/the-indirect-content" 10 Content-Length: ... 11 12 Content-Type: application/sdp 13 Line 12 is the start of the payload for this INVITE. Lines 7-9 define the content type of this payload (indirect content available at the given URL) Line 12 gives the content type of the indirect content. It is actually an entity header inside the payload (an encapsulated entity) Line 13 marks the end of the entity headers for this encapsulated entity and also marks the end of the message This is consistent with the example given in section 5.2.3 of RFC2046. I'm using MIME in the broadest sense defined in RFC2045/2046 to allow nesting or encapsulation of entities. This looks a bit strange compared to other SIP messages, but I believe it is perfectly valid MIME. I don't think we need to use message/sipfrag or even text/plain to accomplish this -- the capability to express nested entities and entity headers is part of MIME. I would be curious to hear from other MIME experts on this issue to see if I'm abusing something here. /sean -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Sunday, July 07, 2002 6:35 PM To: Sean Olson; 'sip@ietf.org' Subject: draft-olson-sip-content-indirect-mech-00 Sean, Well written draft! In Section 3.6 'Specifying the type of the indirect content' - it must be clearly noted that when including the content-type of the indirect content in the payload - there must be Content headers specifying that payload. Along with some textual description added to section 3.6, the example in that section will change to look something like: Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL="http://www.bogus.com/the-indirect-content" Content-Type: text/plain Content-Length: ... Content-Type: application/sdp You may also want to add a small section on how this mechanism satisfies the requirements laid down in the requirements document (draft-ietf-sipping-content-indirect-00). Just as an after thought, the additional Content-Type may also be message/sipfrag instead of text/plain. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 15:12:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10297 for ; Tue, 9 Jul 2002 15:12:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00858 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 15:13:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27073; Tue, 9 Jul 2002 14:30:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27026 for ; Tue, 9 Jul 2002 14:30:16 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06436 for ; Tue, 9 Jul 2002 14:29:23 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 11:29:44 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jul 2002 11:29:44 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 9 Jul 2002 11:29:33 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 11:29:43 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 9 Jul 2002 11:29:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Tue, 9 Jul 2002 11:29:43 -0700 Message-ID: Thread-Topic: draft-olson-sip-content-indirect-mech-00 Thread-Index: AcIndXqpKzPrTZRRQrO0uU9ZqoXNIwAANvKQ From: "Sean Olson" To: "Sriram Parameswar" , X-OriginalArrivalTime: 09 Jul 2002 18:29:43.0454 (UTC) FILETIME=[984C0BE0:01C22776] Subject: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22776.9824F081" ------_=_NextPart_001_01C22776.9824F081 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you are suggesting that we might want to indirectly refer to=20 message/sipfrag or text/plain content, I completely agree. The example you cite below is almost exactly what I have proposed. I just happen to use application/sdp instead of text/html as the (indirect) Content-Type: =20 thanks /sean -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]=20 Sent: Tuesday, July 09, 2002 11:22 AM To: Sean Olson; sip@ietf.org Subject: RE: draft-olson-sip-content-indirect-mech-00 =09 =09 Thanks Sean - I would definitely like to hear from the MIME experts - but here is an example from RFC 2017 section 3 which is more along what I suggested. I think we need to take a closer look because the current draft does borrow heavily from RFC2017: =20 Content-type: message/external-body; access-type=3DURL;=20 URL=3D"http://www.foo.com/file"=20 Content-type: text/html=20 Content-Transfer-Encoding: binary=20 THIS IS NOT REALLY THE BODY!=20 =20 Regards,=20 Sriram=20 __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Interactive Multimedia Server (IMS) Fax: 972-684-3986=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 -----Original Message-----=20 From: Sean Olson [mailto:seanol@windows.microsoft.com]=20 Sent: Tuesday, July 09, 2002 12:38 PM=20 To: Parameswar, Sriram [NGC:B615:EXCH]; sip@ietf.org=20 Subject: RE: draft-olson-sip-content-indirect-mech-00=20 Thanks for the comments!=20 I will try to dissect my original example to explain what I was=20 shooting for. I've added line numbers, plus some surrounding context=20 to hopefully make things a little clearer.=20 1 INVITE sip:bob@acme.com SIP/2.0=20 2 Via: SIP/2.0/TCP 10.0.0.2;branch=3Dz9hG4bK83749=20 3 From: ;tag=3Dabcd=20 4 To: =20 5 Call-ID: 1@10.0.0.2=20 6 CSeq: 2343 INVITE=20 7 Content-Type: message/external-body; access-type=3D"URL";=20 8 expiration=3D"Mon, 24 June 2002 09:00:00 GMT";=20 9 URL=3D"http://www.bogus.com/the-indirect-content"=20 10 Content-Length: ...=20 11 =20 12 Content-Type: application/sdp=20 13 =20 Line 12 is the start of the payload for this INVITE.=20 Lines 7-9 define the content type of this payload (indirect content=20 available at the given URL)=20 Line 12 gives the content type of the indirect content. It is actually=20 an entity header inside the payload (an encapsulated entity)=20 Line 13 marks the end of the entity headers for this encapsulated entity=20 and also marks the end of the message=20 This is consistent with the example given in section 5.2.3 of RFC2046.=20 I'm using MIME in the broadest sense defined in RFC2045/2046 to allow=20 nesting or encapsulation of entities. This looks a bit strange compared=20 to other SIP messages, but I believe it is perfectly valid MIME. I=20 don't think we need to use message/sipfrag or even text/plain to accomplish=20 this -- the capability to express nested entities and entity headers is=20 part of MIME.=20 I would be curious to hear from other MIME experts on this issue to see=20 if I'm=20 abusing something here.=20 /sean=20 -----Original Message-----=20 From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]=20 Sent: Sunday, July 07, 2002 6:35 PM=20 To: Sean Olson; 'sip@ietf.org'=20 Subject: draft-olson-sip-content-indirect-mech-00=20 Sean,=20 Well written draft! In Section 3.6 'Specifying the type of the indirect=20 content' -=20 it must be clearly noted that when including the content-type of the=20 indirect content in the payload=20 - there must be Content headers specifying that payload. Along with some=20 textual description added to section 3.6,=20 the example in that section will change to look something like:=20 Content-Type: message/external-body; access-type=3D"URL"; expiration=3D"Mon,=20 24 June 2002 09:00:00 GMT";=20 URL=3D"http://www.bogus.com/the-indirect-content"=20 Content-Type: text/plain=20 Content-Length: ...=20 =20 Content-Type: application/sdp=20 =20 You may also want to add a small section on how this mechanism satisfies=20 the requirements laid down in the requirements document=20 (draft-ietf-sipping-content-indirect-00). Just as an after thought, the=20 additional Content-Type may also be message/sipfrag instead of=20 text/plain.=20 Regards,=20 Sriram=20 __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Interactive Multimedia Server (IMS) Fax: 972-684-3986=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 ------_=_NextPart_001_01C22776.9824F081 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
If you=20 are suggesting that we might want to indirectly refer to =
message/sipfrag or text/plain content, I completely agree.=20 The
example you cite below is almost exactly what I have=20 proposed.
I just=20 happen to use application/sdp instead of text/html = as
the=20 (indirect) Content-Type:
 
thanks
/sean
-----Original Message-----
From: = Sriram=20 Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: = Tuesday, July=20 09, 2002 11:22 AM
To: Sean Olson; = sip@ietf.org
Subject:=20 RE: draft-olson-sip-content-indirect-mech-00

Thanks Sean - I would definitely like to hear from = the MIME=20 experts - but here is an example from RFC 2017 section 3 which is more = along=20 what I suggested. I think we need to take a closer look because the = current=20 draft does borrow heavily from RFC2017:

<quote RFC2017>
    Content-type: message/external-body;=20 access-type=3DURL;
          &nbs= p;      =20 URL=3D"http://www.foo.com/file"

    Content-type: text/html =
    Content-Transfer-Encoding: binary =

    THIS IS NOT REALLY THE = BODY!

</quote RFC2017>

Regards,

Sriram

__________________________________________ =
Sriram=20 = Parameswar          &nb= sp;  =20 Phone: 972-685-8540
Interactive Multimedia = Server=20 (IMS) Fax: 972-684-3986
Nortel Networks, = Richardson=20 USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Sean=20 Olson [mailto:seanol@windows.micros= oft.com]=20
Sent: Tuesday, July 09, 2002 12:38 PM =
To: Parameswar, Sriram [NGC:B615:EXCH]; sip@ietf.org =
Subject: RE: draft-olson-sip-content-indirect-mech-00 =


Thanks for the comments!

I will try to dissect my original example to explain = what I=20 was
shooting for. I've added line numbers, = plus some=20 surrounding context
to hopefully make things = a little=20 clearer.

1   INVITE sip:bob@acme.com SIP/2.0 =
2   Via: SIP/2.0/TCP = 10.0.0.2;branch=3Dz9hG4bK83749=20
3   From:=20 <sip:alice@acme.com>;tag=3Dabcd
4   To:=20 <sip:bob@acme.com>
5   = Call-ID:=20 1@10.0.0.2
6   CSeq: 2343 = INVITE=20
7   Content-Type: message/external-body;=20 access-type=3D"URL";
8          &nb= sp;     =20 expiration=3D"Mon, 24 June 2002 09:00:00 GMT";
9          &nb= sp;     =20 URL=3D"http://www.bogus.com/the-indirect-content" =
10  Content-Length: ...
11 =20 <CRLF>
12  Content-Type:=20 application/sdp
13  <CRLF> =


Line 12 is the start of the payload for this = INVITE.=20
Lines 7-9 define the content type of this payload = (indirect=20 content
          = available at the=20 given URL)

Line 12 gives the content type of the indirect = content. It is=20 actually
        an=20 entity header inside the payload (an encapsulated entity)

Line 13 marks the end of the entity headers for this = encapsulated entity
        and also marks the = end of=20 the message

This is consistent with the example given in section = 5.2.3 of=20 RFC2046.
I'm using MIME in the broadest = sense defined=20 in RFC2045/2046 to allow
nesting or = encapsulation of=20 entities. This looks a bit strange compared
to other=20 SIP messages, but I believe it is perfectly valid MIME. I =
don't think we need to use message/sipfrag or even text/plain = to=20
accomplish
this -- the = capability to=20 express nested entities and entity headers is
part of=20 MIME.
I would be curious to hear from other = MIME=20 experts on this issue to see
if I'm =
abusing something here.

/sean

-----Original Message-----
From:=20 Sriram Parameswar [mailto:sriramp@nortelnetworks.= com]=20
Sent: Sunday, July 07, 2002 6:35 PM =
To: Sean Olson; 'sip@ietf.org'
Subject:=20 draft-olson-sip-content-indirect-mech-00


Sean,
Well written = draft!  In=20 Section 3.6 'Specifying the type of the indirect
content' -
it must be clearly noted = that when=20 including the content-type of the
indirect = content in=20 the payload
- there must be Content headers = specifying=20 that payload. Along with some
textual = description=20 added to section 3.6,
the example in that = section will=20 change to look something like:

Content-Type: message/external-body; = access-type=3D"URL";=20 expiration=3D"Mon,
24 June 2002 09:00:00 = GMT";=20
URL=3D"http://www.bogus.com/the-indirect-content" =
Content-Type: text/plain
Content-Length: ...=20
<CRLF>
Content-Type:=20 application/sdp
<CRLF>

You may also want to add a small section on how this = mechanism=20 satisfies
the requirements laid down in the=20 requirements document
(draft-ietf-sipping-content-indirect-00). Just as an after = thought,=20 the
additional Content-Type may also be=20 message/sipfrag instead of
text/plain.

Regards,
Sriram =
__________________________________________
Sriram=20 = Parameswar          &nb= sp;  =20 Phone: 972-685-8540
Interactive Multimedia = Server=20 (IMS) Fax: 972-684-3986
Nortel Networks, = Richardson=20 USA  Email: sriramp@nortelnetworks.com=20

=00 ------_=_NextPart_001_01C22776.9824F081-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 15:17:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11137 for ; Tue, 9 Jul 2002 15:17:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01089 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 15:18:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28720; Tue, 9 Jul 2002 14:48:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28690 for ; Tue, 9 Jul 2002 14:48:06 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07184 for ; Tue, 9 Jul 2002 14:47:12 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 11:47:33 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jul 2002 11:47:32 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 9 Jul 2002 11:47:21 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 9 Jul 2002 11:47:32 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 9 Jul 2002 11:47:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Tue, 9 Jul 2002 11:47:31 -0700 Message-ID: Thread-Topic: draft-olson-sip-content-indirect-mech-00 Thread-Index: AcIneDsUPxJ1jc13T42EPbxNMFnnzQAAKn2w From: "Sean Olson" To: "Sriram Parameswar" Cc: X-OriginalArrivalTime: 09 Jul 2002 18:47:32.0084 (UTC) FILETIME=[15400B40:01C22779] Subject: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22779.152CD1A6" ------_=_NextPart_001_01C22779.152CD1A6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think we are saying the same thing... my intent is to send two Content-Type: headers. One says you are using message/external-body (content indirection). The other states the content type of the indirect content (application/sdp, text/html, whatever) =20 /sean -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]=20 Sent: Tuesday, July 09, 2002 11:41 AM To: Sean Olson Cc: sip@ietf.org Subject: RE: draft-olson-sip-content-indirect-mech-00 =09 =09 Sean, =20 One more reason for pushing for the additional Content-Type is Section 7.4.1 of RFC3261 says - "The Internet media type of the message body MUST be given by the Content-Type header field." Otherwise how will the UAS receiving the INVITE know how to parse the body? But maybe I should wait till the MIME experts give us their verdict :) =20 Thanks, =20 Sriram __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Interactive Multimedia Server (IMS) Fax: 972-684-3986=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 -----Original Message----- From: Sean Olson [mailto:seanol@windows.microsoft.com] Sent: Tuesday, July 09, 2002 1:30 PM To: Parameswar, Sriram [NGC:B615:EXCH]; sip@ietf.org Subject: RE: draft-olson-sip-content-indirect-mech-00 =09 =09 If you are suggesting that we might want to indirectly refer to=20 message/sipfrag or text/plain content, I completely agree. The example you cite below is almost exactly what I have proposed. I just happen to use application/sdp instead of text/html as the (indirect) Content-Type: =20 thanks /sean -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]=20 Sent: Tuesday, July 09, 2002 11:22 AM To: Sean Olson; sip@ietf.org Subject: RE: draft-olson-sip-content-indirect-mech-00 =09 =09 Thanks Sean - I would definitely like to hear from the MIME experts - but here is an example from RFC 2017 section 3 which is more along what I suggested. I think we need to take a closer look because the current draft does borrow heavily from RFC2017: =20 Content-type: message/external-body; access-type=3DURL;=20 URL=3D"http://www.foo.com/file"=20 Content-type: text/html=20 Content-Transfer-Encoding: binary=20 THIS IS NOT REALLY THE BODY!=20 =20 Regards,=20 Sriram=20 __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Interactive Multimedia Server (IMS) Fax: 972-684-3986=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 -----Original Message-----=20 From: Sean Olson [mailto:seanol@windows.microsoft.com]=20 Sent: Tuesday, July 09, 2002 12:38 PM=20 To: Parameswar, Sriram [NGC:B615:EXCH]; sip@ietf.org=20 Subject: RE: draft-olson-sip-content-indirect-mech-00=20 Thanks for the comments!=20 I will try to dissect my original example to explain what I was=20 shooting for. I've added line numbers, plus some surrounding context=20 to hopefully make things a little clearer.=20 1 INVITE sip:bob@acme.com SIP/2.0=20 2 Via: SIP/2.0/TCP 10.0.0.2;branch=3Dz9hG4bK83749=20 3 From: ;tag=3Dabcd=20 4 To: =20 5 Call-ID: 1@10.0.0.2=20 6 CSeq: 2343 INVITE=20 7 Content-Type: message/external-body; access-type=3D"URL";=20 8 expiration=3D"Mon, 24 June 2002 09:00:00 GMT";=20 9 URL=3D"http://www.bogus.com/the-indirect-content"=20 10 Content-Length: ...=20 11 =20 12 Content-Type: application/sdp=20 13 =20 Line 12 is the start of the payload for this INVITE.=20 Lines 7-9 define the content type of this payload (indirect content=20 available at the given URL)=20 Line 12 gives the content type of the indirect content. It is actually=20 an entity header inside the payload (an encapsulated entity)=20 Line 13 marks the end of the entity headers for this encapsulated entity=20 and also marks the end of the message=20 This is consistent with the example given in section 5.2.3 of RFC2046.=20 I'm using MIME in the broadest sense defined in RFC2045/2046 to allow=20 nesting or encapsulation of entities. This looks a bit strange compared=20 to other SIP messages, but I believe it is perfectly valid MIME. I=20 don't think we need to use message/sipfrag or even text/plain to=20 accomplish=20 this -- the capability to express nested entities and entity headers is=20 part of MIME.=20 I would be curious to hear from other MIME experts on this issue to see=20 if I'm=20 abusing something here.=20 /sean=20 -----Original Message-----=20 From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]=20 Sent: Sunday, July 07, 2002 6:35 PM=20 To: Sean Olson; 'sip@ietf.org'=20 Subject: draft-olson-sip-content-indirect-mech-00=20 Sean,=20 Well written draft! In Section 3.6 'Specifying the type of the indirect=20 content' -=20 it must be clearly noted that when including the content-type of the=20 indirect content in the payload=20 - there must be Content headers specifying that payload. Along with some=20 textual description added to section 3.6,=20 the example in that section will change to look something like:=20 Content-Type: message/external-body; access-type=3D"URL"; expiration=3D"Mon,=20 24 June 2002 09:00:00 GMT";=20 URL=3D"http://www.bogus.com/the-indirect-content"=20 Content-Type: text/plain=20 Content-Length: ...=20 =20 Content-Type: application/sdp=20 =20 You may also want to add a small section on how this mechanism satisfies=20 the requirements laid down in the requirements document=20 (draft-ietf-sipping-content-indirect-00). Just as an after thought, the=20 additional Content-Type may also be message/sipfrag instead of=20 text/plain.=20 Regards,=20 Sriram=20 __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Interactive Multimedia Server (IMS) Fax: 972-684-3986=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 ------_=_NextPart_001_01C22779.152CD1A6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 think we are saying the same thing... my intent is to send two=20 Content-Type:
headers. One says you are using message/external-body (content=20 indirection).
The=20 other states the content type of the indirect content (application/sdp,=20 text/html,
whatever)
 
/sean
-----Original Message-----
From: = Sriram=20 Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: = Tuesday, July=20 09, 2002 11:41 AM
To: Sean Olson
Cc:=20 sip@ietf.org
Subject: RE:=20 draft-olson-sip-content-indirect-mech-00

Sean,
 
One=20 more reason for pushing for the additional Content-Type is = Section=20 7.4.1 of RFC3261 says - "The Internet media type of the message body = MUST = be given by the Content-Type header = field." Otherwise how will the UAS receiving the = INVITE=20 know how to parse the body? But maybe I should wait till the MIME = experts give=20 us their verdict :)
&nbs= p;
Thanks,
&nbs= p;
Sriram

__________________________________________ =
Sriram=20 = Parameswar          &nb= sp;  =20 Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986 =
Nortel Networks, Richardson USA  = Email: = sriramp@nortelnetworks.com

-----Original Message-----
From: Sean Olson=20 [mailto:seanol@windows.microsoft.com]
Sent: Tuesday, July = 09, 2002=20 1:30 PM
To: Parameswar, Sriram [NGC:B615:EXCH];=20 sip@ietf.org
Subject: RE:=20 draft-olson-sip-content-indirect-mech-00

If=20 you are suggesting that we might want to indirectly refer to=20
message/sipfrag or text/plain content, I completely agree.=20 The
example you cite below is almost exactly what I have=20 proposed.
I=20 just happen to use application/sdp instead of text/html=20 as
the (indirect) Content-Type:
 
thanks
/sean
-----Original Message-----
From: = Sriram=20 Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: = Tuesday,=20 July 09, 2002 11:22 AM
To: Sean Olson;=20 sip@ietf.org
Subject: RE:=20 draft-olson-sip-content-indirect-mech-00

Thanks Sean - I would definitely like to hear = from the=20 MIME experts - but here is an example from RFC 2017 section 3 = which is=20 more along what I suggested. I think we need to take a closer look = because=20 the current draft does borrow heavily from RFC2017:

<quote RFC2017>
    Content-type: message/external-body;=20 access-type=3DURL;
          &nbs= p;      =20 URL=3D"http://www.foo.com/file"

    Content-type: = text/html=20
    Content-Transfer-Encoding:=20 binary

    THIS IS NOT REALLY THE = BODY!=20

</quote RFC2017>

Regards,

Sriram

__________________________________________=20
Sriram=20 = Parameswar          &nb= sp;  =20 Phone: 972-685-8540
Interactive = Multimedia Server=20 (IMS) Fax: 972-684-3986
Nortel Networks, = Richardson USA  Email: sriramp@nortelnetworks.com =


-----Original Message-----
From:=20 Sean Olson [mailto:seanol@windows.micros= oft.com]=20
Sent: Tuesday, July 09, 2002 12:38 PM =
To: Parameswar, Sriram [NGC:B615:EXCH]; = sip@ietf.org=20
Subject: RE:=20 draft-olson-sip-content-indirect-mech-00


Thanks for the comments!

I will try to dissect my original example to = explain what=20 I was
shooting for. I've added line = numbers, plus=20 some surrounding context
to hopefully = make things=20 a little clearer.

1   INVITE sip:bob@acme.com = SIP/2.0=20
2   Via: SIP/2.0/TCP=20 10.0.0.2;branch=3Dz9hG4bK83749
3   From:=20 <sip:alice@acme.com>;tag=3Dabcd
4  =20 To: <sip:bob@acme.com>
5  =20 Call-ID: 1@10.0.0.2
6   CSeq: = 2343=20 INVITE
7   Content-Type:=20 message/external-body; access-type=3D"URL";
8          &nb= sp;     =20 expiration=3D"Mon, 24 June 2002 09:00:00 GMT";
9          &nb= sp;     =20 URL=3D"http://www.bogus.com/the-indirect-content"=20
10  Content-Length: ...
11  <CRLF>
12 =20 Content-Type: application/sdp
13 =20 <CRLF>


Line 12 is the start of the payload for this=20 INVITE.
Lines 7-9 define the content = type of this=20 payload (indirect content
          = available at=20 the given URL)

Line 12 gives the content type of the indirect = content. It=20 is actually
        an entity = header inside=20 the payload (an encapsulated entity)

Line 13 marks the end of the entity headers for = this=20 encapsulated entity
        and also marks = the end=20 of the message

This is consistent with the example given in = section 5.2.3=20 of RFC2046.
I'm using MIME in the = broadest sense=20 defined in RFC2045/2046 to allow
nesting = or=20 encapsulation of entities. This looks a bit strange = compared=20
to other SIP messages, but I believe it is = perfectly=20 valid MIME. I
don't think we need to use = message/sipfrag or even text/plain to
accomplish
this -- the = capability to=20 express nested entities and entity headers is
part=20 of MIME.
I would be curious to hear from = other=20 MIME experts on this issue to see
if = I'm=20
abusing something here.

/sean

-----Original Message-----
From:=20 Sriram Parameswar [mailto:sriramp@nortelnetworks.= com]=20
Sent: Sunday, July 07, 2002 6:35 = PM=20
To: Sean Olson; 'sip@ietf.org'
Subject: draft-olson-sip-content-indirect-mech-00 =


Sean,
Well written = draft!  In=20 Section 3.6 'Specifying the type of the indirect
content' -
it must be clearly = noted that=20 when including the content-type of the
indirect=20 content in the payload
- there must be = Content=20 headers specifying that payload. Along with some
textual description added to section 3.6, =
the example in that section will change to look something = like:

Content-Type: message/external-body; = access-type=3D"URL";=20 expiration=3D"Mon,
24 June 2002 09:00:00 = GMT";
URL=3D"http://www.bogus.com/the-indirect-content"=20
Content-Type: text/plain =
Content-Length: ...
<CRLF>=20
Content-Type: application/sdp =
<CRLF>

You may also want to add a small section on how = this=20 mechanism satisfies
the requirements = laid down in=20 the requirements document
(draft-ietf-sipping-content-indirect-00). Just as an = after thought,=20 the
additional Content-Type may also be=20 message/sipfrag instead of
text/plain.

Regards,
Sriram =
__________________________________________ =
Sriram=20 = Parameswar          &nb= sp;  =20 Phone: 972-685-8540
Interactive = Multimedia Server=20 (IMS) Fax: 972-684-3986
Nortel Networks, = Richardson USA  Email: sriramp@nortelnetworks.com=20

=00 ------_=_NextPart_001_01C22779.152CD1A6-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 15:19:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11812 for ; Tue, 9 Jul 2002 15:19:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01122 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 15:20:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28448; Tue, 9 Jul 2002 14:41:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28351 for ; Tue, 9 Jul 2002 14:41:51 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06961 for ; Tue, 9 Jul 2002 14:40:57 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g69IfV409530; Tue, 9 Jul 2002 13:41:32 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 13:41:17 -0500 Message-ID: From: "Sriram Parameswar" To: "'Sean Olson'" Cc: sip@ietf.org Date: Tue, 9 Jul 2002 13:41:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22778.3597BA10" Subject: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C22778.3597BA10 Content-Type: text/plain; charset="iso-8859-1" Sean, One more reason for pushing for the additional Content-Type is Section 7.4.1 of RFC3261 says - "The Internet media type of the message body MUST be given by the Content-Type header field." Otherwise how will the UAS receiving the INVITE know how to parse the body? But maybe I should wait till the MIME experts give us their verdict :) Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Sean Olson [mailto:seanol@windows.microsoft.com] Sent: Tuesday, July 09, 2002 1:30 PM To: Parameswar, Sriram [NGC:B615:EXCH]; sip@ietf.org Subject: RE: draft-olson-sip-content-indirect-mech-00 If you are suggesting that we might want to indirectly refer to message/sipfrag or text/plain content, I completely agree. The example you cite below is almost exactly what I have proposed. I just happen to use application/sdp instead of text/html as the (indirect) Content-Type: thanks /sean -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Tuesday, July 09, 2002 11:22 AM To: Sean Olson; sip@ietf.org Subject: RE: draft-olson-sip-content-indirect-mech-00 Thanks Sean - I would definitely like to hear from the MIME experts - but here is an example from RFC 2017 section 3 which is more along what I suggested. I think we need to take a closer look because the current draft does borrow heavily from RFC2017: Content-type: message/external-body; access-type=URL; URL=" http://www.foo.com/file " Content-type: text/html Content-Transfer-Encoding: binary THIS IS NOT REALLY THE BODY! Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Sean Olson [ mailto:seanol@windows.microsoft.com ] Sent: Tuesday, July 09, 2002 12:38 PM To: Parameswar, Sriram [NGC:B615:EXCH]; sip@ietf.org Subject: RE: draft-olson-sip-content-indirect-mech-00 Thanks for the comments! I will try to dissect my original example to explain what I was shooting for. I've added line numbers, plus some surrounding context to hopefully make things a little clearer. 1 INVITE sip:bob@acme.com SIP/2.0 2 Via: SIP/2.0/TCP 10.0.0.2;branch=z9hG4bK83749 3 From: ;tag=abcd 4 To: 5 Call-ID: 1@10.0.0.2 6 CSeq: 2343 INVITE 7 Content-Type: message/external-body; access-type="URL"; 8 expiration="Mon, 24 June 2002 09:00:00 GMT"; 9 URL=" http://www.bogus.com/the-indirect-content " 10 Content-Length: ... 11 12 Content-Type: application/sdp 13 Line 12 is the start of the payload for this INVITE. Lines 7-9 define the content type of this payload (indirect content available at the given URL) Line 12 gives the content type of the indirect content. It is actually an entity header inside the payload (an encapsulated entity) Line 13 marks the end of the entity headers for this encapsulated entity and also marks the end of the message This is consistent with the example given in section 5.2.3 of RFC2046. I'm using MIME in the broadest sense defined in RFC2045/2046 to allow nesting or encapsulation of entities. This looks a bit strange compared to other SIP messages, but I believe it is perfectly valid MIME. I don't think we need to use message/sipfrag or even text/plain to accomplish this -- the capability to express nested entities and entity headers is part of MIME. I would be curious to hear from other MIME experts on this issue to see if I'm abusing something here. /sean -----Original Message----- From: Sriram Parameswar [ mailto:sriramp@nortelnetworks.com ] Sent: Sunday, July 07, 2002 6:35 PM To: Sean Olson; 'sip@ietf.org' Subject: draft-olson-sip-content-indirect-mech-00 Sean, Well written draft! In Section 3.6 'Specifying the type of the indirect content' - it must be clearly noted that when including the content-type of the indirect content in the payload - there must be Content headers specifying that payload. Along with some textual description added to section 3.6, the example in that section will change to look something like: Content-Type: message/external-body; access-type="URL"; expiration="Mon, 24 June 2002 09:00:00 GMT"; URL=" http://www.bogus.com/the-indirect-content " Content-Type: text/plain Content-Length: ... Content-Type: application/sdp You may also want to add a small section on how this mechanism satisfies the requirements laid down in the requirements document (draft-ietf-sipping-content-indirect-00). Just as an after thought, the additional Content-Type may also be message/sipfrag instead of text/plain. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C22778.3597BA10 Content-Type: text/html; charset="iso-8859-1" Message
Sean,
 
One more reason for pushing for the additional Content-Type is Section 7.4.1 of RFC3261 says - "The Internet media type of the message body MUST be given by the Content-Type header field." Otherwise how will the UAS receiving the INVITE know how to parse the body? But maybe I should wait till the MIME experts give us their verdict :)
 
Thanks,
 
Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com

-----Original Message-----
From: Sean Olson [mailto:seanol@windows.microsoft.com]
Sent: Tuesday, July 09, 2002 1:30 PM
To: Parameswar, Sriram [NGC:B615:EXCH]; sip@ietf.org
Subject: RE: draft-olson-sip-content-indirect-mech-00

If you are suggesting that we might want to indirectly refer to
message/sipfrag or text/plain content, I completely agree. The
example you cite below is almost exactly what I have proposed.
I just happen to use application/sdp instead of text/html as
the (indirect) Content-Type:
 
thanks
/sean
-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: Tuesday, July 09, 2002 11:22 AM
To: Sean Olson; sip@ietf.org
Subject: RE: draft-olson-sip-content-indirect-mech-00

Thanks Sean - I would definitely like to hear from the MIME experts - but here is an example from RFC 2017 section 3 which is more along what I suggested. I think we need to take a closer look because the current draft does borrow heavily from RFC2017:

<quote RFC2017>
    Content-type: message/external-body; access-type=URL;
                  URL="http://www.foo.com/file"

    Content-type: text/html
    Content-Transfer-Encoding: binary

    THIS IS NOT REALLY THE BODY!

</quote RFC2017>

Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Sean Olson [mailto:seanol@windows.microsoft.com]
Sent: Tuesday, July 09, 2002 12:38 PM
To: Parameswar, Sriram [NGC:B615:EXCH]; sip@ietf.org
Subject: RE: draft-olson-sip-content-indirect-mech-00


Thanks for the comments!

I will try to dissect my original example to explain what I was
shooting for. I've added line numbers, plus some surrounding context
to hopefully make things a little clearer.

1   INVITE sip:bob@acme.com SIP/2.0
2   Via: SIP/2.0/TCP 10.0.0.2;branch=z9hG4bK83749
3   From: <sip:alice@acme.com>;tag=abcd
4   To: <sip:bob@acme.com>
5   Call-ID: 1@10.0.0.2
6   CSeq: 2343 INVITE
7   Content-Type: message/external-body; access-type="URL";
8                 expiration="Mon, 24 June 2002 09:00:00 GMT";
9                 URL="http://www.bogus.com/the-indirect-content"
10  Content-Length: ...
11  <CRLF>
12  Content-Type: application/sdp
13  <CRLF>


Line 12 is the start of the payload for this INVITE.
Lines 7-9 define the content type of this payload (indirect content
          available at the given URL)

Line 12 gives the content type of the indirect content. It is actually
        an entity header inside the payload (an encapsulated entity)

Line 13 marks the end of the entity headers for this encapsulated entity
        and also marks the end of the message

This is consistent with the example given in section 5.2.3 of RFC2046.
I'm using MIME in the broadest sense defined in RFC2045/2046 to allow
nesting or encapsulation of entities. This looks a bit strange compared
to other SIP messages, but I believe it is perfectly valid MIME. I
don't think we need to use message/sipfrag or even text/plain to
accomplish
this -- the capability to express nested entities and entity headers is
part of MIME.
I would be curious to hear from other MIME experts on this issue to see
if I'm
abusing something here.

/sean

-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: Sunday, July 07, 2002 6:35 PM
To: Sean Olson; 'sip@ietf.org'
Subject: draft-olson-sip-content-indirect-mech-00


Sean,
Well written draft!  In Section 3.6 'Specifying the type of the indirect
content' -
it must be clearly noted that when including the content-type of the
indirect content in the payload
- there must be Content headers specifying that payload. Along with some
textual description added to section 3.6,
the example in that section will change to look something like:

Content-Type: message/external-body; access-type="URL"; expiration="Mon,
24 June 2002 09:00:00 GMT";
URL="http://www.bogus.com/the-indirect-content"
Content-Type: text/plain
Content-Length: ...
<CRLF>
Content-Type: application/sdp
<CRLF>

You may also want to add a small section on how this mechanism satisfies
the requirements laid down in the requirements document
(draft-ietf-sipping-content-indirect-00). Just as an after thought, the
additional Content-Type may also be message/sipfrag instead of
text/plain.

Regards,
Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com

------_=_NextPart_001_01C22778.3597BA10-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 15:24:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13877 for ; Tue, 9 Jul 2002 15:24:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01273 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 15:25:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29140; Tue, 9 Jul 2002 14:55:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29110 for ; Tue, 9 Jul 2002 14:55:08 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07387 for ; Tue, 9 Jul 2002 14:54:15 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g69IsIO7011522; Tue, 9 Jul 2002 14:54:18 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3SKSF1FJ>; Tue, 9 Jul 2002 14:54:30 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2CB@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Sriram Parameswar'" , "'Sean Olson'" Cc: sip@ietf.org Subject: RE: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Date: Tue, 9 Jul 2002 14:54:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sriram -- I think you're misunderstanding the text in RFC 2017 that you quoted. Here's a simple demonstration you can use to help convince yourself that Sean's proposal is consistent with RFC 2017: How many "Content-Type" lines are in the RFC 2017 snippet you quoted? Two. One (the actual message content type) specifies message/external-body, and the other (which is actually in the message body) specifies the content type of the external content. How many "Content-Type" lines are in the example in Sean's document? Two. One (the actual message content type) specifies message/external-body, and the other (which is actually in the message body) specifies the content type of the external content. How many "Content-Type" lines are in your proposed example? Three. The first specifies message/external-body, and the third (which is actually in the message body) specifies the content type of the external content. The second specifies "text/plain" for no openly apparent reason, since there is no text/plain content related to this message in any way. Can you see how your proposal is the inconsistent one? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 15:35:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14390 for ; Tue, 9 Jul 2002 15:35:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02579 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 15:36:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00689; Tue, 9 Jul 2002 15:07:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00658 for ; Tue, 9 Jul 2002 15:07:22 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10067 for ; Tue, 9 Jul 2002 15:06:24 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g69J6o422114; Tue, 9 Jul 2002 14:06:50 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 14:06:35 -0500 Message-ID: From: "Sriram Parameswar" To: "'Adam Roach'" , "'Sean Olson'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Date: Tue, 9 Jul 2002 14:06:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2277B.BCCEDF10" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C2277B.BCCEDF10 Content-Type: text/plain; charset="iso-8859-1" Adam: Thanks for the explanation its clear - sorry for the confusion. Sean: Last comment we probably need the Content-ID header in the example: RFC 2046 "The encapsulated headers in ALL "message/external-body" entities MUST include a Content-ID header field to give a unique identifier by which to reference the data." Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Tuesday, July 09, 2002 1:54 PM To: Parameswar, Sriram [NGC:B615:EXCH]; 'Sean Olson' Cc: sip@ietf.org Subject: RE: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Sriram -- I think you're misunderstanding the text in RFC 2017 that you quoted. Here's a simple demonstration you can use to help convince yourself that Sean's proposal is consistent with RFC 2017: How many "Content-Type" lines are in the RFC 2017 snippet you quoted? Two. One (the actual message content type) specifies message/external-body, and the other (which is actually in the message body) specifies the content type of the external content. How many "Content-Type" lines are in the example in Sean's document? Two. One (the actual message content type) specifies message/external-body, and the other (which is actually in the message body) specifies the content type of the external content. How many "Content-Type" lines are in your proposed example? Three. The first specifies message/external-body, and the third (which is actually in the message body) specifies the content type of the external content. The second specifies "text/plain" for no openly apparent reason, since there is no text/plain content related to this message in any way. Can you see how your proposal is the inconsistent one? /a ------_=_NextPart_001_01C2277B.BCCEDF10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] RE: draft-olson-sip-content-indirect-mech-00

Adam:

Thanks for the explanation its clear - sorry for the = confusion.

Sean:
Last comment we probably need the Content-ID header = in the example: RFC 2046 "The encapsulated headers in ALL = "message/external-body" entities MUST include a Content-ID = header field to give a unique identifier by which to reference the = data."

Thanks,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Adam Roach [mailto:adam@dynamicsoft.com]
Sent: Tuesday, July 09, 2002 1:54 PM
To: Parameswar, Sriram [NGC:B615:EXCH]; 'Sean = Olson'
Cc: sip@ietf.org
Subject: RE: [Sip] RE: = draft-olson-sip-content-indirect-mech-00


Sriram --

I think you're misunderstanding the text in RFC 2017 = that you quoted.
Here's a simple demonstration you can use to help = convince yourself
that Sean's proposal is consistent with RFC = 2017:

How many "Content-Type" lines are in the = RFC 2017 snippet you quoted?
Two. One (the actual message content type) = specifies
message/external-body, and the other (which is = actually in the
message body) specifies the content type of the = external content.

How many "Content-Type" lines are in the = example in Sean's document?
Two. One (the actual message content type) = specifies
message/external-body, and the other (which is = actually in the
message body) specifies the content type of the = external content.

How many "Content-Type" lines are in your = proposed example?
Three. The first specifies message/external-body, = and
the third (which is actually in the message body) = specifies
the content type of the external content. The = second
specifies "text/plain" for no openly = apparent reason,
since there is no text/plain content related to = this
message in any way.

Can you see how your proposal is the inconsistent = one?

/a

------_=_NextPart_001_01C2277B.BCCEDF10-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 16:21:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15782 for ; Tue, 9 Jul 2002 16:21:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA05320 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 16:22:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02479; Tue, 9 Jul 2002 15:35:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02454 for ; Tue, 9 Jul 2002 15:35:08 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14337 for ; Tue, 9 Jul 2002 15:34:13 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 12:34:28 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jul 2002 12:34:29 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 9 Jul 2002 12:34:28 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 9 Jul 2002 12:34:28 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 9 Jul 2002 12:34:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Date: Tue, 9 Jul 2002 12:34:24 -0700 Message-ID: Thread-Topic: [Sip] RE: draft-olson-sip-content-indirect-mech-00 Thread-Index: AcIne8UzW6gX5O6sTAWbxdlmiu4QPQAA9F3A From: "Sean Olson" To: "Sriram Parameswar" , "Adam Roach" Cc: X-OriginalArrivalTime: 09 Jul 2002 19:34:24.0044 (UTC) FILETIME=[A14F16C0:01C2277F] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2277F.A154F9D5" ------_=_NextPart_001_01C2277F.A154F9D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, I'll make the Content-ID a MUST in the -01 version. /sean -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]=20 Sent: Tuesday, July 09, 2002 12:07 PM To: 'Adam Roach'; Sean Olson Cc: 'sip@ietf.org' Subject: RE: [Sip] RE: draft-olson-sip-content-indirect-mech-00 =09 =09 Adam:=20 Thanks for the explanation its clear - sorry for the confusion.=20 Sean:=20 Last comment we probably need the Content-ID header in the example: RFC 2046 "The encapsulated headers in ALL "message/external-body" entities MUST include a Content-ID header field to give a unique identifier by which to reference the data." Thanks,=20 Sriram=20 __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Interactive Multimedia Server (IMS) Fax: 972-684-3986=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 -----Original Message-----=20 From: Adam Roach [mailto:adam@dynamicsoft.com]=20 Sent: Tuesday, July 09, 2002 1:54 PM=20 To: Parameswar, Sriram [NGC:B615:EXCH]; 'Sean Olson'=20 Cc: sip@ietf.org=20 Subject: RE: [Sip] RE: draft-olson-sip-content-indirect-mech-00=20 Sriram --=20 I think you're misunderstanding the text in RFC 2017 that you quoted.=20 Here's a simple demonstration you can use to help convince yourself=20 that Sean's proposal is consistent with RFC 2017:=20 How many "Content-Type" lines are in the RFC 2017 snippet you quoted?=20 Two. One (the actual message content type) specifies=20 message/external-body, and the other (which is actually in the=20 message body) specifies the content type of the external content.=20 How many "Content-Type" lines are in the example in Sean's document?=20 Two. One (the actual message content type) specifies=20 message/external-body, and the other (which is actually in the=20 message body) specifies the content type of the external content.=20 How many "Content-Type" lines are in your proposed example?=20 Three. The first specifies message/external-body, and=20 the third (which is actually in the message body) specifies=20 the content type of the external content. The second=20 specifies "text/plain" for no openly apparent reason,=20 since there is no text/plain content related to this=20 message in any way.=20 Can you see how your proposal is the inconsistent one?=20 /a=20 ------_=_NextPart_001_01C2277F.A154F9D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Thanks, I'll make the Content-ID a MUST in the -01=20 version.
/sean
-----Original Message-----
From: = Sriram=20 Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: = Tuesday, July=20 09, 2002 12:07 PM
To: 'Adam Roach'; Sean Olson
Cc: = 'sip@ietf.org'
Subject: RE: [Sip] RE:=20 draft-olson-sip-content-indirect-mech-00

Adam:

Thanks for the explanation its clear - sorry for the = confusion.

Sean:
Last comment we = probably need=20 the Content-ID header in the example: RFC 2046 "The encapsulated = headers in=20 ALL "message/external-body" entities MUST include a Content-ID header = field to=20 give a unique identifier by which to reference the data."

Thanks,

Sriram

__________________________________________ =
Sriram=20 = Parameswar          &nb= sp;  =20 Phone: 972-685-8540
Interactive Multimedia = Server=20 (IMS) Fax: 972-684-3986
Nortel Networks, = Richardson=20 USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Adam=20 Roach [mailto:adam@dynamicsoft.com]=20
Sent: Tuesday, July 09, 2002 1:54 PM =
To: Parameswar, Sriram [NGC:B615:EXCH]; 'Sean Olson' =
Cc: sip@ietf.org
Subject: RE: [Sip] = RE:=20 draft-olson-sip-content-indirect-mech-00


Sriram --

I think you're misunderstanding the text in RFC 2017 = that you=20 quoted.
Here's a simple demonstration you = can use to=20 help convince yourself
that Sean's proposal = is=20 consistent with RFC 2017:

How many "Content-Type" lines are in the RFC 2017 = snippet you=20 quoted?
Two. One (the actual message content = type)=20 specifies
message/external-body, and the = other (which=20 is actually in the
message body) specifies = the content=20 type of the external content.

How many "Content-Type" lines are in the example in = Sean's=20 document?
Two. One (the actual message = content type)=20 specifies
message/external-body, and the = other (which=20 is actually in the
message body) specifies = the content=20 type of the external content.

How many "Content-Type" lines are in your proposed=20 example?
Three. The first specifies=20 message/external-body, and
the third (which = is=20 actually in the message body) specifies
the = content=20 type of the external content. The second
specifies=20 "text/plain" for no openly apparent reason,
since=20 there is no text/plain content related to this
message=20 in any way.

Can you see how your proposal is the inconsistent = one?=20

/a

=00 ------_=_NextPart_001_01C2277F.A154F9D5-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 17:20:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17873 for ; Tue, 9 Jul 2002 17:20:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10038 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 17:21:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06578; Tue, 9 Jul 2002 16:41:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06547 for ; Tue, 9 Jul 2002 16:41:09 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16726 for ; Tue, 9 Jul 2002 16:40:13 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g69KeY332624 for ; Tue, 9 Jul 2002 15:40:34 -0500 From: "Dean Willis" To: Date: Tue, 9 Jul 2002 15:40:30 -0500 Message-ID: <042201c22788$dd63dca0$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Should service route discover be standards track or p-header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Should the SIP Service route Discovery draft be an informational P-header or should it be standards track? Some have argued that it is more general than usual for P-headers. It seems to me to be useful whenever it is useful for a registrar to return routing infromation that UAs may use when they want request routing services from the domain served by that registrar. Opinions? See: http://search.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-06.tx t -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 17:29:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18469 for ; Tue, 9 Jul 2002 17:29:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11481 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 17:30:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07623; Tue, 9 Jul 2002 16:59:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07588 for ; Tue, 9 Jul 2002 16:59:46 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17264 for ; Tue, 9 Jul 2002 16:58:50 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g69Kxbd09201; Tue, 9 Jul 2002 22:59:38 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g69KxbP15027; Tue, 9 Jul 2002 22:59:37 +0200 (MEST) Received: from cs.columbia.edu (mhpa6v8c [139.23.202.84]) by mail-y.mchp.siemens.de with ESMTP id g69Kxb8e003893; Tue, 9 Jul 2002 22:59:37 +0200 (MET DST) Message-ID: <3D2B4E88.8020706@cs.columbia.edu> Date: Tue, 09 Jul 2002 16:58:48 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] Should service route discover be standards track or p-header References: <042201c22788$dd63dca0$eb036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit No, I think it should stay a P- header. Then, we will hopefully discover that it is generally useful and thus show that scarlet-letter headers are a flawed idea. All the other poor P- headers will then look up to this one and get some hope in their purgatory that redemption is possible. Dean Willis wrote: > Should the SIP Service route Discovery draft be an informational > P-header or should it be standards track? Some have argued that it is > more general than usual for P-headers. It seems to me to be useful > whenever it is useful for a registrar to return routing infromation that > UAs may use when they want request routing services from the domain > served by that registrar. > > Opinions? > > See: > > http://search.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-06.tx > t > > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 17:54:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19371 for ; Tue, 9 Jul 2002 17:53:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13642 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 17:54:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12261; Tue, 9 Jul 2002 17:32:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12232 for ; Tue, 9 Jul 2002 17:32:54 -0400 (EDT) Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18581 for ; Tue, 9 Jul 2002 17:31:58 -0400 (EDT) Message-ID: <20020709213247.54982.qmail@web11602.mail.yahoo.com> Received: from [131.107.3.72] by web11602.mail.yahoo.com via HTTP; Tue, 09 Jul 2002 14:32:47 PDT Date: Tue, 9 Jul 2002 14:32:47 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] Should service route discover be standards track or p-header To: Dean Willis , sip@ietf.org In-Reply-To: <042201c22788$dd63dca0$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org It seems that the applicability of the "Service Route Discovery" draft would be the same as the "Header Field for Registering Non-Adjacent Contacts" draft. Is there a reason one should be a P-header and the other should not? /sean --- Dean Willis wrote: > > Should the SIP Service route Discovery draft be an > informational > P-header or should it be standards track? Some have > argued that it is > more general than usual for P-headers. It seems to > me to be useful > whenever it is useful for a registrar to return > routing infromation that > UAs may use when they want request routing services > from the domain > served by that registrar. > > Opinions? > > See: > > http://search.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-06.tx > t > > > -- > Dean > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 18:26:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20324 for ; Tue, 9 Jul 2002 18:26:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA16270 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 18:26:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14487; Tue, 9 Jul 2002 18:02:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14426 for ; Tue, 9 Jul 2002 18:02:23 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19576 for ; Tue, 9 Jul 2002 18:01:28 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g69M1OO7013051; Tue, 9 Jul 2002 18:01:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3SKSF19M>; Tue, 9 Jul 2002 18:01:37 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2CF@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] Should service route discover be standards track or p-h eader Date: Tue, 9 Jul 2002 18:01:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'd argue that Service Route Discovery is generally useful, and doesn't involve the working-group reservations that the currently proposed P-headers do. Consider the three possible criteria for classifying something as a P header: - Is it Proprietary? Certainly not -- it's undergoing working group standardization, and is generally appliable to SIP networks in general (not just specific networks with assumptions that don't hold in the Internet at large). - Is it Private? No, it is going to be a published RFC. - Is it Preliminary? I don't think so. If it is, we need to keep working on the draft until it's fully baked. While I agree with Henning that the entire P-header ghetto concept is complete rubbish, I don't think it would be appropriate to crucify Service Route Discovery merely to prove that point. I'd prefer to continue to explain to the P-header proponents that "fire is hot and should not be touched" than to set up a tripwire designed to throw them (and the rest of us) into the campfire. /a > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 09, 2002 15:59 > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Should service route discover be standards track or > p-header > > > No, I think it should stay a P- header. Then, we will > hopefully discover > that it is generally useful and thus show that scarlet-letter headers > are a flawed idea. All the other poor P- headers will then look up to > this one and get some hope in their purgatory that redemption > is possible. > > Dean Willis wrote: > > Should the SIP Service route Discovery draft be an informational > > P-header or should it be standards track? Some have argued > that it is > > more general than usual for P-headers. It seems to me to be useful > > whenever it is useful for a registrar to return routing > infromation that > > UAs may use when they want request routing services from the domain > > served by that registrar. > > > > Opinions? > > > > See: > > > > http://search.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-06.tx > t > > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 9 18:29:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20365 for ; Tue, 9 Jul 2002 18:29:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA16471 for sip-archive@odin.ietf.org; Tue, 9 Jul 2002 18:30:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14784; Tue, 9 Jul 2002 18:04:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14723 for ; Tue, 9 Jul 2002 18:03:59 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19643; Tue, 9 Jul 2002 18:03:04 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g69M2d300626; Tue, 9 Jul 2002 17:02:39 -0500 From: "Dean Willis" To: , Date: Tue, 9 Jul 2002 17:02:33 -0500 Message-ID: <044801c22794$54a3a8d0$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Agenda, SIP WG, IETF 54 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The Siession Initiation Protocol (SIP) Working Group Agenda for IETF 54 is posted at: http://www.softarmor.com/sipwg/meets/ietf54/agenda.html Text follows. I will produce a hyperlinked version as time permits. Agenda ------ Session 1 Monday July 15, 1530-1730, Room 301/302 1530 Agenda Bash 1535 Status and Charter, Chairs 1600 Refer open issues, Robert Sparks 1615 MIMEtypes open issues, Robert Sparks 1630 MESSAGE open issues, Ben Campbell 1645 Caller Preferences open issues, Jonathan Rosenberg 1700 SIP NAT open issues, Jonathan Rosenberg 1715 Digest Authentication enhancement open issues, James Undery 1730 Break Session 2 Wednesday, July 17, 1300-1500, Room 301/302 1300 Agenda Bash 1305 Identity ppen issues, TBD (Watson, Jennings, Peterson?) 1330 URI Binding , TBD (Campbell/Schulzrinne?) 1345 SIP Compression open issues, Carsten Bormann 1400 Congestion Safety open issues, Dean Willis 1415 Discussion, referrals from SIPPING Content indirection, join, resource priority 1445 Future Work Planning Can we postpone cookie/state indefinitely? 1500 Break _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 02:07:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08010 for ; Wed, 10 Jul 2002 02:07:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA16053 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 02:08:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14922; Wed, 10 Jul 2002 01:46:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14893 for ; Wed, 10 Jul 2002 01:45:57 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28762 for ; Wed, 10 Jul 2002 01:45:03 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g6A5jQ302997 for ; Wed, 10 Jul 2002 00:45:27 -0500 Message-ID: <005001c227d4$fdeaf8e0$1a02a8c0@C1893415A> From: "Dean Willis" To: Date: Wed, 10 Jul 2002 00:45:26 -0500 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Cleanup on supplemental site "drafts" page Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I did some major cleanup at: http://www.softarmor.com/sipwg/drafts/ Note that the "approved" documents are now in the rfced sub-page linked at the top of this page. If you've authored a draft that's supposed to be currently in the SIP working group, please check here and make sure I'm tracking it. I wrote all new data-entry forms for this stuff yesterday and re-entered a lot of it this morning. I also "morgued" a lot of old documents, including those things that have cleared the RFC editor queue and are now "RFC"s. Also, please eyeball statuses and tracks and whatnot and let me know if anything looks unreasonable. Thanks, -- Dean (your loyal E-3 Clerk/Typist, just call me Radar ) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 06:01:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26460 for ; Wed, 10 Jul 2002 06:00:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13069 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 06:01:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11340; Wed, 10 Jul 2002 05:36:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11308 for ; Wed, 10 Jul 2002 05:36:08 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25909 for ; Wed, 10 Jul 2002 05:35:08 -0400 (EDT) Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g6A9ZTe12340 for ; Wed, 10 Jul 2002 15:05:29 +0530 (IST) Received: from blr-m1-bh1.wipro.com ([10.115.50.91]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GZ11AY00.DI7 for ; Wed, 10 Jul 2002 15:05:23 +0530 Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 15:05:22 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-c8a08143-c7ca-4fdf-a2b0-2165429b2d29" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 15:05:22 +0530 Message-ID: <860BFD79D602F0409BB9EEA42B9E3BC00D3047@blr-m1-msg.wipro.com> Thread-Topic: ABNF for Replaces header Thread-Index: AcIn9iwv5OZI2+wKQ6GEwjxbMJONvg== From: "Ganesh Sivaraman" To: X-OriginalArrivalTime: 10 Jul 2002 09:35:22.0900 (UTC) FILETIME=[1D217D40:01C227F5] Subject: [Sip] ABNF for Replaces header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-c8a08143-c7ca-4fdf-a2b0-2165429b2d29 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C227F5.1CEE7B64" ------_=_NextPart_001_01C227F5.1CEE7B64 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Following is the ABNF for Replaces header as specified in = draft-ietf-sip-replaces-02.txt: =20 Replaces =3D "Replaces" HCOLON callid *(SEMI replaces-param) replaces-param =3D to-tag / from-tag / generic-param to-tag =3D "to-tag" EQUAL token from-tag =3D "from-tag" EQUAL token =20 According to this I could have Replaces headers like: =20 Replaces: abcd@efgh;to-tag=3Dsdfsd --> (i) Replaces: 1234ab@cde4 --> (ii) =20 But the text right below the Replaces header's definition in the draft = states the following: =20 "A Replaces header MUST contain exactly one to-tag and exactly one = from-tag, as they are required for unique dialog matching". =20 According to this textual description the above examples ( i & ii) are = incorrect. =20 The ABNF doesn't seem to be matching this textual description. Is this a = bug with the ABNF? =20 Thanks & Regards Ganesh =20 =20 =20 ------_=_NextPart_001_01C227F5.1CEE7B64 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
  = Following is=20 the ABNF for Replaces header as specified in=20 draft-ietf-sip-replaces-02.txt:
 
Replaces =3D "Replaces" HCOLON callid = *(SEMI=20 replaces-param)
replaces-param =3D to-tag / from-tag /=20 generic-param
to-tag =3D "to-tag" EQUAL = token
from-tag =3D "from-tag" EQUAL = token
 
According to this I=20 could have Replaces headers = like:
 
Replaces:=20 abcd@efgh;to-tag=3Dsdfsd --> (i)
Replaces:=20 1234ab@cde4 --> (ii)
 
But = the text right=20 below the Replaces header's definition in the draft states the=20 following:
 
"A Replaces=20 header MUST contain exactly one to-tag and exactly one from-tag, as they = are=20 required for unique dialog matching".
 
According to=20 this textual description the above examples ( i & ii) are=20 incorrect.
 
The = ABNF doesn't=20 seem to be matching this textual description. Is this a bug with the=20 ABNF?
 
Thanks = &=20 Regards
Ganesh
 
 
 
------_=_NextPart_001_01C227F5.1CEE7B64-- ------=_NextPartTM-000-c8a08143-c7ca-4fdf-a2b0-2165429b2d29 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** ------=_NextPartTM-000-c8a08143-c7ca-4fdf-a2b0-2165429b2d29-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 07:49:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28344 for ; Wed, 10 Jul 2002 07:49:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA17941 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 07:50:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16536; Wed, 10 Jul 2002 07:17:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16445 for ; Wed, 10 Jul 2002 07:17:18 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27895 for ; Wed, 10 Jul 2002 07:16:22 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22803.32DA3034" Subject: RE: [Sip] ABNF for Replaces header Date: Wed, 10 Jul 2002 06:16:12 -0500 Message-ID: <7E06D3212981524CA10D2A114937C414093A94@NREXCH.netrake.net> Thread-Topic: ABNF for Replaces header Thread-Index: AcIn9iwv5OZI2+wKQ6GEwjxbMJONvgAC+0Gw From: "Rob Phillips" To: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C22803.32DA3034 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't see this so much as a bug in the ABNF as much as a failure in = the language. By specifying the ABNF as such, you can have: =20 Replaces: you@whereyoureat.com; to-tag=3Dthetotag; = from-tag=3Dthefromtag =20 or =20 Replaces: you@whereyoureat.com; from-tag=3Dthefromtag; = to-tag=3Dthetotag =20 or =20 Replaces: you@whereyoureat.com; myextension=3Dwhatever; = from-tag=3Dthefromtag; anotherextension=3Dwhatelse; to-tag=3Dthetotag =20 The ABNF can't specify what is mandatory without specifying the order in = which it should occur. I think specifying the ABNF as-is and then = having the trailing comment is just a way of saying, I don't care what = order you put the parameters in, but I do care that you have these two = parameters. So yes, your two examples below are both invalid. =20 - rob -----Original Message----- From: Ganesh Sivaraman [mailto:ganesh.sivaraman@wipro.com] Sent: Wednesday, July 10, 2002 4:35 AM To: sip@ietf.org Subject: [Sip] ABNF for Replaces header Hi, Following is the ABNF for Replaces header as specified in = draft-ietf-sip-replaces-02.txt: =20 Replaces =3D "Replaces" HCOLON callid *(SEMI replaces-param) replaces-param =3D to-tag / from-tag / generic-param to-tag =3D "to-tag" EQUAL token from-tag =3D "from-tag" EQUAL token =20 According to this I could have Replaces headers like: =20 Replaces: abcd@efgh;to-tag=3Dsdfsd --> (i) Replaces: 1234ab@cde4 --> (ii) =20 But the text right below the Replaces header's definition in the draft = states the following: =20 "A Replaces header MUST contain exactly one to-tag and exactly one = from-tag, as they are required for unique dialog matching". =20 According to this textual description the above examples ( i & ii) are = incorrect. =20 The ABNF doesn't seem to be matching this textual description. Is this a = bug with the ABNF? =20 Thanks & Regards Ganesh =20 =20 =20 ------_=_NextPart_001_01C22803.32DA3034 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
I=20 don't see this so much as a bug in the ABNF as much as a failure in the=20 language.  By specifying the ABNF as such, you can=20 have:
 
    Replaces: you@whereyoureat.com; = to-tag=3Dthetotag;=20 from-tag=3Dthefromtag
 
or
 
    Replaces: you@whereyoureat.com;=20 from-tag=3Dthefromtag; to-tag=3Dthetotag
 
or
 
    Replaces: you@whereyoureat.com;=20 myextension=3Dwhatever; from-tag=3Dthefromtag; = anotherextension=3Dwhatelse;=20 to-tag=3Dthetotag
 
The=20 ABNF can't specify what is mandatory without specifying the order in = which it=20 should occur.  I think specifying the ABNF as-is and then having = the=20 trailing comment is just a way of saying, I don't care what order you = put the=20 parameters in, but I do care that you have these two parameters.  = So yes,=20 your two examples below are both invalid.
 
-=20 rob
-----Original Message-----
From: Ganesh Sivaraman=20 [mailto:ganesh.sivaraman@wipro.com]
Sent: Wednesday, July = 10, 2002=20 4:35 AM
To: sip@ietf.org
Subject: [Sip] ABNF for = Replaces=20 header

Hi,
  Following=20 is the ABNF for Replaces header as specified in=20 draft-ietf-sip-replaces-02.txt:
 
Replaces =3D "Replaces" HCOLON callid = *(SEMI=20 replaces-param)
replaces-param =3D to-tag / from-tag = /=20 generic-param
to-tag =3D "to-tag" EQUAL = token
from-tag =3D "from-tag" EQUAL = token
 
According to this=20 I could have Replaces headers=20 like:
 
Replaces:=20 abcd@efgh;to-tag=3Dsdfsd --> (i)
Replaces:=20 1234ab@cde4 --> (ii)
 
But = the text right=20 below the Replaces header's definition in the draft states the=20 following:
 
"A=20 Replaces header MUST contain exactly one to-tag and exactly one = from-tag, as=20 they are required for unique dialog = matching".
 
According to=20 this textual description the above examples ( i & ii) are=20 incorrect.
 
The = ABNF doesn't=20 seem to be matching this textual description. Is this a bug with the=20 ABNF?
 
Thanks &=20 Regards
Ganesh
 
 
 
------_=_NextPart_001_01C22803.32DA3034-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 07:55:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28514 for ; Wed, 10 Jul 2002 07:55:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18282 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 07:56:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16876; Wed, 10 Jul 2002 07:29:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16844 for ; Wed, 10 Jul 2002 07:29:55 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28035 for ; Wed, 10 Jul 2002 07:28:59 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6ABTorU013289; Wed, 10 Jul 2002 13:29:51 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g6ABToa9022336; Wed, 10 Jul 2002 14:29:50 +0300 (EET DST) Message-ID: <3D2C1AAE.17FC7FEE@lmf.ericsson.se> Date: Wed, 10 Jul 2002 14:29:51 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Phillips CC: sip@ietf.org Subject: Re: [Sip] ABNF for Replaces header References: <7E06D3212981524CA10D2A114937C414093A94@NREXCH.netrake.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I would say that it is NOT an error from an ABNF poinf of view if one or more of those parameters are missing - ie you will not get a parser error. But, it is a bug from an APPLICATION point of view, since the applications does require all the parameters. (Another example is the URI, where some parameters sometimes are mandatory/forbidden depending on the SIP header the URI is defined for. Again, it is not a ABNF bug, but an APPLICATION bug, if some parameter is missing, or if some parameter is present even if it shouldn't.) Of course it is possible to make the parameters mandatory also in the ABNF, but in that case, which was said, you would have to also specify the order of them. ...OR you can add comments in the ABNF saying that all the parameters are mandatory. I don't know if that is "according to the rules", but at least Megaco uses "at-most-once", "at-most-one" etc -type of comments in the ABNF grammar. Just my thoughts... Regards, Christer Holmberg Ericsson Finland Rob Phillips wrote: > I don't see this so much as a bug in the ABNF as much as a failure in > the language. By specifying the ABNF as such, you can have: > Replaces: you@whereyoureat.com; to-tag=thetotag; > from-tag=thefromtagor Replaces: you@whereyoureat.com; > from-tag=thefromtag; to-tag=thetotagor Replaces: > you@whereyoureat.com; myextension=whatever; from-tag=thefromtag; > anotherextension=whatelse; to-tag=thetotagThe ABNF can't specify what > is mandatory without specifying the order in which it should occur. I > think specifying the ABNF as-is and then having the trailing comment > is just a way of saying, I don't care what order you put the > parameters in, but I do care that you have these two parameters. So > yes, your two examples below are both invalid.- rob > > -----Original Message----- > From: Ganesh Sivaraman [mailto:ganesh.sivaraman@wipro.com] > Sent: Wednesday, July 10, 2002 4:35 AM > To: sip@ietf.org > Subject: [Sip] ABNF for Replaces header > > Hi, Following is the ABNF for Replaces header as specified > in draft-ietf-sip-replaces-02.txt:Replaces = "Replaces" > HCOLON callid *(SEMI replaces-param)replaces-param = to-tag > / from-tag / generic-paramto-tag = "to-tag" EQUAL > tokenfrom-tag = "from-tag" EQUAL token According to this I > could have Replaces headers like: Replaces: > abcd@efgh;to-tag=sdfsd --> (i)Replaces: 1234ab@cde4 --> > (ii)But the text right below the Replaces header's > definition in the draft states the following:"A Replaces > header MUST contain exactly one to-tag and exactly one > from-tag, as they are required for unique dialog > matching".According to this textual description the above > examples ( i & ii) are incorrect.The ABNF doesn't seem to be > matching this textual description. Is this a bug with the > ABNF?Thanks & RegardsGanesh > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 08:54:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00942 for ; Wed, 10 Jul 2002 08:54:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21526 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 08:55:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20016; Wed, 10 Jul 2002 08:30:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20809 for ; Tue, 9 Jul 2002 19:35:43 -0400 (EDT) Received: from services1.dasecurenetworks.com (adsl-64-217-197-215.dsl.rcsntx.swbell.net [64.217.197.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21826 for ; Tue, 9 Jul 2002 19:34:51 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services1.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g69NDIV29122; Tue, 9 Jul 2002 18:13:19 -0500 Message-ID: <3D2B7362.70094AA6@infravast.com> Date: Tue, 09 Jul 2002 18:36:02 -0500 From: Chris Martin Reply-To: chris@infravast.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: KANUMURI Sreeram CC: Ranjit Avasarala , ShavinderPal Singh , sip@ietf.org Subject: Re: [Sip] Authentication for re-INVITE. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Spoofing is very simple without some form of authentication, merely crafting a SIP packet with a an ethernet source IP address and corresponding SIP information within the SIP/SDP body one could cause many things to go wrong with an established call, ranging from denial of service to redirection. KANUMURI Sreeram wrote: > > > > > I don't think proxy needs to authenticate re-invite, as re-invite is used > > for changing session parameters of an existing call > > >>For this very reason you should reauthenticate...so that someone doesnt > >>spoof a forged INVITE with bad parameters within it back to the client. > > TRUE but can you tell me how can "someone spoof a forged INVITE" ?? > like the call is established between the end users and it is olny session > parameters change. > As there is Already the authentication done. > olny the UA in the call can change teh parameters with a new invite.....?? > > so can u make me clearer?? > > Sreeram > > > > > Ranjit > > ----- Original Message ----- > > From: ShavinderPal Singh > > To: ; Jonathan Rosemberg > > Sent: Monday, July 08, 2002 5:21 PM > > Subject: [Sip] Authentication for re-INVITE. > > > > > > > > Is a SIP proxy supposed to Authenticate a re-INVITE also? If no, then if > > > some proxy in Authenticating and it asks for Auth Info from the UA, what > > > is the UA supposed to do? Is it mandatory that it should send the Auth > > > Info? > > > > > > Please suggest! > > > > > > Thanks & Regards > > > s > > > > > > Ph.: 091-124-6383474 (e 250) > > > __________________________________________ > > > I had a good grip on life, but then the handle broke. > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 11:01:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05678 for ; Wed, 10 Jul 2002 11:01:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05040 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 11:02:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01451; Wed, 10 Jul 2002 10:38:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01418 for ; Wed, 10 Jul 2002 10:37:59 -0400 (EDT) Received: from snail.directvbroadband.net (snail.directvbroadband.net [216.227.60.197]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04569 for ; Wed, 10 Jul 2002 10:37:04 -0400 (EDT) Received: by typhoon.directvbroadband.net with Internet Mail Service (5.5.2655.55) id <3DTW4TK8>; Wed, 10 Jul 2002 07:32:44 -0700 Message-ID: <617933180D08D311AB500090273F1F960335EE46@STORM> From: "Feldman, Michael" To: sip@ietf.org Date: Wed, 10 Jul 2002 07:37:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP info method - rfc2976 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I know this is probably a little late, but.... I do not see why the info method is supposed to follow an established signaling path. It would be helpful (in my case at least) to send session information to a third party destination not involved with the SIP call. section 1 intro: "It is necessary that the mid-session signaling information traverse the post session setup SIP signaling path. This is the path taken by SIP re-Invites, Byes, etc..." it also mentions it in section 2... thanks, mike feldman mfeldman@bb.directv.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 11:25:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06753 for ; Wed, 10 Jul 2002 11:25:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07232 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 11:26:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03458; Wed, 10 Jul 2002 10:54:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03429 for ; Wed, 10 Jul 2002 10:54:23 -0400 (EDT) Received: from commserver.iperia.com ([204.57.52.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05256 for ; Wed, 10 Jul 2002 10:53:27 -0400 (EDT) Received: by commserver.erictest.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 10:53:41 -0400 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A370B@commserver.erictest.com> From: Gordon Ledgard To: "'Feldman, Michael'" , sip@ietf.org Subject: RE: [Sip] SIP info method - rfc2976 Date: Wed, 10 Jul 2002 10:53:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org If INFO didn't follow the same rules as the rest of the SIP traffic, it would require its own whole set of procedures to validate it and make sure it belonged there. Is your "third party destination" also a SIP endpoint? Why is it in the conversation? Who says so? I believe what you are looking for can be solved via a whole slew of other mechanisms besides SIP. And yep, you're a bit late. :) Gordon Ledgard -----Original Message----- From: Feldman, Michael [mailto:mfeldman@bb.directv.com] Sent: Wednesday, July 10, 2002 10:37 AM To: sip@ietf.org Subject: [Sip] SIP info method - rfc2976 I know this is probably a little late, but.... I do not see why the info method is supposed to follow an established signaling path. It would be helpful (in my case at least) to send session information to a third party destination not involved with the SIP call. section 1 intro: "It is necessary that the mid-session signaling information traverse the post session setup SIP signaling path. This is the path taken by SIP re-Invites, Byes, etc..." it also mentions it in section 2... thanks, mike feldman mfeldman@bb.directv.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 12:30:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10034 for ; Wed, 10 Jul 2002 12:30:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17592 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 12:31:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14532; Wed, 10 Jul 2002 12:05:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14502 for ; Wed, 10 Jul 2002 12:05:43 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08734 for ; Wed, 10 Jul 2002 12:04:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6AG4wO7017538; Wed, 10 Jul 2002 12:04:58 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3SKSFHJB>; Wed, 10 Jul 2002 12:05:10 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2D2@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Feldman, Michael'" , sip@ietf.org Subject: RE: [Sip] SIP info method - rfc2976 Date: Wed, 10 Jul 2002 12:05:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The problem is that there is a widespread misconception that you can do whatever the heck you want with INFO, and still call what you're doing "SIP." In all liklihood, you're trying to accomplish a task that falls in one of the two categories: a) Something the SIP working group has thought of, and has a solution to, or b) Some useful application that we haven't thought of yet So, instead of trying to overload INFO (which is looking like an increasingly bad idea as time goes on), you'd probably be better starting on sip-implementors (see the automatically- inserted note at the end of this message), and describing your application. If it falls into category (a) (and I suspect it does -- we've been at this for a while, and have a ton of tools), then someone can point you at the relevant RFCs/drafts. If it falls into (b), then we can start working on the tools you need to implement your service. /a > -----Original Message----- > From: Feldman, Michael [mailto:mfeldman@bb.directv.com] > Sent: Wednesday, July 10, 2002 9:37 > To: sip@ietf.org > Subject: [Sip] SIP info method - rfc2976 > > > I know this is probably a little late, but.... > > > I do not see why > the info method is supposed to follow an established > signaling path. It > would be helpful (in my case at least) to send session > information to a > third party destination not involved with the SIP call. > > > > section 1 intro: > "It is necessary that the mid-session signaling information > traverse the > post session setup SIP signaling path. This is the path taken by SIP > re-Invites, Byes, etc..." > > it also mentions it in section 2... > > > thanks, > mike feldman > mfeldman@bb.directv.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 16:02:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17516 for ; Wed, 10 Jul 2002 16:02:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04503 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 16:03:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02208; Wed, 10 Jul 2002 15:34:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02177 for ; Wed, 10 Jul 2002 15:34:50 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16689 for ; Wed, 10 Jul 2002 15:33:55 -0400 (EDT) Received: from jku2.fokus.gmd.de (dhcp246.fokus.gmd.de [195.37.78.246]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g6AJY5C24521; Wed, 10 Jul 2002 21:34:05 +0200 Message-Id: <5.1.0.14.0.20020710213233.02d3b8a8@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Jul 2002 21:34:09 +0200 To: Ben Campbell From: Jiri Kuthan Cc: sip@ietf.org In-Reply-To: <3D29E679.7060405@dynamicsoft.com> References: <5.1.0.14.0.20020703142040.033c0fb8@iptel.org> <5.1.0.14.0.20020703200900.00b3d110@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Re: MESSAGE advertising in REGISTERs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org What I actually do not understand is why we have not put this requirement on all supported methods. Fixing it for a specific methods seems better (though ugly) to me than fixing it for none. -Jiri At 09:22 PM 7/8/2002, Ben Campbell wrote: >I do not understand why we would expect support of MESSAGE to give a client a higher requirement for registration than for clients that do not support MESSAGE. > >Jiri Kuthan wrote: >>Though advertising MESSAGE capability in REGISTERs does >>not hurt in any scenario, not advertising hurts in some. >>That's why I would much prefer having it as a MUST. >>-Jiri >>At 06:51 PM 7/3/2002, Ben Campbell wrote: >> >>>Certainly it will be needed to make many server related scenarios work. It is optional because MESSAGE can also be used in a pure end-to-end mode without assuming that such servers exist. For example, a MESSAGE UAC may discover the contact for a MESSAGE UAS from presence information (i.e. a contact in a presence doc), then send the MESSAGE request directly with no intervening servers. In this architecture, there is not necessarily a need to advertise support at a registrar. >>> >>>Jiri Kuthan wrote: >>> >>>>Can someone tell me why the MESSAGE I-D mandates advertising >>>>of support in REGISTERs of a MESSAGE-capable UAC only *optionally*? >>>>Making it optional gains little knowledge to a SIP server -- a server does not know anything it could reliably use in its processing logic. >>>>Think of a SIP server which acts as a proxy server and message store. >>>>If it knew, that downstream UAS was not capable of processing MESSAGEs, >>>>it could immediately store an incoming MESSAGE, send 202 upstream, >>>>and relay the message to first UAC which registers and advertises support >>>>for MESSAGE in REGISTER. >>>>Because the server does not know it, it has to relay unnecessarily a message to an upstream UAS, which will deny it. Then, whenever a REGISTER arrives, the server will try to dump message store to it, >>>>(hoping a UAC capable of MESSAGE registered) resulting in quite >>>>uneffective behaviour. >>>>-Jiri > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 16:39:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18906 for ; Wed, 10 Jul 2002 16:39:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07325 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 16:40:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04764; Wed, 10 Jul 2002 16:17:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04733 for ; Wed, 10 Jul 2002 16:17:24 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18033 for ; Wed, 10 Jul 2002 16:16:29 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6AKL0a05309; Wed, 10 Jul 2002 15:21:00 -0500 Subject: Re: [Sip] REFER: Who has implemented REFER without creating subscriptions? From: Robert Sparks To: Robert Sparks Cc: sip@ietf.org In-Reply-To: <1025189183.2344.35.camel@dhcp150.dfw.dynamicsoft.com> References: <3D17F899.A5D25374@pingtel.com> <1025018225.1689.222.camel@localhost.localdomain> <3D1A3E49.4A795013@pingtel.com> <1025189183.2344.35.camel@dhcp150.dfw.dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 10 Jul 2002 15:14:55 -0500 Message-Id: <1026332095.1185.48.camel@dhcp150.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've received no responses indicating someone has implemented accepting REFER and not sending NOTIFY. As sip-events matured, the perceived potential need for that behavior has diminished. So, I am changing REFER to require the implicit subscription, so at least one NOTIFY will always be sent. (An implementation that needs to be extremely lightweight can send just one NOTIFY terminating the subscription). This change makes the Required/Supported mechanics discussed in draft-sparks-sip-refer-3265disc-00 unnecessary. I will remove them. When the submission blackout is listed, I will submit the revised 3265disc draft as draft-ietf-sip-refer-06. RjS On Thu, 2002-06-27 at 09:46, Robert Sparks wrote: > This was part of the last message I sent, but it was buried > pretty deep. > > When we made the decision to go with implicit subscriptions > work around the finite length non-INVITE transaction, we made > serving that subscription SHOULD strength to allow for implementations > that couldn't deal with the weight of serving subscriptions. > > Do the original proponents of allowing implementations to never > send a notify still see this need? Are there any implementations > out there that accept a REFER but don't send NOTIFYs? > > The subscription concept has substantially matured (in particular, > Subscription-State is explicitly communicated). As Dan points out > in his last note, an implementation that needed to be very lightweight > could send exactly one NOTIFY terminating the subscription. If > serving the subscription (even if it involved sending just that > one NOTIFY) were strictly mandatory, the error space is much smaller. > > RjS > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 17:55:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21344 for ; Wed, 10 Jul 2002 17:55:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12323 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 17:56:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10507; Wed, 10 Jul 2002 17:21:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10476 for ; Wed, 10 Jul 2002 17:21:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20247 for ; Wed, 10 Jul 2002 17:20:58 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA28387; Wed, 10 Jul 2002 17:21:19 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15686; Wed, 10 Jul 2002 17:21:20 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jul 2002 17:21:19 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B5643@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Robert Sparks'" Cc: sip@ietf.org Subject: RE: [Sip] REFER: Who has implemented REFER without creating subsc riptions? Date: Wed, 10 Jul 2002 17:21:16 -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@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Of course we observe that "at least one" means some implementations send one NOTIFY upon completion of REFER. The new spec requires at least two, an immediate one, and the one upon completion. I agree we don't need the Required/Supported mechanism however. All of us with "exactly one" will have to upgrade, but that's the cost of implementing a draft. Brian > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, July 10, 2002 4:15 PM > To: Robert Sparks > Cc: sip@ietf.org > Subject: Re: [Sip] REFER: Who has implemented REFER without creating > subscriptions? > > > I've received no responses indicating someone has implemented > accepting REFER and not sending NOTIFY. As sip-events matured, > the perceived potential need for that behavior has diminished. > > So, I am changing REFER to require the implicit subscription, > so at least one NOTIFY will always be sent. (An implementation > that needs to be extremely lightweight can send just one NOTIFY > terminating the subscription). This change makes the > Required/Supported mechanics discussed in > draft-sparks-sip-refer-3265disc-00 unnecessary. I will remove > them. > > When the submission blackout is listed, I will submit the > revised 3265disc draft as draft-ietf-sip-refer-06. > > RjS > > On Thu, 2002-06-27 at 09:46, Robert Sparks wrote: > > This was part of the last message I sent, but it was buried > > pretty deep. > > > > When we made the decision to go with implicit subscriptions > > work around the finite length non-INVITE transaction, we made > > serving that subscription SHOULD strength to allow for > implementations > > that couldn't deal with the weight of serving subscriptions. > > > > Do the original proponents of allowing implementations to never > > send a notify still see this need? Are there any implementations > > out there that accept a REFER but don't send NOTIFYs? > > > > The subscription concept has substantially matured (in particular, > > Subscription-State is explicitly communicated). As Dan points out > > in his last note, an implementation that needed to be very > lightweight > > could send exactly one NOTIFY terminating the subscription. If > > serving the subscription (even if it involved sending just that > > one NOTIFY) were strictly mandatory, the error space is > much smaller. > > > > RjS > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 10 17:55:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21358 for ; Wed, 10 Jul 2002 17:55:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12334 for sip-archive@odin.ietf.org; Wed, 10 Jul 2002 17:56:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11402; Wed, 10 Jul 2002 17:31:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11376 for ; Wed, 10 Jul 2002 17:31:41 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20535 for ; Wed, 10 Jul 2002 17:30:46 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6ALUtO7020445; Wed, 10 Jul 2002 17:30:55 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3SKSF26C>; Wed, 10 Jul 2002 17:31:09 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2DB@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" , Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] REFER: Who has implemented REFER without creating subsc riptions? Date: Wed, 10 Jul 2002 17:31:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > The new [REFER] spec requires at least two [NOTIFYs], > an immediate one, and the one upon completion. As Dan pointed out and Robert reiterated, this isn't precisely true. You can get away with just one NOTIFY: the immediate one. As long as the "Subscription- State" header indicates "terminated," this behavior complies with the draft. The distinction is important, since it doesn't require recipients of REFER to implement the full event mechanism. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 11 03:43:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12021 for ; Thu, 11 Jul 2002 03:43:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18747 for sip-archive@odin.ietf.org; Thu, 11 Jul 2002 03:43:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16642; Thu, 11 Jul 2002 03:10:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16581 for ; Thu, 11 Jul 2002 03:10:51 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11490; Thu, 11 Jul 2002 03:09:56 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6B7AkrU017275; Thu, 11 Jul 2002 09:10:46 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g6B7Aia9019985; Thu, 11 Jul 2002 10:10:44 +0300 (EET DST) Message-ID: <3D2D2F76.91C4B92B@lmf.ericsson.se> Date: Thu, 11 Jul 2002 10:10:46 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: Gonzalo Camarillo , rohan@cisco.com, sip@ietf.org, sipping@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I think it is important to think of who is allowed to "demand" what. Can we always assume the client makes the final decission? What if the server - for whatever reason - doens't want to/isn't able to reuse the connection? Shall it send some kind of error response to the request where the "demand" is specified, or shall it be allowed to use another, or establish a new, connection? Shall the server be allowed to "demand" a re-use of connection, even if the client didn't? How does this affect backward compability, if the indicators aren't understood by all the nodes? Do we need Supported/Require/Proxy-Require tags? Regards, Christer Holmberg Ericsson Finland > Good point. Is this is a request or a demand by the client to re-use > the connection? I think we need the possibility for the client to > *demand* that the connection be re-used. There may also be situations > where re-use is just an optimization. > > /sean > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, July 09, 2002 9:41 AM > To: Sean Olson; Gonzalo Camarillo; rohan@cisco.com; sip@ietf.org; > sipping@ietf.org > Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 > > Another comment, > > I also think it is important to remember that there MAY be scenarios, > especially if a connection is used for multiple sessions, where one > wants to use separate connections per each direction - even if the > client indicates he wants to use the same connection for the response. > Just to think of before the MUSTs are added... > > Regards, > > Christer Holmberg > Ericsson Finland > > Christer Holmberg wrote: > > > Hi Sean, > > > > > Is this really out of scope for this draft? Naturally > > > the more re-use you make of the connection, the more benefit you get > > > > from re-use ;-) > > > > Of course, but in that case it should be mentioned in the draft :) > > > > The only thing the draft currently talks about the problem how to make > > > sure a single connection is used for both directions, per session - > > which is a separate issue from reusing connections for multiple > > sessions. > > > > And, since I don't think any draft currently talks about the reuse of > > connections for multiple sessions (bis talks about keeping the > > connection open to make sure the transaction uses the same > > transaction), maybe it could be added to the connect-reuse draft? > > > > Just some thoughts... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > /sean > > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Tuesday, July 09, 2002 6:30 AM > > > To: Gonzalo Camarillo > > > Cc: Sean Olson; rohan@cisco.com; sip@ietf.org; sipping@ietf.org > > > Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 > > > > > > Hi, > > > > > > RFC3261/bis-9 mainly talks about using a single connection (or, one > > > in each > > > direction) for a single transaction, and the connect-reuse draft > > > talks about being able to use a single connection for messages in > > > both direction, for a single session. Sometimes, however, when we > > > talk about "reuse of connection" we mean when a single connection > > > (or, one in each > > > direction) is used for multiple sessions. I think it would be a good > > > idea to mention that that kind of "reuse" is out of the scope of the > > > draft. Otherwise the draft subject should more clear indicate what > kind > > > of reuse it refers to... > > > > > > Of course, once a single connection is established, according to the > > > > connect-reuse draft, it MAY be used for multiple sessions, but > > > that's not the scope of the draft, so... > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 11 11:09:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20352 for ; Thu, 11 Jul 2002 11:09:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14575 for sip-archive@odin.ietf.org; Thu, 11 Jul 2002 11:10:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12269; Thu, 11 Jul 2002 10:43:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12179 for ; Thu, 11 Jul 2002 10:43:36 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19496; Thu, 11 Jul 2002 10:42:41 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6BEh339002625; Thu, 11 Jul 2002 07:43:03 -0700 (PDT) Received: from open-131-161-248-87.cliq.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAK07920; Thu, 11 Jul 2002 07:43:02 -0700 (PDT) Date: Thu, 11 Jul 2002 07:43:47 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Sean Olson , Gonzalo Camarillo , sip@ietf.org, sipping@ietf.org To: Christer Holmberg From: Rohan Mahy In-Reply-To: <3D2D2F76.91C4B92B@lmf.ericsson.se> Message-Id: <9B79BAA0-94DC-11D6-9F1D-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The current wording is that connection reuse is part of a request which can be rejected. I need to understand Sean's use case a little better, but I suspect this will need to remain a request, because the request might not be authorized. I guess the key question is what do you do if the request can't be handled? do you reject with an error message or handle the SIP request anyway (ignoring the connection reuse). perhaps this is what Sean meant. We probably should have an indication that the alias is optional or required. Of course, required handling would also imply a Proxy-Require/Require which I was trying to avoid.... thanks, -rohan On Thursday, July 11, 2002, at 12:10 AM, Christer Holmberg wrote: > > Hi, > > I think it is important to think of who is allowed to "demand" what. > Can we > always assume the client makes the final decission? What if the > server - for > whatever reason - doens't want to/isn't able to reuse the connection? > Shall > it send some kind of error response to the request where the "demand" is > specified, or shall it be allowed to use another, or establish a new, > connection? Shall the server be allowed to "demand" a re-use of > connection, > even if the client didn't? How does this affect backward compability, > if the > indicators aren't understood by all the nodes? Do we need > Supported/Require/Proxy-Require tags? > > Regards, > > Christer Holmberg > Ericsson Finland > > > >> Good point. Is this is a request or a demand by the client to re-use >> the connection? I think we need the possibility for the client to >> *demand* that the connection be re-used. There may also be situations >> where re-use is just an optimization. >> >> /sean >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >> Sent: Tuesday, July 09, 2002 9:41 AM >> To: Sean Olson; Gonzalo Camarillo; rohan@cisco.com; sip@ietf.org; >> sipping@ietf.org >> Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 >> >> Another comment, >> >> I also think it is important to remember that there MAY be scenarios, >> especially if a connection is used for multiple sessions, where one >> wants to use separate connections per each direction - even if the >> client indicates he wants to use the same connection for the response. >> Just to think of before the MUSTs are added... >> >> Regards, >> >> Christer Holmberg >> Ericsson Finland >> >> Christer Holmberg wrote: >> >>> Hi Sean, >>> >>>> Is this really out of scope for this draft? Naturally >>>> the more re-use you make of the connection, the more benefit you get >> >>>> from re-use ;-) >>> >>> Of course, but in that case it should be mentioned in the draft :) >>> >>> The only thing the draft currently talks about the problem how to make >> >>> sure a single connection is used for both directions, per session - >>> which is a separate issue from reusing connections for multiple >>> sessions. >>> >>> And, since I don't think any draft currently talks about the reuse of >>> connections for multiple sessions (bis talks about keeping the >>> connection open to make sure the transaction uses the same >>> transaction), maybe it could be added to the connect-reuse draft? >>> >>> Just some thoughts... >>> >>> Regards, >>> >>> Christer Holmberg >>> Ericsson Finland >>> >>>> >>>> >>>> /sean >>>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >>>> Sent: Tuesday, July 09, 2002 6:30 AM >>>> To: Gonzalo Camarillo >>>> Cc: Sean Olson; rohan@cisco.com; sip@ietf.org; sipping@ietf.org >>>> Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 >>>> >>>> Hi, >>>> >>>> RFC3261/bis-9 mainly talks about using a single connection (or, one >>>> in each >>>> direction) for a single transaction, and the connect-reuse draft >>>> talks about being able to use a single connection for messages in >>>> both direction, for a single session. Sometimes, however, when we >>>> talk about "reuse of connection" we mean when a single connection >>>> (or, one in each >>>> direction) is used for multiple sessions. I think it would be a good >>>> idea to mention that that kind of "reuse" is out of the scope of the >>>> draft. Otherwise the draft subject should more clear indicate what >> kind >>>> of reuse it refers to... >>>> >>>> Of course, once a single connection is established, according to the >> >>>> connect-reuse draft, it MAY be used for multiple sessions, but >>>> that's not the scope of the draft, so... >>>> >>>> Regards, >>>> >>>> Christer Holmberg >>>> Ericsson Finland >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sip@ietf.org for new developments of core SIP > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 11 13:47:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27688 for ; Thu, 11 Jul 2002 13:47:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03099 for sip-archive@odin.ietf.org; Thu, 11 Jul 2002 13:48:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26342; Thu, 11 Jul 2002 12:45:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26270 for ; Thu, 11 Jul 2002 12:45:28 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24848; Thu, 11 Jul 2002 12:44:34 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 09:41:02 -0700 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Jul 2002 09:41:02 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 11 Jul 2002 09:41:03 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 09:41:02 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 11 Jul 2002 09:41:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Jul 2002 09:40:20 -0700 Message-ID: Thread-Topic: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Thread-Index: AcIo6UYXkv8CIiqhRDGMY/yr2C8UGAAEDLSQ From: "Sean Olson" To: "Rohan Mahy" , "Christer Holmberg" Cc: "Gonzalo Camarillo" , , X-OriginalArrivalTime: 11 Jul 2002 16:41:06.0441 (UTC) FILETIME=[C0AE4790:01C228F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA26271 Subject: [Sip] RE: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I am considering the use case where the connection between the client and the server is "one-way". By one-way, I mean only the client may establish a connection to the server and not the other way around, usually due to an intermediate firewall. In this case, it is critical that the server re-use the connection that the client established to it, not only for this transaction but for all subsequent messaging. /sean -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Thursday, July 11, 2002 7:44 AM To: Christer Holmberg Cc: Sean Olson; Gonzalo Camarillo; sip@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 Hi, The current wording is that connection reuse is part of a request which can be rejected. I need to understand Sean's use case a little better, but I suspect this will need to remain a request, because the request might not be authorized. I guess the key question is what do you do if the request can't be handled? do you reject with an error message or handle the SIP request anyway (ignoring the connection reuse). perhaps this is what Sean meant. We probably should have an indication that the alias is optional or required. Of course, required handling would also imply a Proxy-Require/Require which I was trying to avoid.... thanks, -rohan On Thursday, July 11, 2002, at 12:10 AM, Christer Holmberg wrote: > > Hi, > > I think it is important to think of who is allowed to "demand" what. > Can we > always assume the client makes the final decission? What if the > server - for > whatever reason - doens't want to/isn't able to reuse the connection? > Shall > it send some kind of error response to the request where the "demand" is > specified, or shall it be allowed to use another, or establish a new, > connection? Shall the server be allowed to "demand" a re-use of > connection, > even if the client didn't? How does this affect backward compability, > if the > indicators aren't understood by all the nodes? Do we need > Supported/Require/Proxy-Require tags? > > Regards, > > Christer Holmberg > Ericsson Finland > > > >> Good point. Is this is a request or a demand by the client to re-use >> the connection? I think we need the possibility for the client to >> *demand* that the connection be re-used. There may also be situations >> where re-use is just an optimization. >> >> /sean >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >> Sent: Tuesday, July 09, 2002 9:41 AM >> To: Sean Olson; Gonzalo Camarillo; rohan@cisco.com; sip@ietf.org; >> sipping@ietf.org >> Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 >> >> Another comment, >> >> I also think it is important to remember that there MAY be scenarios, >> especially if a connection is used for multiple sessions, where one >> wants to use separate connections per each direction - even if the >> client indicates he wants to use the same connection for the >> response. Just to think of before the MUSTs are added... >> >> Regards, >> >> Christer Holmberg >> Ericsson Finland >> >> Christer Holmberg wrote: >> >>> Hi Sean, >>> >>>> Is this really out of scope for this draft? Naturally >>>> the more re-use you make of the connection, the more benefit you >>>> get >> >>>> from re-use ;-) >>> >>> Of course, but in that case it should be mentioned in the draft :) >>> >>> The only thing the draft currently talks about the problem how to >>> make >> >>> sure a single connection is used for both directions, per session - >>> which is a separate issue from reusing connections for multiple >>> sessions. >>> >>> And, since I don't think any draft currently talks about the reuse >>> of connections for multiple sessions (bis talks about keeping the >>> connection open to make sure the transaction uses the same >>> transaction), maybe it could be added to the connect-reuse draft? >>> >>> Just some thoughts... >>> >>> Regards, >>> >>> Christer Holmberg >>> Ericsson Finland >>> >>>> >>>> >>>> /sean >>>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >>>> Sent: Tuesday, July 09, 2002 6:30 AM >>>> To: Gonzalo Camarillo >>>> Cc: Sean Olson; rohan@cisco.com; sip@ietf.org; sipping@ietf.org >>>> Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 >>>> >>>> Hi, >>>> >>>> RFC3261/bis-9 mainly talks about using a single connection (or, one >>>> in each >>>> direction) for a single transaction, and the connect-reuse draft >>>> talks about being able to use a single connection for messages in >>>> both direction, for a single session. Sometimes, however, when we >>>> talk about "reuse of connection" we mean when a single connection >>>> (or, one in each >>>> direction) is used for multiple sessions. I think it would be a >>>> good idea to mention that that kind of "reuse" is out of the scope >>>> of the draft. Otherwise the draft subject should more clear >>>> indicate what >> kind >>>> of reuse it refers to... >>>> >>>> Of course, once a single connection is established, according to >>>> the >> >>>> connect-reuse draft, it MAY be used for multiple sessions, but >>>> that's not the scope of the draft, so... >>>> >>>> Regards, >>>> >>>> Christer Holmberg >>>> Ericsson Finland >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sip@ietf.org for new developments of core SIP > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 11 14:56:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01136 for ; Thu, 11 Jul 2002 14:56:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09681 for sip-archive@odin.ietf.org; Thu, 11 Jul 2002 14:57:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06990; Thu, 11 Jul 2002 14:16:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06959 for ; Thu, 11 Jul 2002 14:16:32 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29271 for ; Thu, 11 Jul 2002 14:15:39 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6BIG2hI017156; Thu, 11 Jul 2002 11:16:02 -0700 (PDT) Received: from cisco.com (dhcp-128-107-138-217.cisco.com [128.107.138.217]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEJ82483; Thu, 11 Jul 2002 11:13:09 -0700 (PDT) Message-ID: <3D2DCB5E.8C212C9F@cisco.com> Date: Thu, 11 Jul 2002 11:15:58 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------811837795B5E2981C5D1569A" Subject: [Sip] Out-of-Band DTMF Relay Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------811837795B5E2981C5D1569A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is there a draft or spec addressing how out-of-band DTMF relay should be done in SIP. Is there preference between the INFO message and a NOTIFY message to carry this out-of-band DTMF between 2 SIP end-points. Thanks, Sarvi --------------811837795B5E2981C5D1569A Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Sarvi tel;work:408-527-4875 x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Group adr:;;;;;; version:2.1 email;internet:sarvi@cisco.com title:Technical Leader fn:Sarvi Shanmugham end:vcard --------------811837795B5E2981C5D1569A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 11 18:18:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09383 for ; Thu, 11 Jul 2002 18:18:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22045 for sip-archive@odin.ietf.org; Thu, 11 Jul 2002 18:19:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19787; Thu, 11 Jul 2002 17:45:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26835 for ; Thu, 11 Jul 2002 12:49:09 -0400 (EDT) Received: from stamail.telecom.sna.samsung.com (mail1.sta.samsung.com [63.166.115.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25036 for ; Thu, 11 Jul 2002 12:48:15 -0400 (EDT) Received: by stamail.telecom.sna.samsung.com with Internet Mail Service (5.5.2653.19) id <3VG438L4>; Thu, 11 Jul 2002 11:52:15 -0500 Message-ID: <4B9386E83999D411997100508BAF206A061F4FAB@stamail.telecom.sna.samsung.com> From: Kedar Patil To: "'sip@ietf.org'" Date: Thu, 11 Jul 2002 11:52:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228FB.49FE9A80" Subject: [Sip] question on new offer in a dialog Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C228FB.49FE9A80 Content-Type: text/plain; charset="iso-8859-1" Hi, Section 13.2.1 (Page 80) of RFC3261 says : ====================================================== o After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in requests based on rules specified for that method, but only "if it has received answers to any previous offers", AND "has not sent any offers to which it hasn't gotten an answer". ======================================================= The last two clauses (enclosed in double quotes) joined by "AND" mean the same thing, Isn't it? Is there any hidden case in either clause not covered by the other? thanks, = Kedar = ------_=_NextPart_001_01C228FB.49FE9A80 Content-Type: text/html; charset="iso-8859-1" question on new offer in a dialog

Hi,

Section 13.2.1 (Page 80) of RFC3261 says :

======================================================
o After having sent or received an answer to the first offer, the
  UAC MAY generate subsequent offers in requests based on rules
  specified for that method, but only "if it has received answers
  to any previous offers", AND "has not sent any offers to which it
  hasn't gotten an answer".
=======================================================

The last two clauses (enclosed in double quotes) joined by "AND"
mean the same thing, Isn't it? Is there any hidden case in either
clause not covered by the other?

thanks,
= Kedar =

------_=_NextPart_001_01C228FB.49FE9A80-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 11 18:18:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09402 for ; Thu, 11 Jul 2002 18:18:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22058 for sip-archive@odin.ietf.org; Thu, 11 Jul 2002 18:19:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19169; Thu, 11 Jul 2002 17:36:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19138 for ; Thu, 11 Jul 2002 17:36:15 -0400 (EDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07305 for ; Thu, 11 Jul 2002 17:35:20 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g6BLaCgD024072 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 11 Jul 2002 14:36:12 -0700 (PDT) Received: from MAHENDRA.qualcomm.com (mahendra.qualcomm.com [129.46.75.104]) by magus.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g6BLa9Zd028809 for ; Thu, 11 Jul 2002 14:36:10 -0700 (PDT) Message-Id: <5.1.0.14.2.20020711143204.02656460@clea.qualcomm.com> X-Sender: mahendra@clea.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Jul 2002 14:36:09 -0700 To: sip@ietf.org From: AC Mahendran In-Reply-To: <200207071633.MAA25356@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] draft-ietf-sip-sec-agree-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I have question regarding the purpose of the "Security-Client" field. Based on the description, it looks like this field is not used by the server in any way. Can someone explain the purpose of this field? thanks, AC Ps: In the "Server Initiated" (Section 3.4.2) procedures, this field is not used. By the same reasoning, this field should not be applicable to the "Client Initiated" procedures as well. At 12:33 PM 7/7/2002 -0400, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Session Initiation Protocol Working Group >of the IETF. > > Title : Security Mechanism Agreement for SIP Sessions > Author(s) : J. Arkko et al. > Filename : draft-ietf-sip-sec-agree-04.txt > Pages : 17 > Date : 05-Jul-02 > >SIP has a number of security mechanisms. Some of them have been built >in to the SIP protocol, such as HTTP authentication or secure >attachments. These mechanisms have even alternative algorithms and >parameters. SIP does not currently provide any mechanism for >selecting which security mechanisms to use between two entities. In >particular, even if some mechanisms such as OPTIONS were used to make >this selection, the selection would be vulnerable against the >Bidding-Down attack. This document defines three header fields for >negotiating the security mechanisms within SIP between a SIP entity >and its next SIP hop. A SIP entity applying this mechanism must >always require some minimum security (i.e. integrity protection) from >all communicating parties in order to secure the negotiation, but the >negotiation can agree on which specific minimum security is used. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sip-sec-agree-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sip-sec-agree-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20020705142509.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sip-sec-agree-04.txt > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 12 09:41:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22087 for ; Fri, 12 Jul 2002 09:41:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17389 for sip-archive@odin.ietf.org; Fri, 12 Jul 2002 09:42:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15782; Fri, 12 Jul 2002 09:12:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15750 for ; Fri, 12 Jul 2002 09:12:08 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21030 for ; Fri, 12 Jul 2002 09:11:12 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6CDCYi09686 for ; Fri, 12 Jul 2002 16:12:34 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 12 Jul 2002 16:12:03 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 16:12:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 12 Jul 2002 16:12:02 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203E6@esebe019.NOE.Nokia.com> Thread-Topic: Questions on sip-guidelines Thread-Index: AcIppbYti0teLkmLR2u8Da36Q4ejRA== To: X-OriginalArrivalTime: 12 Jul 2002 13:12:03.0336 (UTC) FILETIME=[B6D21880:01C229A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA15751 Subject: [Sip] Questions on sip-guidelines Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit - Is defining a new sip-uri parameter considered to be an extension. This also applies to headers that allow extension params. If so, should this be mentioned in the draft? - Should the draft also mention something about registering new sip headers, methods, option-tags with IANA? - "Extensions that define new methods SHOULD use all capitals for the method name". Why not a MUST? Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 12 11:02:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26278 for ; Fri, 12 Jul 2002 11:02:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23924 for sip-archive@odin.ietf.org; Fri, 12 Jul 2002 11:03:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22066; Fri, 12 Jul 2002 10:36:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22038 for ; Fri, 12 Jul 2002 10:36:06 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24820 for ; Fri, 12 Jul 2002 10:35:10 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6CEZYM05872; Fri, 12 Jul 2002 09:35:34 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 09:35:20 -0500 Message-ID: From: "Sriram Parameswar" To: "'Adam Roach'" , "'Rosen, Brian'" , Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] REFER: Who has implemented REFER without creating subsc riptions? Date: Fri, 12 Jul 2002 09:35:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C229B1.58AD2E50" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C229B1.58AD2E50 Content-Type: text/plain; charset="iso-8859-1" Hi All, I think there is definite value to having REFER without NOTIFYs. There are several non transfer applications that benefit from REFER, without having the overhead of the NOTIFY(s). To this end, I suggest that we include an option-tag "nosubscription" to the REFER method. Thus if a UA wants to send a REFER but does not care for notification of success of failure - it puts in Require: nosubscription. The inclusion of the 'nosubscription' option-tag causes the REFER to complete upon receiving the 202, without the need for NOTIFY(s). This is also backwards compatible - because a regular REFER (without this option-tag) continues to show standard behavior with atleast one NOTIFY. Comments are welcome, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Wednesday, July 10, 2002 4:31 PM To: 'Rosen, Brian'; Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] REFER: Who has implemented REFER without creating subsc riptions? > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > The new [REFER] spec requires at least two [NOTIFYs], > an immediate one, and the one upon completion. As Dan pointed out and Robert reiterated, this isn't precisely true. You can get away with just one NOTIFY: the immediate one. As long as the "Subscription- State" header indicates "terminated," this behavior complies with the draft. The distinction is important, since it doesn't require recipients of REFER to implement the full event mechanism. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C229B1.58AD2E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] REFER: Who has implemented REFER without creating = subsc riptions?

Hi All,

I think there is definite value to having REFER = without NOTIFYs. There are several non transfer applications that = benefit from REFER, without having the overhead of the = NOTIFY(s).

To this end, I suggest that we include an option-tag = "nosubscription" to the REFER method. Thus if a UA wants to = send a REFER but does not care for notification of success of failure - = it puts in Require: nosubscription. The inclusion of the = 'nosubscription' option-tag causes the REFER to complete upon receiving = the 202, without the need for NOTIFY(s). This is also backwards = compatible - because a regular REFER (without this option-tag) = continues to show standard behavior with atleast one NOTIFY.

Comments are welcome,

Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Adam Roach [mailto:adam@dynamicsoft.com]
Sent: Wednesday, July 10, 2002 4:31 PM
To: 'Rosen, Brian'; Robert Sparks
Cc: sip@ietf.org
Subject: RE: [Sip] REFER: Who has implemented REFER = without creating
subsc riptions?


> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
>
> The new [REFER] spec requires at least two = [NOTIFYs],
> an immediate one, and the one upon = completion.

As Dan pointed out and Robert reiterated, this = isn't
precisely true. You can get away with just = one
NOTIFY: the immediate one. As long as the = "Subscription-
State" header indicates "terminated," = this behavior
complies with the draft. The distinction is = important,
since it doesn't require recipients of REFER to = implement
the full event mechanism.

/a

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

------_=_NextPart_001_01C229B1.58AD2E50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sun Jul 14 08:19:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03276 for ; Sun, 14 Jul 2002 08:19:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA17886 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 08:20:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17358; Sun, 14 Jul 2002 08:03:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17330 for ; Sun, 14 Jul 2002 08:03:48 -0400 (EDT) Received: from kenny.siteprotect.com (kenny.siteprotect.com [64.26.0.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02798 for ; Sun, 14 Jul 2002 08:02:50 -0400 (EDT) Received: from joshua (host217-39-33-101.in-addr.btopenworld.com [217.39.33.101]) by kenny.siteprotect.com (8.9.3/8.9.3) with ESMTP id HAA15961 for ; Sun, 14 Jul 2002 07:03:14 -0500 From: "Ofir Arkin" To: Date: Sun, 14 Jul 2002 13:02:45 +0100 Message-ID: <000d01c22b2e$5ff00290$0a01a8c0@joshua> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Some qustions on processing REGISTER requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit While reading RFC 3261 section 10.3 Processing REGISTER requests I have encountered several questions I could not find answers for: 1. Step 1: When the Registrar inspects the Request-URI to determine if it has access to the required bindings, the RFC does not specify what the Registrar should do if it does not have access to the binding (and when it cannot forward the request). Is there a response code sent in that case? 2. Step 5: the 'To' header value is examined (address-of-record) to verify it is valid with the domain found in the Request-URI. The actual verification test in not given with the text, but can I assume the authors meant that the domain names should be the same? Btw - Are there open source or free SIP Registrar servers that actually implements the requirements found with RFC 3261? Thanks! Ofir Arkin [ofir@sys-security.com] Founder The Sys-Security Group http://www.sys-security.com PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sun Jul 14 11:00:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08281 for ; Sun, 14 Jul 2002 10:58:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22699 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 10:59:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22454; Sun, 14 Jul 2002 10:43:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22407 for ; Sun, 14 Jul 2002 10:41:43 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07662 for ; Sun, 14 Jul 2002 10:40:48 -0400 (EDT) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6EEdcYH005710; Sun, 14 Jul 2002 10:39:58 -0400 (EDT) Message-ID: <3D318D1F.60603@dynamicsoft.com> Date: Sun, 14 Jul 2002 23:39:27 +0900 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kedar Patil CC: "'sip@ietf.org'" Subject: Re: [Sip] question on new offer in a dialog References: <4B9386E83999D411997100508BAF206A061F4FAB@stamail.telecom.sna.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Kedar Patil wrote: > Hi, > > Section 13.2.1 (Page 80) of RFC3261 says : > > ====================================================== > o After having sent or received an answer to the first offer, the > UAC MAY generate subsequent offers in requests based on rules > specified for that method, but only "if it has received answers > to any previous offers", AND "has not sent any offers to which it > hasn't gotten an answer". > ======================================================= > > The last two clauses (enclosed in double quotes) joined by "AND" > mean the same thing, Isn't it? Is there any hidden case in either > clause not covered by the other? I think this is a bug in the spec. The first clause should read "if it has sent answers to any previous offers". Thanks for catching it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sun Jul 14 11:02:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08371 for ; Sun, 14 Jul 2002 11:02:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23285 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 11:03:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22250; Sun, 14 Jul 2002 10:34:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22219 for ; Sun, 14 Jul 2002 10:34:26 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07522 for ; Sun, 14 Jul 2002 10:33:31 -0400 (EDT) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6EEXtYH005705; Sun, 14 Jul 2002 10:33:56 -0400 (EDT) Message-ID: <3D318BCA.5030106@dynamicsoft.com> Date: Sun, 14 Jul 2002 23:33:46 +0900 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sarvi Shanmugham CC: sip@ietf.org Subject: Re: [Sip] Out-of-Band DTMF Relay References: <3D2DCB5E.8C212C9F@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sarvi Shanmugham wrote: > Is there a draft or spec addressing how out-of-band DTMF relay should be > done in SIP. This remains an active item of discussion. There are several drafts, which include: http://search.ietf.org/internet-drafts/draft-rosenberg-sipping-markup-00.txt http://search.ietf.org/internet-drafts/draft-fairlie-sipping-netapp-session-00.txt http://search.ietf.org/internet-drafts/draft-culpepper-sip-key-events-01.txt Unfortunately, there are many proprietary implementations for this as well. > > Is there preference between the INFO message and a NOTIFY message to > carry this out-of-band DTMF between 2 SIP end-points. INFO is really bad. I think there is general agreement on that. It causes extra signaling even if no one cares, and is limite in scope to just DTMF. All of the above three drafts use some mechanism whereby a server asks the client for input, which is generally better. There is, of course, rfc2833, which is ideal for end-to-end DTMF, such as between gateways or between a PC and a gateway. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sun Jul 14 11:07:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08571 for ; Sun, 14 Jul 2002 11:07:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23343 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 11:08:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22581; Sun, 14 Jul 2002 10:49:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22550 for ; Sun, 14 Jul 2002 10:49:46 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07954 for ; Sun, 14 Jul 2002 10:48:50 -0400 (EDT) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6EEnCYH005713; Sun, 14 Jul 2002 10:49:14 -0400 (EDT) Message-ID: <3D318F5D.5040308@dynamicsoft.com> Date: Sun, 14 Jul 2002 23:49:01 +0900 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Questions on sip-guidelines References: <2038BCC78B1AD641891A0D1AE133DBB7C203E6@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > - Is defining a new sip-uri parameter considered to be an extension. Yes. > This also applies to headers that allow extension params. Yes. > If so, should > this be mentioned in the draft? Yes. Its mentioned up front that these are extensions, but there is no real dsicussion of it. I will add it. > > - Should the draft also mention something about registering new sip > headers, methods, option-tags with IANA? I think its worth mentioning, yes. > > - "Extensions that define new methods SHOULD use all capitals for the > method name". Why not a MUST? Because, technically, they can be lowercase. Its just that we haven't had any, historically. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sun Jul 14 11:32:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09371 for ; Sun, 14 Jul 2002 11:32:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24591 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 11:32:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23416; Sun, 14 Jul 2002 11:09:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23353 for ; Sun, 14 Jul 2002 11:09:13 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08600; Sun, 14 Jul 2002 11:08:16 -0400 (EDT) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6EF8YYH005721; Sun, 14 Jul 2002 11:08:38 -0400 (EDT) Message-ID: <3D3193E7.2070607@dynamicsoft.com> Date: Mon, 15 Jul 2002 00:08:23 +0900 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: Christer Holmberg , Gonzalo Camarillo , rohan@cisco.com, sip@ietf.org, sipping@ietf.org Subject: Re: [Sip] RE: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean Olson wrote: > Good point. Is this is a request or a demand by the client to re-use > the connection? I think we need the possibility for the client to > *demand* that the connection be re-used. There may also be situations > where re-use is just an optimization. Yes, I agree. My main reason for indicating that a connection MUST be reused is NATs. If I open a connection from my UA to the proxy through a NAT, I will only be able to receive incoming traffic on that connection. Therefore, reuse for incoming messages is a MUST, rather than just an optimiziation. Another way to think about this is that the alias is "scoped". In the case of mandatory reuse, the alias is only defined on the element to which the request was sent. I suppose this means that its the responsibility of that element to make sure that requests addressed to that alias by some other entity get routed to that element first. -Jonathan R. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, July 09, 2002 9:41 AM > To: Sean Olson; Gonzalo Camarillo; rohan@cisco.com; sip@ietf.org; > sipping@ietf.org > Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 > > > > Another comment, > > I also think it is important to remember that there MAY be scenarios, > especially if a connection is used for multiple sessions, where one > wants to use separate connections per each direction - even if the > client indicates he wants to use the same connection for the response. > Just to think of before the MUSTs are added... > > Regards, > > Christer Holmberg > Ericsson Finland > > > Christer Holmberg wrote: > > >>Hi Sean, >> >> >>>Is this really out of scope for this draft? Naturally >>>the more re-use you make of the connection, the more benefit you get >> > >>>from re-use ;-) >> >>Of course, but in that case it should be mentioned in the draft :) >> >>The only thing the draft currently talks about the problem how to make > > >>sure a single connection is used for both directions, per session - >>which is a separate issue from reusing connections for multiple >>sessions. >> >>And, since I don't think any draft currently talks about the reuse of >>connections for multiple sessions (bis talks about keeping the >>connection open to make sure the transaction uses the same >>transaction), maybe it could be added to the connect-reuse draft? >> >>Just some thoughts... >> >>Regards, >> >>Christer Holmberg >>Ericsson Finland >> >> >>> >>>/sean >>> >>>-----Original Message----- >>>From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >>>Sent: Tuesday, July 09, 2002 6:30 AM >>>To: Gonzalo Camarillo >>>Cc: Sean Olson; rohan@cisco.com; sip@ietf.org; sipping@ietf.org >>>Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 >>> >>>Hi, >>> >>>RFC3261/bis-9 mainly talks about using a single connection (or, one >>>in each >>>direction) for a single transaction, and the connect-reuse draft >>>talks about being able to use a single connection for messages in >>>both direction, for a single session. Sometimes, however, when we >>>talk about "reuse of connection" we mean when a single connection >>>(or, one in each >>>direction) is used for multiple sessions. I think it would be a good >>>idea to mention that that kind of "reuse" is out of the scope of the >>>draft. Otherwise the draft subject should more clear indicate what >> > kind > >>>of reuse it refers to... >>> >>>Of course, once a single connection is established, according to the >> > >>>connect-reuse draft, it MAY be used for multiple sessions, but >>>that's not the scope of the draft, so... >>> >>>Regards, >>> >>>Christer Holmberg >>>Ericsson Finland >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP Use >>sip-implementors@cs.columbia.edu for questions on current sip Use >>sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 14 19:12:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20387 for ; Sun, 14 Jul 2002 19:12:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06536 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 19:13:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10688; Sun, 14 Jul 2002 18:51:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10625 for ; Sun, 14 Jul 2002 18:50:55 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19723; Sun, 14 Jul 2002 18:49:58 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6EMoirU000652; Mon, 15 Jul 2002 00:50:45 +0200 (MEST) Received: from lmf.ericsson.se (jptowa1m46.ao.ericsson.se [150.236.214.111]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g6EMoaa9002284; Mon, 15 Jul 2002 01:50:38 +0300 (EET DST) Message-ID: <3D32004F.40F718E4@lmf.ericsson.se> Date: Mon, 15 Jul 2002 01:50:55 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Sean Olson , Gonzalo Camarillo , rohan@cisco.com, sip@ietf.org, sipping@ietf.org Subject: Re: [Sip] RE: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 References: <3D3193E7.2070607@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, We should also look from the other direction, and remember that node establishing the connection may also be a proxy forwarding an INVITE to a SIP UA, requiring the connection to be reused in both direction for the purpose of "saving" connections. Or, it may of course be a NAT. So, from that point of view it is good that the client can make the reuse "decission". However, I also think it is good if the called party, receiving the INVITE, can require the connection to be used. For example, a single-session SIP UA making a call may not care if it has to establish one or two connections. It may, however, send the INVITE to a proxy, and/or a NAT, which again does require the connection to be reused, so it should be able to do so. I also think it is important to have a look how the solution will affect the reuse of connections for multiple sessions (IF eg some extra parameters are needed for that, or if some clarifications are needed). Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > Sean Olson wrote: > > Good point. Is this is a request or a demand by the client to re-use > > the connection? I think we need the possibility for the client to > > *demand* that the connection be re-used. There may also be situations > > where re-use is just an optimization. > > Yes, I agree. > > My main reason for indicating that a connection MUST be reused is NATs. > If I open a connection from my UA to the proxy through a NAT, I will > only be able to receive incoming traffic on that connection. Therefore, > reuse for incoming messages is a MUST, rather than just an optimiziation. > > Another way to think about this is that the alias is "scoped". In the > case of mandatory reuse, the alias is only defined on the element to > which the request was sent. I suppose this means that its the > responsibility of that element to make sure that requests addressed to > that alias by some other entity get routed to that element first. > > -Jonathan R. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, July 09, 2002 9:41 AM > > To: Sean Olson; Gonzalo Camarillo; rohan@cisco.com; sip@ietf.org; > > sipping@ietf.org > > Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 > > > > > > > > Another comment, > > > > I also think it is important to remember that there MAY be scenarios, > > especially if a connection is used for multiple sessions, where one > > wants to use separate connections per each direction - even if the > > client indicates he wants to use the same connection for the response. > > Just to think of before the MUSTs are added... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > Christer Holmberg wrote: > > > > > >>Hi Sean, > >> > >> > >>>Is this really out of scope for this draft? Naturally > >>>the more re-use you make of the connection, the more benefit you get > >> > > > >>>from re-use ;-) > >> > >>Of course, but in that case it should be mentioned in the draft :) > >> > >>The only thing the draft currently talks about the problem how to make > > > > > >>sure a single connection is used for both directions, per session - > >>which is a separate issue from reusing connections for multiple > >>sessions. > >> > >>And, since I don't think any draft currently talks about the reuse of > >>connections for multiple sessions (bis talks about keeping the > >>connection open to make sure the transaction uses the same > >>transaction), maybe it could be added to the connect-reuse draft? > >> > >>Just some thoughts... > >> > >>Regards, > >> > >>Christer Holmberg > >>Ericsson Finland > >> > >> > >>> > >>>/sean > >>> > >>>-----Original Message----- > >>>From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > >>>Sent: Tuesday, July 09, 2002 6:30 AM > >>>To: Gonzalo Camarillo > >>>Cc: Sean Olson; rohan@cisco.com; sip@ietf.org; sipping@ietf.org > >>>Subject: Re: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00 > >>> > >>>Hi, > >>> > >>>RFC3261/bis-9 mainly talks about using a single connection (or, one > >>>in each > >>>direction) for a single transaction, and the connect-reuse draft > >>>talks about being able to use a single connection for messages in > >>>both direction, for a single session. Sometimes, however, when we > >>>talk about "reuse of connection" we mean when a single connection > >>>(or, one in each > >>>direction) is used for multiple sessions. I think it would be a good > >>>idea to mention that that kind of "reuse" is out of the scope of the > >>>draft. Otherwise the draft subject should more clear indicate what > >> > > kind > > > >>>of reuse it refers to... > >>> > >>>Of course, once a single connection is established, according to the > >> > > > >>>connect-reuse draft, it MAY be used for multiple sessions, but > >>>that's not the scope of the draft, so... > >>> > >>>Regards, > >>> > >>>Christer Holmberg > >>>Ericsson Finland > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP Use > >>sip-implementors@cs.columbia.edu for questions on current sip Use > >>sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 14 21:39:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24059 for ; Sun, 14 Jul 2002 21:39:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA07280 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 21:40:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06070; Sun, 14 Jul 2002 21:16:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06023 for ; Sun, 14 Jul 2002 21:15:59 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23350 for ; Sun, 14 Jul 2002 21:15:02 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com ([63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6F1F5tu029776; Sun, 14 Jul 2002 21:15:08 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YZ77Q8D>; Sun, 14 Jul 2002 20:15:20 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F44F@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Pete Cordell , Jonathan Rosenberg , Cullen Jennings Cc: sip@ietf.org Subject: RE: [Sip] Proposed change in draft-ietf-sip-nat Date: Sun, 14 Jul 2002 20:15:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Pete Cordell [mailto:pcordell@ridgewaysystems.com] > > So why not acknowledge the editorial error (which > requires no action) and move on. Wow. I never thought I'd see the day that the SIP Working Group mailing list devolved to the level of an old-fashioned Usenet-style spelling flame. Thanks, Pete. It's a first. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 14 21:40:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24086 for ; Sun, 14 Jul 2002 21:40:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA07311 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 21:40:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06021; Sun, 14 Jul 2002 21:15:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05987 for ; Sun, 14 Jul 2002 21:15:55 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23347 for ; Sun, 14 Jul 2002 21:14:58 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com ([63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6F1F5tt029776; Sun, 14 Jul 2002 21:15:06 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YZ77Q8C>; Sun, 14 Jul 2002 20:15:20 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F453@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: jh@lohi.eng.song.fi, "Peterson, Jon" Cc: Rohan Mahy , sip@ietf.org Subject: RE: [Sip] P- headers vs. requirements in sip change process Date: Sun, 14 Jul 2002 20:15:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Catching up on old mail... > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > also, nai is and in fact MUST be used also within a single > trust domain > if the user has specified anonymous from header and the > request goes to > a sip/pstn gw.. so the nai header is not just some "nice to know" > thing, but an integral part of the sip specification. Why? The user's identity can be ascertained from the credentials (the username, in particular) provided at authentication time. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 14 21:43:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24186 for ; Sun, 14 Jul 2002 21:43:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA07444 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 21:44:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05949; Sun, 14 Jul 2002 21:15:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05910 for ; Sun, 14 Jul 2002 21:15:44 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23335 for ; Sun, 14 Jul 2002 21:14:47 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com ([63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6F1Ettt029766; Sun, 14 Jul 2002 21:14:56 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YZ77Q70>; Sun, 14 Jul 2002 20:15:10 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F44B@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: hisham.khartabil@nokia.com, sip@ietf.org Subject: RE: [Sip] Questions on sip-guidelines Date: Sun, 14 Jul 2002 20:15:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > - Is defining a new sip-uri parameter considered to be an > extension. This also applies to headers that allow extension > params. Yes, these are extensions. In particular, just adding on your own made-up, private URI parameters runs the chances of colliding with someone else's made-up, private URI parameters (which almost certainly have different semantics than yours). So, you can't do that and still claim to be SIP compliant. You'll need to at least register the new parameters with IANA to avoid such collisions, and the tsvchange document would seem to indicate that doing so requires a SIP working group document. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jul 14 21:48:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24482 for ; Sun, 14 Jul 2002 21:48:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA07564 for sip-archive@odin.ietf.org; Sun, 14 Jul 2002 21:49:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05969; Sun, 14 Jul 2002 21:15:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05918 for ; Sun, 14 Jul 2002 21:15:45 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23338 for ; Sun, 14 Jul 2002 21:14:48 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com ([63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6F1Ettt029765; Sun, 14 Jul 2002 21:14:55 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YZ77Q79>; Sun, 14 Jul 2002 20:15:10 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F44C@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Sriram Parameswar , "'Adam Roach'" , "'Rosen, Brian'" , Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] REFER: Who has implemented REFER without creating subsc riptions? Date: Sun, 14 Jul 2002 20:15:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >-----Original Message----- >From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] > >I think there is definite value to having REFER without NOTIFYs. >There are several non transfer applications that benefit from >REFER, without having the overhead of the NOTIFY(s). In particular, this reasoning flies in the face of the principle of selecting "generality over efficiency" that has been established for the SIP protocol and its extensions. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 15 00:42:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00503 for ; Mon, 15 Jul 2002 00:42:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA17836 for sip-archive@odin.ietf.org; Mon, 15 Jul 2002 00:43:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16757; Mon, 15 Jul 2002 00:20:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16731 for ; Mon, 15 Jul 2002 00:20:18 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29830 for ; Mon, 15 Jul 2002 00:19:21 -0400 (EDT) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 17TxKy-0001p6-00; Mon, 15 Jul 2002 07:19:52 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15666.19816.758453.652133@lohi.eng.song.fi> Date: Mon, 15 Jul 2002 07:19:52 +0300 To: Adam Roach Cc: "Peterson, Jon" , Rohan Mahy , sip@ietf.org Subject: RE: [Sip] P- headers vs. requirements in sip change process In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F325F453@DYN-TX-EXCH-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F325F453@DYN-TX-EXCH-001.dynamicsoft.com> X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Adam Roach writes: > > also, nai is and in fact MUST be used also within a single > > trust domain > > if the user has specified anonymous from header and the > > request goes to > > a sip/pstn gw.. so the nai header is not just some "nice to know" > > thing, but an integral part of the sip specification. > > Why? The user's identity can be ascertained from the credentials > (the username, in particular) provided at authentication time. because one user may have many sip identities. this should have been clear based on several earlier emails about this topic. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 15 01:34:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02167 for ; Mon, 15 Jul 2002 01:34:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28297 for sip-archive@odin.ietf.org; Mon, 15 Jul 2002 01:34:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26768; Mon, 15 Jul 2002 01:15:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26706 for ; Mon, 15 Jul 2002 01:15:11 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01603 for ; Mon, 15 Jul 2002 01:14:14 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6F5EMt07245; Mon, 15 Jul 2002 00:14:22 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Jul 2002 00:14:07 -0500 Message-ID: From: "Sriram Parameswar" To: "'Adam Roach'" , "'Rosen, Brian'" , Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] REFER: Who has implemented REFER without creating subsc riptions? Date: Mon, 15 Jul 2002 00:14:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22BBE.6E6A0E20" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C22BBE.6E6A0E20 Content-Type: text/plain; charset="iso-8859-1" I am afraid I do not agree with the rather general statement you have made below. Implicit subscription created by REFER for all REFERs is does not rate as a generality. It is a special use of Implicit Subscriptions. There are applications that could 'refer' the recipient to a resource, but not care to receive a notification. Thx, Sriram -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Sunday, July 14, 2002 8:15 PM To: Parameswar, Sriram [NGC:B615:EXCH]; 'Adam Roach'; 'Rosen, Brian'; Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] REFER: Who has implemented REFER without creating subsc riptions? >-----Original Message----- >From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] > >I think there is definite value to having REFER without NOTIFYs. >There are several non transfer applications that benefit from >REFER, without having the overhead of the NOTIFY(s). In particular, this reasoning flies in the face of the principle of selecting "generality over efficiency" that has been established for the SIP protocol and its extensions. /a ------_=_NextPart_001_01C22BBE.6E6A0E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] REFER: Who has implemented REFER without creating = subsc riptions?

I am afraid I do not agree with the rather general = statement you have made below. Implicit subscription created by REFER = for all REFERs is does not rate as a generality. It is a special use of = Implicit Subscriptions. There are applications that could 'refer' the = recipient to a resource, but not care to receive a notification. =

Thx,

Sriram


-----Original Message-----
From: Adam Roach [mailto:adam@dynamicsoft.com]
Sent: Sunday, July 14, 2002 8:15 PM
To: Parameswar, Sriram [NGC:B615:EXCH]; 'Adam = Roach'; 'Rosen, Brian';
Robert Sparks
Cc: sip@ietf.org
Subject: RE: [Sip] REFER: Who has implemented REFER = without creating
subsc riptions?


>-----Original Message-----
>From: Sriram Parameswar [mailto:sriramp@nortelnetworks= .com]
>
>I think there is definite value to having REFER = without NOTIFYs.
>There are several non transfer applications that = benefit from
>REFER, without having the overhead of the = NOTIFY(s).

In particular, this reasoning flies in the face of = the principle
of selecting "generality over efficiency" = that has been established
for the SIP protocol and its extensions.

/a

------_=_NextPart_001_01C22BBE.6E6A0E20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 15 02:02:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05094 for ; Mon, 15 Jul 2002 02:02:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA29689 for sip-archive@odin.ietf.org; Mon, 15 Jul 2002 02:03:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28617; Mon, 15 Jul 2002 01:41:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28588 for ; Mon, 15 Jul 2002 01:41:40 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02407 for ; Mon, 15 Jul 2002 01:40:42 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6F5iMa24683; Mon, 15 Jul 2002 00:44:27 -0500 Subject: RE: [Sip] REFER: Who has implemented REFER without creating subsc riptions? From: Robert Sparks To: Sriram Parameswar Cc: "'Adam Roach'" , "'Rosen, Brian'" , sip@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 15 Jul 2002 14:39:51 +0900 Message-Id: <1026711599.1405.10.camel@ietf-wireless-dhcp-73-165> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Going with a mandatory creation of a subscription for the base REFER document really simplifies the spec and implementation of it. If you have an application that truly cannot stomach getting exactly one notify, I suggest we work out an extension later. Note that as a REFERor, if you don't care about the notifies, all you have to do is reject the first one. That terminates the subscription. If you are a REFERee and you don't want to deal with holding onto subscription state, send exactly one NOTIFY with a terminated subscription-state. RjS On Mon, 2002-07-15 at 14:14, Sriram Parameswar wrote: > I am afraid I do not agree with the rather general statement you have > made below. Implicit subscription created by REFER for all REFERs is > does not rate as a generality. It is a special use of Implicit > Subscriptions. There are applications that could 'refer' the recipient > to a resource, but not care to receive a notification. > > Thx, > > Sriram > > > -----Original Message----- > From: Adam Roach [ mailto:adam@dynamicsoft.com > ] > Sent: Sunday, July 14, 2002 8:15 PM > To: Parameswar, Sriram [NGC:B615:EXCH]; 'Adam Roach'; 'Rosen, Brian'; > Robert Sparks > Cc: sip@ietf.org > Subject: RE: [Sip] REFER: Who has implemented REFER without creating > subsc riptions? > > > >-----Original Message----- > >From: Sriram Parameswar [ mailto:sriramp@nortelnetworks.com > ] > > > >I think there is definite value to having REFER without NOTIFYs. > >There are several non transfer applications that benefit from > >REFER, without having the overhead of the NOTIFY(s). > > In particular, this reasoning flies in the face of the principle > of selecting "generality over efficiency" that has been established > for the SIP protocol and its extensions. > > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 15 02:18:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12702 for ; Mon, 15 Jul 2002 02:18:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA00447 for sip-archive@odin.ietf.org; Mon, 15 Jul 2002 02:19:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29029; Mon, 15 Jul 2002 01:55:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29000 for ; Mon, 15 Jul 2002 01:55:45 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03102 for ; Mon, 15 Jul 2002 01:54:33 -0400 (EDT) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g6F5sse27082 for ; Mon, 15 Jul 2002 11:24:54 +0530 (IST) Received: from blr-m1-bh2.wipro.com ([10.115.50.92]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GZA0F700.ND9; Mon, 15 Jul 2002 11:24:43 +0530 Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Jul 2002 11:24:43 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 15 Jul 2002 11:24:42 +0530 Message-ID: <860BFD79D602F0409BB9EEA42B9E3BC01235B4@blr-m1-msg.wipro.com> Thread-Topic: Unsubsccri Thread-Index: AcIhDqxUgsbBn5XgRv69zyvFP8BOsQKtjWJA From: "Shivaprasad Shivarudrappa" To: Cc: X-OriginalArrivalTime: 15 Jul 2002 05:54:43.0298 (UTC) FILETIME=[1DC74C20:01C22BC4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA29001 Subject: [Sip] Unsubsccri Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Monday, July 01, 2002 8:15 PM To: Mark Watson Cc: Alexeitsev, D; sip@ietf.org; Chris Hogg Subject: Re: [Sip] Local vs Remote ringback on 180 Hi Mark, > I'm confused by this discussion, because there seems to be a desire to > extrapolate some semantics about the *media* from a message which does > not contain SDP. Apologies if I have missed the issue at hand, or if > the following is obvious, but... > > The unify model means that media and session state are completely > independent, so, to talk about '180 with SDP' or '180 without SDP' > makes no sense. I agree, but those are the terms used by the drafts I've refered to. The ISUP/SIP mapping draft says that "180 with SDP" means that a remote ringback will be generated, and bis-09 says that "180 without SDP" MAY cause the UAC to generate a local ringback. Of course, those statements may sometimes be valid, if we receive either a 180 without SDP, OR we receive 180 with SDP - and no early dialog still exists. My orignial question was what we do if we receive 180 without SDP, but we DO have an early dialog established. It has been argued that the UAC should not generate local ringback in that case - instead assume the UAS does it since there is an early dialog established (if the UAS wants the UAC to generate local ringback it would have to put the media on hold using UPDATE). IF that's the case, I think it should me more clarified. Clarification is the only thing I've asked for - no changes in the protocol. > You can talk about the effect 180 has on the session state (indicates > that called party is being alerted), but this has nothing to do with > the media state (if there was media before, there still is, if there > was no media before, there still isn't). I've said all the time that the session state is not affected, only that the 180 affects what the application does with the media. So, what you just wrote means, that in the case we have an established early dialog it really doesn't matter, from a ringback point of view, if there is a SDP in the 180 or not. Is that the "official" clarification I've asked for? :) > You can talk about the effect that SDP offer/answer exchanges have on > the media, but this operates independently of the SIP message those > SDP bodies arrive in. True. That is why I also asked if the SDP is a good "ringback indicator" in the first place... > So, > > 1) the UAC knows whether there is media or not (based on SDP > offer/answer exchanges so far) > 2) if 180 has been received, the UAC knows that the called party is > alerting > > If the UAC knows that the called party is alerting AND knows that > there is media, it is a local matter what to do. Personally, I cannot > see an argument for doing anything other than playing the media (it > might contain 'ringing with call waiting announcement'). I think it was earlier said that the decission can't be based on if there is media or not. There may be RTP packets, but that doesn't mean they contain any "real" media. > A PROBLEM arises if there is a UAS which negotiates media but then > sends silence (no packets) - there ARE some reasons why it might want > to do this to do with reducing clipping on answer. The result is that > silence would be all the caller would hear even though the UAC may > know that the called party is being alerted. I think we just have to > say that it is foolish for the UAS to negotiate media and then send > silence - it should put the media on hold if it has nothing to send. Like I said earlier, that would probably not happend when the same server establishes the early dialog and sends the 180. I earlier gave an example where a B2BUA sends the announcement ("you have now reached the X company"), the contacts a SIP phone which sends 180 (the SIP phone does NOT generate early media). Now, the B2BUA gets the 180, stop playing the announcement, and forwards the 180 to the UAC. Now, since there are no more announcements, and the SIP phone doesn't generate remote ringback, and the UAC doesn't generate local ringback, there is no ringback at all. In this case the B2BUA would have to send UPDATE (media on hold), then forward the 180 (the UAC will now generate local ringback), and when the SIP phone answers it would have to send another UPDATE (media un-hold) and then forward the 200. An issue related to this I brought up earlier, is if the UAS will have to buffer the 200 until both UPDATE transactions have been completed. Any comments on that? Also, in a non-PRACK environment, is a 18x "allowed" to establish an early dialog in the first place? Bis-09 says that the answer must be sent in a reliable response, which is 200 OK. Yes, bis-09 DOES say that the answer MAY also be sent earlier, unreliably in a 18x, but when is the early dialog actually "officially" established? Again, the UAC could make a ringback decission based on if there is a SDP in the 180 or not, but a unreliably sent 180 may not even arrive... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 15 05:40:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19599 for ; Mon, 15 Jul 2002 05:40:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12958 for sip-archive@odin.ietf.org; Mon, 15 Jul 2002 05:41:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10572; Mon, 15 Jul 2002 05:09:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10541 for ; Mon, 15 Jul 2002 05:09:39 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18094 for ; Mon, 15 Jul 2002 05:08:43 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6F996Ra038544 for ; Mon, 15 Jul 2002 11:09:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6F995r121570 for ; Mon, 15 Jul 2002 11:09:06 +0200 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Avshalom Houri" Date: Mon, 15 Jul 2002 12:08:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 15/07/2002 12:09:05, Serialize complete at 15/07/2002 12:09:05 Content-Type: multipart/alternative; boundary="=_alternative 00323DDEC2256BF7_=" Subject: [Sip] The cost of UDP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multipart message in MIME format. --=_alternative 00323DDEC2256BF7_= Content-Type: text/plain; charset="us-ascii" Was caught in a middle of a row during the meeting and could not get to the microphone. Wanted to remark on the remark that UDP is less resource consuming then TCP and you can get more users on a machine with UDP. Well, it is very much dependent on your implementation. I have seen an implementation that can hold 20-30K users on a simple NT machine quite easily. Saying that UDP enable you to support more users is a bit misleading what happens is that you consume less system resources but you end up in consuming much more application resources since now you need to do what TCP does for you in the application level. Using TCP and TLS also goes with the lines of using existing protocols to solve problems and not having to solve these problems again and again in the applications. As can be understood, I am all for deprecating UDP while SIP is still young and it can be done. Regarding backward compatibility issues, I am not so worried about it. I am not aware of a very large SIP deployments that are used by millions of users currently. It will be relatively easy to modify proxies and servers to accept and initiate only TCP. Regarding clients, in the time frame that we are speaking about, 12-18 months, the clients can also be modified. Avshalom --=_alternative 00323DDEC2256BF7_= Content-Type: text/html; charset="us-ascii"
Was caught in a middle of a row during the meeting and could not get to the microphone.

Wanted to remark on the remark that UDP is less resource consuming then TCP and you can
get more users on a machine with UDP.

Well, it is very much dependent on your implementation. I have seen an implementation that can
hold 20-30K users on a simple NT machine quite easily. Saying that UDP enable you to support
more users is a bit misleading what happens is that you consume less system resources but you
end up in consuming much more application resources since now you need to do what TCP does
for you in the application level. Using TCP and TLS also goes with the lines of using existing
protocols to solve problems and not having to solve these problems again and again in the
applications.

As can be understood, I am all for deprecating UDP while SIP is still young and it can be done.
Regarding backward compatibility issues, I am not so worried about it. I am not aware of
a very large SIP deployments that are used by millions of users currently. It will be relatively
easy to modify proxies and servers to accept and initiate only TCP. Regarding clients, in the time frame that we
are speaking about, 12-18 months, the clients can also be modified.

Avshalom

--=_alternative 00323DDEC2256BF7_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 15 11:56:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09314 for ; Mon, 15 Jul 2002 11:56:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04149 for sip-archive@odin.ietf.org; Mon, 15 Jul 2002 11:57:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01263; Mon, 15 Jul 2002 11:11:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01232 for ; Mon, 15 Jul 2002 11:11:19 -0400 (EDT) Received: from tank.fr.ulticom.com (hide.fr.ulticom.com [213.244.28.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07645 for ; Mon, 15 Jul 2002 11:10:23 -0400 (EDT) Received: from PCGASTAUDL (pc-gastaud-l.fr.ulticom.com [172.26.32.87]) by tank.fr.ulticom.com (8.8.8+Sun/8.8.8) with SMTP id RAA20768 for ; Mon, 15 Jul 2002 17:10:47 +0200 (MET DST) From: "Valerie Gastaud" To: "Sip" Date: Mon, 15 Jul 2002 17:27:00 +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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP draft-bis-09 to RFC 3261 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Can someone tell me what are the (major) changes between 2543-bis09 and RFC 3261? Thanks, Valerie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 15 16:10:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15770 for ; Mon, 15 Jul 2002 16:10:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24834 for sip-archive@odin.ietf.org; Mon, 15 Jul 2002 16:11:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23772; Mon, 15 Jul 2002 15:45:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23741 for ; Mon, 15 Jul 2002 15:45:25 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15398 for ; Mon, 15 Jul 2002 15:44:26 -0400 (EDT) Received: from jku2.fokus.gmd.de (jku2.dyn.ietf54.wide.ad.jp [133.93.72.184]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g6FJhmC20231; Mon, 15 Jul 2002 21:43:49 +0200 Message-Id: <5.1.0.14.0.20020715211925.039c68c8@iptel.org> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 15 Jul 2002 21:22:22 +0200 To: "Valerie Gastaud" , "Sip" From: Jiri Kuthan Subject: Re: [Sip] SIP draft-bis-09 to RFC 3261 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org You may want to look at wdiff at iptel.org archive. http://www.iptel.org/info/players/ietf/callsignalling/draft-ietf-sip-rfc2543bis-09.txt.wdiff -Jiri At 05:27 PM 7/15/2002, Valerie Gastaud wrote: >Hi, >Can someone tell me what are the (major) changes between 2543-bis09 and RFC >3261? >Thanks, >Valerie > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 01:01:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29112 for ; Tue, 16 Jul 2002 01:01:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA22727 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 01:02:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21792; Tue, 16 Jul 2002 00:45:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21732 for ; Tue, 16 Jul 2002 00:45:36 -0400 (EDT) Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28687; Tue, 16 Jul 2002 00:44:34 -0400 (EDT) Received: from [10.10.13.95] (helo=ranjit) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 17UK8B-0000Lc-00; Tue, 16 Jul 2002 10:10:11 +0530 Message-ID: <015301c22c83$c0cb92e0$5f0d0a0a@ranjit> From: "Ranjit Avasarala" To: Cc: "sip-ietf" Date: Tue, 16 Jul 2002 10:16:30 +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 Content-Transfer-Encoding: 7bit Subject: [Sip] query on conference model Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi according to draft draft-ietf-sipping-service-examples-02.txt , user B sends INVITE to bridge to establish session. Now how do I differentiate this INVITE from the normal INVITE? I have this problem because my conference server is a combination of normal UAS, Registrar and conference server. Thanks In Advance Ranjit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 02:34:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11198 for ; Tue, 16 Jul 2002 02:34:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA05812 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 02:35:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03905; Tue, 16 Jul 2002 02:06:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03862 for ; Tue, 16 Jul 2002 02:06:00 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07367 for ; Tue, 16 Jul 2002 02:05:01 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id XAA15232 for ; Mon, 15 Jul 2002 23:05:57 -0700 (MST)] Received: [from nadhi.migv.mot.com ([217.2.42.15]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id XAA01224 for ; Mon, 15 Jul 2002 23:05:55 -0700 (MST)] Received: from golfmail.migv.mot.com (golfmail.migv.mot.com [217.2.42.13]) by migv.mot.com (8.9.3/8.9.3) with ESMTP id LAA25855 for ; Tue, 16 Jul 2002 11:40:19 +0530 (IST) Received: by golfmail.migv.mot.com with Internet Mail Service (5.5.2650.21) id <31LR0FQ3>; Tue, 16 Jul 2002 11:35:54 +0530 Message-ID: <195FE1D3531BD411A50F00B0D021783402907B89@golfmail.migv.mot.com> From: ABDUL SATTAR SHAIK To: "'sip@ietf.org'" Date: Tue, 16 Jul 2002 11:35:53 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22C8E.D79C93BA" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C22C8E.D79C93BA Content-Type: text/plain; charset="iso-8859-1" Hi what are the differences between rfc2543-bis-09 and rfc 3261? I didn't find a single difference in these two. I think the bis-09 is published as 3261 since bis-09 expires by august. AmI right ? Thanks abdul sattar ------_=_NextPart_001_01C22C8E.D79C93BA Content-Type: text/html; charset="iso-8859-1"

Hi
what are the differences between rfc2543-bis-09 and rfc 3261?

I  didn't find a single difference in these two.

I think the bis-09 is  published as 3261 since bis-09 expires by august.

AmI right ?

Thanks
abdul sattar


------_=_NextPart_001_01C22C8E.D79C93BA-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 03:32:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12586 for ; Tue, 16 Jul 2002 03:32:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09379 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 03:33:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07285; Tue, 16 Jul 2002 03:01:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07245 for ; Tue, 16 Jul 2002 03:01:18 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11874 for ; Tue, 16 Jul 2002 03:00:19 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6G70f325437; Tue, 16 Jul 2002 02:00:44 -0500 From: "Dean Willis" To: "'Avshalom Houri'" , Subject: RE: [Sip] The cost of UDP Date: Tue, 16 Jul 2002 02:00:36 -0500 Message-ID: <001301c22c96$7ee468d0$7e4d5d85@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Avshalom said: -------------- Wanted to remark on the remark that UDP is less resource consuming then TCP and you can get more users on a machine with UDP. Well, it is very much dependent on your implementation. I have seen an implementation that can hold 20-30K users on a simple NT machine quite easily. Saying that UDP enable you to support more users is a bit misleading what happens is that you consume less system resources but you end up in consuming much more application resources since now you need to do what TCP does for you in the application level. Using TCP and TLS also goes with the lines of using existing protocols to solve problems and not having to solve these problems again and again in the applications. --------------- The "TCP limit" is based on the fact that most sockets-based implementations of TCP use up one filesystem file handle per connected socket. Since most kernel limitations use an unsigned 16-bit index for the filehandle table, this puts a fairly hard upper bound of 64k connected sockets. Given that one is likely to need a few to support the OS and other applications, this makes a firm upper bound of around 64,000. Of course, many operating systems don't actually support this many, with many TCP implementations actually breakikng at a much smaller number, perhaps 16 or 256, but we're not likely to see commercial-grade proxy systems built on these systems. Of course, with connection-reuse in a proxy-proxy scenario, one socket might actually be supporting thousands of users. The real issue is on "boundary" proxies, where there is fan-in (or fan-out) to many UAs or small (residential?) proxies. What's the impact? Let's say we average one 7-message dialog sequence per hour per device. That's 7/messages per hour, or about 2 messages per second per 1,000 UA. With an average proxy capable of handling 1,000 messages per second, we should be able to handle 500,000 UA per proxy. That's clearly a larger number than 64k, so there IS a potential for fan in/out limitations being induced by TCP on larger servers. Of course, if one factors in presence and a little more traffic, it's not at all unreasoablle to expect more than 70 messages per hour per UA, which with this size proxy gets us CPU bound at around 50,000 clients, so the TCP constraint isn't binding. In other words, my analysis seems to indicate that for any "reasonable" model of proxy fanout that the TCP connected socket limitation is only to likely to impact really BIG proxy servers using a monolithic "mainframe" style architecture not common in today's distributed environments. In other words, it's just not much of a problem. Another aspect to consider is the "half open connection limit". There exists a constraint in many TCP implementations as to how many sockets may be in a connecting (not connected) state at any given time. Just a few years back, this number was something like 16 in a certain "robust commercial UNIX". I think it's commonly much larger now. This was highly problematic with HTTP 1.0 and it's very short-lived TCP connections, but our model of persistent TCP/TLS connections and connection reuse greatly reduce this liability. Consider that 50,000 client server. If every single TCP connection is broken and restored over the course of an hour, that gives us something like 5 half/open connections at any given time. If however every connection is restarted at exactly the same time, we DO have a bit more of a problem, so there may well be an issue in this regard. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 04:04:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13262 for ; Tue, 16 Jul 2002 04:04:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11551 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 04:05:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09998; Tue, 16 Jul 2002 03:44:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09970 for ; Tue, 16 Jul 2002 03:44:13 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12865 for ; Tue, 16 Jul 2002 03:43:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA16424; Tue, 16 Jul 2002 03:43:42 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA07498; Tue, 16 Jul 2002 03:43:42 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W98WC4G>; Tue, 16 Jul 2002 03:43:42 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B568D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'ABDUL SATTAR SHAIK'" , "'sip@ietf.org'" Subject: RE: [Sip] (no subject) Date: Tue, 16 Jul 2002 03:43:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22C9C.7E639150" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C22C9C.7E639150 Content-Type: text/plain; charset="iso-8859-1" There were a number of relatively small things fixed. For example, several ABNF errors were reported after bis-09 and before RFC3261 which were fixed. I believe we will provide a diff to highlight the changes. This is harder than you might think because the RFC editor completely redid the formatting, so creating a diff is not really easy. There are no actual protocol changes. Brian -----Original Message----- From: ABDUL SATTAR SHAIK [mailto:abdulss@migv.mot.com] Sent: Tuesday, July 16, 2002 2:06 AM To: 'sip@ietf.org' Subject: [Sip] (no subject) Hi what are the differences between rfc2543-bis-09 and rfc 3261? I didn't find a single difference in these two. I think the bis-09 is published as 3261 since bis-09 expires by august. AmI right ? Thanks abdul sattar ------_=_NextPart_001_01C22C9C.7E639150 Content-Type: text/html; charset="iso-8859-1"
There were a number of relatively small things fixed. 
For example, several ABNF errors were reported after bis-09
and before RFC3261 which were fixed.   I believe we will
provide a diff to highlight the changes.  This is harder than
you might think because the RFC editor completely redid the
formatting, so creating a diff is not really easy. 
 
There are no actual protocol changes.
 
Brian
-----Original Message-----
From: ABDUL SATTAR SHAIK [mailto:abdulss@migv.mot.com]
Sent: Tuesday, July 16, 2002 2:06 AM
To: 'sip@ietf.org'
Subject: [Sip] (no subject)

Hi
what are the differences between rfc2543-bis-09 and rfc 3261?

I  didn't find a single difference in these two.

I think the bis-09 is  published as 3261 since bis-09 expires by august.

AmI right ?

Thanks
abdul sattar


------_=_NextPart_001_01C22C9C.7E639150-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 05:45:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15307 for ; Tue, 16 Jul 2002 05:45:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA17169 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 05:46:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15657; Tue, 16 Jul 2002 05:23:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13460 for ; Tue, 16 Jul 2002 04:47:55 -0400 (EDT) Received: from saturn.aculab.com (mailhost.aculab.com [194.202.163.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14074; Tue, 16 Jul 2002 04:46:58 -0400 (EDT) From: Matthew.Gardiner@aculab.com Received: by saturn.aculab.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Jul 2002 09:43:16 +0100 Message-ID: <8C9A566C643ED6119E8900A0C9DE297A1AE0A5@saturn.aculab.com> To: sip@ietf.org, sipping@ietf.org Date: Tue, 16 Jul 2002 09:43:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] SIP call transfer as in draft-ietf-sipping-service-examples-02.tx t Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi All, A colleague and I are currently trying to design call transfer into a system and are therefore consulting draft-ietf-sipping-service-examples-02.txt to assist us. We are finding the example of "Attended transfer" a little confusing; we can understand messages F1 to F14, but we do not understand how message F15 is able to confer to user A any useful information. 1) At this stage user A has a call held (id=12345600@here.com) with user B, but the REFER (F15) message uses a new callid (12345678900@here.com). 2) Furthermore the REFER message itself does not seem to have any fields which relate to the held call at user A. If anyone understands how SIP call transfer is achieved, with regard to the "Attended transfer" example in draft-ietf-sipping-service-examples-02.txt, could they possibly send me an explanation? Thanks for your time, Matthew Gardiner Software Engineer Aculab Tel: +44 (0) 1908 273 911 Fax: +44 (0) 1908 273 801 Email: matthew.gardiner@aculab.com> Website: http://www.aculab.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 05:45:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15321 for ; Tue, 16 Jul 2002 05:45:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA17180 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 05:46:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15694; Tue, 16 Jul 2002 05:23:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13918 for ; Tue, 16 Jul 2002 04:55:17 -0400 (EDT) Received: from emily.fle.fujitsu.com ([193.122.18.249]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14259 for ; Tue, 16 Jul 2002 04:54:20 -0400 (EDT) From: h.chebbo@fle.fujitsu.com Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Tue, 16 Jul 2002 09:57:53 +0100 Received: by fle2.fleblue.fujitsu.com with Internet Mail Service (5.5.2655.55) id <3W2SFV0B>; Tue, 16 Jul 2002 09:58:13 +0100 Message-ID: <23A24554B6CB594F8F804A978F8CFB6A014C75@fle2.fleblue.fujitsu.com> To: sip@ietf.org Date: Tue, 16 Jul 2002 09:58:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-8f3bf36a-96fa-4943-a0d5-47ec28e9ff28" Subject: [Sip] SIP Processing power Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-8f3bf36a-96fa-4943-a0d5-47ec28e9ff28 Content-Type: text/plain; charset="iso-8859-1" Dear all How do you assess the processing power of SIP server ? Is it based on the categorisation of the actions carried out according to their complexities( simple,medium, complex) and then assigning a corresponding processing power. If so how you categorise an action as simple ,medium or complex. Comments and answers are very much appreciated. Regards ------=_NextPartTM-000-8f3bf36a-96fa-4943-a0d5-47ec28e9ff28 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and FLE. ------=_NextPartTM-000-8f3bf36a-96fa-4943-a0d5-47ec28e9ff28-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 05:52:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15431 for ; Tue, 16 Jul 2002 05:52:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA17390 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 05:53:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15745; Tue, 16 Jul 2002 05:23:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15563 for ; Tue, 16 Jul 2002 05:21:56 -0400 (EDT) Received: from tssg.wit.ie (tssg.wit.ie [193.1.185.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14805 for ; Tue, 16 Jul 2002 05:20:56 -0400 (EDT) Received: from boolard ([10.37.1.56]) by tssg.wit.ie (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g6G9L9V09342; Tue, 16 Jul 2002 10:21:11 +0100 From: "Shane McCormack" To: "Dean Willis" , "'Avshalom Houri'" , Subject: RE: [Sip] The cost of UDP Date: Tue, 16 Jul 2002 10:24:19 +0100 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <001301c22c96$7ee468d0$7e4d5d85@TXDWILLIS2> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Would SCTP solve any resource issues here? Shane -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Dean Willis Sent: 16 July 2002 08:01 To: 'Avshalom Houri'; sip@ietf.org Subject: RE: [Sip] The cost of UDP Avshalom said: -------------- Wanted to remark on the remark that UDP is less resource consuming then TCP and you can get more users on a machine with UDP. Well, it is very much dependent on your implementation. I have seen an implementation that can hold 20-30K users on a simple NT machine quite easily. Saying that UDP enable you to support more users is a bit misleading what happens is that you consume less system resources but you end up in consuming much more application resources since now you need to do what TCP does for you in the application level. Using TCP and TLS also goes with the lines of using existing protocols to solve problems and not having to solve these problems again and again in the applications. --------------- The "TCP limit" is based on the fact that most sockets-based implementations of TCP use up one filesystem file handle per connected socket. Since most kernel limitations use an unsigned 16-bit index for the filehandle table, this puts a fairly hard upper bound of 64k connected sockets. Given that one is likely to need a few to support the OS and other applications, this makes a firm upper bound of around 64,000. Of course, many operating systems don't actually support this many, with many TCP implementations actually breakikng at a much smaller number, perhaps 16 or 256, but we're not likely to see commercial-grade proxy systems built on these systems. Of course, with connection-reuse in a proxy-proxy scenario, one socket might actually be supporting thousands of users. The real issue is on "boundary" proxies, where there is fan-in (or fan-out) to many UAs or small (residential?) proxies. What's the impact? Let's say we average one 7-message dialog sequence per hour per device. That's 7/messages per hour, or about 2 messages per second per 1,000 UA. With an average proxy capable of handling 1,000 messages per second, we should be able to handle 500,000 UA per proxy. That's clearly a larger number than 64k, so there IS a potential for fan in/out limitations being induced by TCP on larger servers. Of course, if one factors in presence and a little more traffic, it's not at all unreasoablle to expect more than 70 messages per hour per UA, which with this size proxy gets us CPU bound at around 50,000 clients, so the TCP constraint isn't binding. In other words, my analysis seems to indicate that for any "reasonable" model of proxy fanout that the TCP connected socket limitation is only to likely to impact really BIG proxy servers using a monolithic "mainframe" style architecture not common in today's distributed environments. In other words, it's just not much of a problem. Another aspect to consider is the "half open connection limit". There exists a constraint in many TCP implementations as to how many sockets may be in a connecting (not connected) state at any given time. Just a few years back, this number was something like 16 in a certain "robust commercial UNIX". I think it's commonly much larger now. This was highly problematic with HTTP 1.0 and it's very short-lived TCP connections, but our model of persistent TCP/TLS connections and connection reuse greatly reduce this liability. Consider that 50,000 client server. If every single TCP connection is broken and restored over the course of an hour, that gives us something like 5 half/open connections at any given time. If however every connection is restarted at exactly the same time, we DO have a bit more of a problem, so there may well be an issue in this regard. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 08:47:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18642 for ; Tue, 16 Jul 2002 08:47:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25232 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 08:48:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23923; Tue, 16 Jul 2002 08:26:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23889 for ; Tue, 16 Jul 2002 08:25:58 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18272 for ; Tue, 16 Jul 2002 08:25:00 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6GCPswh006283; Tue, 16 Jul 2002 08:25:54 -0400 (EDT) Received: from cs.columbia.edu (ietf-terminal-dhcp-11-209.dyn.ietf54.wide.ad.jp [133.93.11.209]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6GCPoKM003905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Jul 2002 08:25:52 -0400 (EDT) Message-ID: <3D34109A.40304@cs.columbia.edu> Date: Tue, 16 Jul 2002 08:24:58 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Avshalom Houri'" , sip@ietf.org Subject: Re: [Sip] The cost of UDP References: <001301c22c96$7ee468d0$7e4d5d85@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The "reboot building" restart issue is something we probably need to do something about in any event. Using TCP to the outbound proxy compounds the problem that already exists due to the REGISTER flood. But maybe all the devices will be fighting for DHCP IP addresses and thus spread out the onrush. Dean Willis wrote: > Avshalom said: > -------------- > Wanted to remark on the remark that UDP is less resource consuming then > TCP and you can > get more users on a machine with UDP. > > Well, it is very much dependent on your implementation. I have seen an > implementation that can > hold 20-30K users on a simple NT machine quite easily. Saying that UDP > enable you to support > more users is a bit misleading what happens is that you consume less > system resources but you > end up in consuming much more application resources since now you need > to do what TCP does > for you in the application level. Using TCP and TLS also goes with the > lines of using existing > protocols to solve problems and not having to solve these problems again > and again in the > applications. > --------------- > > The "TCP limit" is based on the fact that most sockets-based > implementations of TCP use up one filesystem file handle per connected > socket. Since most kernel limitations use an unsigned 16-bit index for > the filehandle table, this puts a fairly hard upper bound of 64k > connected sockets. Given that one is likely to need a few to support the > OS and other applications, this makes a firm upper bound of around > 64,000. Of course, many operating systems don't actually support this > many, with many TCP implementations actually breakikng at a much smaller > number, perhaps 16 or 256, but we're not likely to see commercial-grade > proxy systems built on these systems. > > > Of course, with connection-reuse in a proxy-proxy scenario, one socket > might actually be supporting thousands of users. The real issue is on > "boundary" proxies, where there is fan-in (or fan-out) to many UAs or > small (residential?) proxies. > > What's the impact? > > Let's say we average one 7-message dialog sequence per hour per device. > That's 7/messages per hour, or about 2 messages per second per 1,000 UA. > With an average proxy capable of handling 1,000 messages per second, we > should be able to handle 500,000 UA per proxy. That's clearly a larger > number than 64k, so there IS a potential for fan in/out limitations > being induced by TCP on larger servers. Of course, if one factors in > presence and a little more traffic, it's not at all unreasoablle to > expect more than 70 messages per hour per UA, which with this size proxy > gets us CPU bound at around 50,000 clients, so the TCP constraint isn't > binding. > > In other words, my analysis seems to indicate that for any "reasonable" > model of proxy fanout that the TCP connected socket limitation is only > to likely to impact really BIG proxy servers using a monolithic > "mainframe" style architecture not common in today's distributed > environments. In other words, it's just not much of a problem. > > Another aspect to consider is the "half open connection limit". There > exists a constraint in many TCP implementations as to how many sockets > may be in a connecting (not connected) state at any given time. Just a > few years back, this number was something like 16 in a certain "robust > commercial UNIX". I think it's commonly much larger now. This was highly > problematic with HTTP 1.0 and it's very short-lived TCP connections, but > our model of persistent TCP/TLS connections and connection reuse greatly > reduce this liability. > > Consider that 50,000 client server. If every single TCP connection is > broken and restored over the course of an hour, that gives us something > like 5 half/open connections at any given time. If however every > connection is restarted at exactly the same time, we DO have a bit more > of a problem, so there may well be an issue in this regard. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 09:08:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19030 for ; Tue, 16 Jul 2002 09:08:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26570 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 09:09:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24964; Tue, 16 Jul 2002 08:43:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24934 for ; Tue, 16 Jul 2002 08:43:22 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18573 for ; Tue, 16 Jul 2002 08:42:24 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6GCgm327732; Tue, 16 Jul 2002 07:42:48 -0500 From: "Dean Willis" To: "'Shane McCormack'" , "'Avshalom Houri'" , Subject: RE: [Sip] The cost of UDP Date: Tue, 16 Jul 2002 07:42:39 -0500 Message-ID: <001001c22cc6$474a17a0$7e4d5d85@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Shane asked: > Hi, > Would SCTP solve any resource issues here? > > Shane I don't know that we have enough deployment experience to really say. Many people think so. A lot depends on the way that the SCTP library is actually implemented, and I personally haven't implemented one yet . . . Maybe somebody with implementation experience can say. Approaches that follow the TCP Berkeley-sockets model of file-handle allocation would presumably have the same problem. Other "raw socket" approaches might not. Of course, one COULD presumably do a TCP implementation that isn't file-handle bound, but I wouldn't recommend the one I did as a class project n-many years ago as a starting point. One place that SCTP should REALLY help is on optimizing high-volume server-server links. TCP in this role has this annoying "head of line blocking" quirk around retransmission of lost packets that SCTP fixes nicely. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 21:05:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05833 for ; Tue, 16 Jul 2002 21:05:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA04687 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 21:06:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01929; Tue, 16 Jul 2002 20:29:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01898 for ; Tue, 16 Jul 2002 20:29:40 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04733 for ; Tue, 16 Jul 2002 20:28:41 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6H0TXhZ011468; Tue, 16 Jul 2002 19:29:34 -0500 (CDT) Message-ID: <3D34BA62.5090908@dynamicsoft.com> Date: Tue, 16 Jul 2002 19:29:22 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: simple@mailman.dynamicsoft.com, "Vijay K. Gurbani" , "Sip@Ietf. Org" References: X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Simple] -05 MESSAGE and Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yes--this was pretty much the mood of the room in the SIMPLE wg meeting. It was also mentioned that this is a SIP draft, and any decisions must be made on the SIP list. (I am copying this message to SIP). So, my current plan is to leave it alone. If others disagree, please express that on the SIP list. Thanks! Ben. Cullen Jennings wrote: > To quote the honorable Mr. Sparks "leave it alone" > > I don't think that it is fundamentally broken (other than of course the lame > name). Priority is definitely not the right thing to use. I would vote for > just going with it as it is. > > Cullen > > > >>-----Original Message----- >>From: simple-admin@mailman.dynamicsoft.com >>[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Vijay K. >>Gurbani >>Sent: Tuesday, July 16, 2002 5:39 AM >>To: bcampbell@dynamicsoft.com >>Cc: simple@mailman.dynamicsoft.com >>Subject: [Simple] -05 MESSAGE and Expires header >> >> >>Ben: >> >>Any reasons why -05 MESSAGE I-D overloads "Expires: 0" to mean >>immediate attention. Maybe we can use "Priority: Urgent" instead; since >>the Priority header is defined in 3261 and "may be factored into >>decisions about call routing and acceptance". >> >>I think that overloading the Expires header here is confusing; 3261's >>use of "Expires: 0" in conjunction with REGISTER means something >>entirely different -- that this registration is invalid. From a >>semantic point of view, "Expires: 0" with REGISTER to mean >>deregistration appears to make sense; but "Expires: 0" with MESSAGE to >>mean immediate delivery appears incongrous. >> >>If it is not too late, maybe you can consider using the Priority header. >>I won't be able to make it to simple WG meeting tomorrow, so I just >>wanted to bring this to you attention. >> >>Thanks, >> >>- vijay >> >>_______________________________________________ >>simple mailing list >>simple@mailman.dynamicsoft.com >>http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 21:16:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06100 for ; Tue, 16 Jul 2002 21:16:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05192 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 21:17:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03712; Tue, 16 Jul 2002 20:56:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03662 for ; Tue, 16 Jul 2002 20:56:19 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05572 for ; Tue, 16 Jul 2002 20:55:21 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6H0tmM2025397; Tue, 16 Jul 2002 17:55:48 -0700 (PDT) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADL66091; Tue, 16 Jul 2002 17:56:03 -0700 (PDT) From: "Cullen Jennings" To: Cc: "'Avshalom Houri'" , "Dean Willis" Subject: RE: [Sip] The cost of UDP Date: Tue, 16 Jul 2002 17:55:47 -0700 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: <001301c22c96$7ee468d0$7e4d5d85@TXDWILLIS2> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Few thoughts on this .... 64,000 subscriber per host is not very many - people that are going to deploy millions of users don't want a boat load of servers to manage. 64,000 could correspond to around 50 cps. I can imagine proxies that easily do 500 cps on a cheap machine today and I can imagine proxies that do 30,000 cps on a $1000 machine 10 years from now. Perhaps no one will care about that level of performance but the point I am making is simple - 64,000 users per host is very low. If a host supported several IP address on a single interface, it might be able to do more than 64k TCP connections. Should work in theory but probably does not work in practice. The following scenario is quite realistic - We end up with a city with several million IP phones. This city regularly looses power resulting in all UA simultaneously rebooting and trying to register. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Dean > Willis > Sent: Tuesday, July 16, 2002 12:01 AM > To: 'Avshalom Houri'; sip@ietf.org > Subject: RE: [Sip] The cost of UDP > > > Avshalom said: > -------------- > Wanted to remark on the remark that UDP is less resource consuming then > TCP and you can > get more users on a machine with UDP. > > Well, it is very much dependent on your implementation. I have seen an > implementation that can > hold 20-30K users on a simple NT machine quite easily. Saying that UDP > enable you to support > more users is a bit misleading what happens is that you consume less > system resources but you > end up in consuming much more application resources since now you need > to do what TCP does > for you in the application level. Using TCP and TLS also goes with the > lines of using existing > protocols to solve problems and not having to solve these problems again > and again in the > applications. > --------------- > > The "TCP limit" is based on the fact that most sockets-based > implementations of TCP use up one filesystem file handle per connected > socket. Since most kernel limitations use an unsigned 16-bit index for > the filehandle table, this puts a fairly hard upper bound of 64k > connected sockets. Given that one is likely to need a few to support the > OS and other applications, this makes a firm upper bound of around > 64,000. Of course, many operating systems don't actually support this > many, with many TCP implementations actually breakikng at a much smaller > number, perhaps 16 or 256, but we're not likely to see commercial-grade > proxy systems built on these systems. > > > Of course, with connection-reuse in a proxy-proxy scenario, one socket > might actually be supporting thousands of users. The real issue is on > "boundary" proxies, where there is fan-in (or fan-out) to many UAs or > small (residential?) proxies. > > What's the impact? > > Let's say we average one 7-message dialog sequence per hour per device. > That's 7/messages per hour, or about 2 messages per second per 1,000 UA. > With an average proxy capable of handling 1,000 messages per second, we > should be able to handle 500,000 UA per proxy. That's clearly a larger > number than 64k, so there IS a potential for fan in/out limitations > being induced by TCP on larger servers. Of course, if one factors in > presence and a little more traffic, it's not at all unreasoablle to > expect more than 70 messages per hour per UA, which with this size proxy > gets us CPU bound at around 50,000 clients, so the TCP constraint isn't > binding. > > In other words, my analysis seems to indicate that for any "reasonable" > model of proxy fanout that the TCP connected socket limitation is only > to likely to impact really BIG proxy servers using a monolithic > "mainframe" style architecture not common in today's distributed > environments. In other words, it's just not much of a problem. > > Another aspect to consider is the "half open connection limit". There > exists a constraint in many TCP implementations as to how many sockets > may be in a connecting (not connected) state at any given time. Just a > few years back, this number was something like 16 in a certain "robust > commercial UNIX". I think it's commonly much larger now. This was highly > problematic with HTTP 1.0 and it's very short-lived TCP connections, but > our model of persistent TCP/TLS connections and connection reuse greatly > reduce this liability. > > Consider that 50,000 client server. If every single TCP connection is > broken and restored over the course of an hour, that gives us something > like 5 half/open connections at any given time. If however every > connection is restarted at exactly the same time, we DO have a bit more > of a problem, so there may well be an issue in this regard. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 22:01:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07898 for ; Tue, 16 Jul 2002 22:01:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA08718 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 22:02:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06258; Tue, 16 Jul 2002 21:35:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25417 for ; Tue, 16 Jul 2002 08:57:14 -0400 (EDT) Received: from tssg.wit.ie (tssg.wit.ie [193.1.185.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18801 for ; Tue, 16 Jul 2002 08:56:15 -0400 (EDT) Received: from boolard ([10.37.1.56]) by tssg.wit.ie (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g6GCuiV13995; Tue, 16 Jul 2002 13:56:44 +0100 From: "Shane McCormack" To: "Dean Willis" , "'Shane McCormack'" , "'Avshalom Houri'" , Subject: RE: [Sip] The cost of UDP Date: Tue, 16 Jul 2002 13:59:53 +0100 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <001001c22cc6$474a17a0$7e4d5d85@TXDWILLIS2> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree, I know Coritel university in Italy has done some SIP SCTP work using the lksctp open source linux kernel implementation of SCTP http://sourceforge.net/projects/lksctp and kphone/dissipate sip stack. http://www.wirlab.net/kphone/ Maybe some more research should be done? or is being done? Regards Shane -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: 16 July 2002 13:43 To: 'Shane McCormack'; 'Avshalom Houri'; sip@ietf.org Subject: RE: [Sip] The cost of UDP *This message was transferred with a trial version of CommuniGate(tm) Pro* Shane asked: > Hi, > Would SCTP solve any resource issues here? > > Shane I don't know that we have enough deployment experience to really say. Many people think so. A lot depends on the way that the SCTP library is actually implemented, and I personally haven't implemented one yet . . . Maybe somebody with implementation experience can say. Approaches that follow the TCP Berkeley-sockets model of file-handle allocation would presumably have the same problem. Other "raw socket" approaches might not. Of course, one COULD presumably do a TCP implementation that isn't file-handle bound, but I wouldn't recommend the one I did as a class project n-many years ago as a starting point. One place that SCTP should REALLY help is on optimizing high-volume server-server links. TCP in this role has this annoying "head of line blocking" quirk around retransmission of lost packets that SCTP fixes nicely. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 22:08:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08066 for ; Tue, 16 Jul 2002 22:08:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA09013 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 22:09:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06239; Tue, 16 Jul 2002 21:35:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16859 for ; Tue, 16 Jul 2002 05:42:27 -0400 (EDT) Received: from fw.tta.or.kr ([211.61.57.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15239 for ; Tue, 16 Jul 2002 05:41:29 -0400 (EDT) Message-ID: <022601c22cac$b9452a30$041b3dd3@LocalHost> From: =?ks_c_5601-1987?B?t/m09r+t?= To: Date: Tue, 16 Jul 2002 18:39:47 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0223_01C22CF8.2909B9D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Sip] Please, Give me the answer to "bis" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0223_01C22CF8.2909B9D0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciwgDQoNCkknbSBub3cgaW4gY2hhcmdlIG9mIHRlc3Rpbmcgb2YgVm9JUCBzeXN0ZW1zIGlu IFRUQSwgd2hpY2ggaXMgM3JkIHBhcnR5IHRlc3RpbmcgYXV0aG9yaXR5IGFib3V0IElUIGVxdWlw bWVudHMgaW4gS29yZWEuDQpXaGF0IEkgd2FudCB0byBrbm93IGlzIGp1c3QgYWJvdXQgdGhlIG1l YW5pbmcgb2YgImJpcyIgaW4gIlJGQyAyNTQzYmlzLTA5Ii4NCg0KU2lyLCBkbyB5b3UgaGFwcGVu IHRvIGtub3cgYWJvdXQgImJpcyI/IFBsZWFzZSBnaXZlIG1lIGEgaGFuZD8NCg0KSSdkIGxpa2Ug dG8gZ2V0IHRoZSBhbnN3ZXIgZnJvbSB5b3UgIDogQWJicmV2aWF0aW9uIG9mICJiaXMiIG9yIHRo ZSByZWFsIG1lYW5pbmcgb2YgImJpcyINCg0KIA0KWW91cnMgc2luY2VyZWx5IQ0KDQoNCg0KIA0K RHVrLXllbGwgWW9vDQpUZWwgOiArODItMzEtNzI0LTAxNjQNCmUtTWFpbCA6IHlvb2RsODdAdHRh Lm9yLmtyDQoNCkVuZ2luZWVyaW5nIFN0YWZmDQpPcGVuIFRlc3RiZWQgdGVhbQ0KTmV0d29yayBU ZXN0IENlbnRlcg0KSVQgVGVzdGluZyBMYWJvcmF0b3J5IA0KVFRBKFRlbGVjb21tdW5pY2F0aW9u cyBUZWNobm9sb2d5IEFzc29jaWF0aW9uKSwgUmVwdWJsaWMgb2YgS29yZWENCg== ------=_NextPart_000_0223_01C22CF8.2909B9D0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48Rk9O VCBzaXplPTI+DQo8RElWPjxGT05UIHNpemU9Mj5EZWFyLCA8L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSdtIG5vdyBpbiBjaGFyZ2Ugb2YgdGVzdGlu ZyBvZiBWb0lQIHN5c3RlbXMgaW4gVFRBLCB3aGljaCBpcyANCjNyZCBwYXJ0eSB0ZXN0aW5nIGF1 dGhvcml0eSZuYnNwO2Fib3V0IElUIGVxdWlwbWVudHMgaW4gS29yZWEuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+V2hhdCBJJm5ic3A7d2FudCB0byBrbm93IGlzIGp1c3QgYWJvdXQg dGhlIG1lYW5pbmcgb2YgImJpcyIgaW4gDQoiUkZDIDI1NDNiaXMtMDkiLjwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5TaXIsJm5ic3A7ZG8geW91IGhh cHBlbiB0byBrbm93PC9GT05UPiZuYnNwOzxGT05UIHNpemU9Mj5hYm91dCANCiJiaXMiPyBQbGVh c2UgZ2l2ZSBtZSBhIGhhbmQ/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPkknZCBsaWtlIHRvIGdldCB0aGUgYW5zd2VyIGZyb20geW91Jm5ic3A7IDog QWJicmV2aWF0aW9uIG9mIA0KImJpcyIgb3IgdGhlIHJlYWwgbWVhbmluZyBvZiAiYmlzIjwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Zb3VycyBzaW5jZXJlbHkhPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+RHVrLXllbGwgWW9vPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGVsIDogKzgy LTMxLTcyNC0wMTY0PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ZS1NYWlsIDogPEEg DQpocmVmPSJtYWlsdG86eW9vZGw4N0B0dGEub3Iua3IiPnlvb2RsODdAdHRhLm9yLmtyPC9BPjwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5FbmdpbmVl cmluZyZuYnNwO1N0YWZmPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+T3BlbiBUZXN0 YmVkIHRlYW08L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5OZXR3b3JrIFRlc3QgQ2Vu dGVyPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SVQgVGVzdGluZyBMYWJvcmF0b3J5 IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRUQShUZWxlY29tbXVuaWNhdGlvbnMg VGVjaG5vbG9neSBBc3NvY2lhdGlvbiksIFJlcHVibGljIG9mIA0KS29yZWE8L0ZPTlQ+PC9ESVY+ PC9GT05UPjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0223_01C22CF8.2909B9D0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 22:12:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08322 for ; Tue, 16 Jul 2002 22:12:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA09273 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 22:13:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06209; Tue, 16 Jul 2002 21:34:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18647 for ; Tue, 16 Jul 2002 06:20:03 -0400 (EDT) Received: from pub.isofttechindia.com ([203.199.202.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15901 for ; Tue, 16 Jul 2002 06:19:04 -0400 (EDT) Received: from isoft ([192.168.0.235]) by pub.isofttechindia.com (8.11.0/8.11.0) with SMTP id g6GAHSV27042 for ; Tue, 16 Jul 2002 15:47:28 +0530 From: "Sp.Raja" To: Date: Tue, 16 Jul 2002 15:55:36 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C22CE1.39DDDBE0" 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 V6.00.2600.0000 Subject: [Sip] CANCEL FAQs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C22CE1.39DDDBE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please help me out by answering these questions. 1. Can CANCEL be used to cancel a bye ? 2. Can CANCEL be send by the called entity (UAS) ? If yes then under what circumstances - Sp.Raja ------=_NextPart_000_0000_01C22CE1.39DDDBE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please = help me out=20 by answering these questions.
 
1. Can = CANCEL be=20 used to cancel a bye ?
 
2. Can = CANCEL be=20 send by the called entity (UAS) ? If yes then under what=20 circumstances
 
-=20 Sp.Raja
------=_NextPart_000_0000_01C22CE1.39DDDBE0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 23:56:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10834 for ; Tue, 16 Jul 2002 23:56:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA14729 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 23:57:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14186; Tue, 16 Jul 2002 23:36:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14157 for ; Tue, 16 Jul 2002 23:36:36 -0400 (EDT) Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10459 for ; Tue, 16 Jul 2002 23:35:39 -0400 (EDT) Received: from deewana (pool-138-88-38-74.res.east.verizon.net [138.88.38.74]) by tonnant.cnchost.com id XAA26933; Tue, 16 Jul 2002 23:36:35 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <003501c22d45$22511e10$0100000a@nextone.com> From: "Medhavi Bhatia" To: References: Subject: Re: [Sip] CANCEL FAQs Date: Tue, 16 Jul 2002 23:50:46 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This stuff generally belongs to the implementor's list: sip-implementors Generally CANCEL should not be used for transactions which are bound to complete quickly, and never for transactions for which you havent received a provisional (1xx) response. So the answer for (1) would be: probably not. Also the UAS cannot cancel a transaction started by the UAC (I guess that's what you meant), so it cannot generate the CANCEL ever. ----- Original Message ----- From: "Sp.Raja" To: Sent: Tuesday, July 16, 2002 6:25 AM Subject: [Sip] CANCEL FAQs > Please help me out by answering these questions. > > 1. Can CANCEL be used to cancel a bye ? > > 2. Can CANCEL be send by the called entity (UAS) ? If yes then under what > circumstances > > - Sp.Raja > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 16 23:56:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10849 for ; Tue, 16 Jul 2002 23:56:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA14758 for sip-archive@odin.ietf.org; Tue, 16 Jul 2002 23:57:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13045; Tue, 16 Jul 2002 23:20:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13016 for ; Tue, 16 Jul 2002 23:20:42 -0400 (EDT) Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10208 for ; Tue, 16 Jul 2002 23:19:45 -0400 (EDT) Received: from deewana (pool-138-88-38-74.res.east.verizon.net [138.88.38.74]) by tonnant.cnchost.com id XAA13235; Tue, 16 Jul 2002 23:20:37 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <001001c22d42$e7b00840$0100000a@nextone.com> From: "Medhavi Bhatia" To: =?utf-8?B?66WY642V7Je0?= , References: <022601c22cac$b9452a30$041b3dd3@LocalHost> Subject: Re: [Sip] Please, Give me the answer to "bis" Date: Tue, 16 Jul 2002 23:34:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit A second version ;) ----- Original Message ----- From: "류덕열" To: Sent: Tuesday, July 16, 2002 5:39 AM Subject: [Sip] Please, Give me the answer to "bis" > Dear, > > I'm now in charge of testing of VoIP systems in TTA, which is 3rd party testing authority about IT equipments in Korea. > What I want to know is just about the meaning of "bis" in "RFC 2543bis-09". > > Sir, do you happen to know about "bis"? Please give me a hand? > > I'd like to get the answer from you : Abbreviation of "bis" or the real meaning of "bis" > > > Yours sincerely! > > > > > Duk-yell Yoo > Tel : +82-31-724-0164 > e-Mail : yoodl87@tta.or.kr > > Engineering Staff > Open Testbed team > Network Test Center > IT Testing Laboratory > TTA(Telecommunications Technology Association), Republic of Korea > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 03:10:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08044 for ; Wed, 17 Jul 2002 03:10:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA17635 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 03:11:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15855; Wed, 17 Jul 2002 02:46:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15792 for ; Wed, 17 Jul 2002 02:45:55 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07373; Wed, 17 Jul 2002 02:44:58 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6H6jtwh029320; Wed, 17 Jul 2002 02:45:55 -0400 (EDT) Received: from cs.columbia.edu (cta.dyn.ietf54.wide.ad.jp [133.93.77.218]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6H6jmKM011938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Jul 2002 02:45:54 -0400 (EDT) Message-ID: <3D351268.9070501@cs.columbia.edu> Date: Wed, 17 Jul 2002 02:44:56 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Discussion meeting for hearing-impaired issues for SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Room 413, 17:30 - 18:30 Meeting is open; agenda is to identify concrete items that need to be done, based on the requirements document (and preferably identify candidate volunteers). Henning Schulzrinne _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 05:55:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11220 for ; Wed, 17 Jul 2002 05:55:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25917 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 05:56:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23897; Wed, 17 Jul 2002 05:04:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23868 for ; Wed, 17 Jul 2002 05:04:46 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10507 for ; Wed, 17 Jul 2002 05:03:47 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6H94fRb010385; Wed, 17 Jul 2002 11:04:41 +0200 (MEST) Received: from lmf.ericsson.se (jptowa1m04.ao.ericsson.se [150.236.214.69]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g6H94aa9018439; Wed, 17 Jul 2002 12:04:38 +0300 (EET DST) Message-ID: <3D353345.720BBBB9@lmf.ericsson.se> Date: Wed, 17 Jul 2002 12:05:09 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: jdrosen@dynamicsoft.com Subject: Re: [Sip] Anounce WGLC for draft-ietf-sip-callerpref References: <041401c2276c$d7e25200$eb036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a couple of small comments on the draft. Q1: My first comment (which I also gave a long time ago, when the first version of the draft was released): I think a usefull feature would be when a proxy modifies/inserts/removes caller preft, recieved in messages from a client (or another proxy). A UA may not know which preferences it's "allowed" to register/use, so the proxy (using whatever policy) could change those. The draft talks about "caller preferences vs CPL (or similar)" in proxies, but this feature could in many cases be a combination of those, since the proxy needs some kind of policy what/how/if to change in the caller preference headers of the received message. No, the draft really does NOT forbid proxies to do this, but I think it would show more usefulness of the draft if is was described in chapter 6.4 (unless chapter 6.3 is valid also for the "UAC part" of proxies). Q2: My second comment is about a caller prefs feature I've thought could be included: Would it be possible for a client to indicate if it supports (or, "wishes to receive") early media or not (note: this proposal is NOT to start the early vs local ringback discussion again!)? A forking proxy could eg set different values for different legs, to prevent early media mixing (the proxy is not allowed to change the media mode indicator to inactive in the SDP, so...) at the caller node. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 05:57:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11269 for ; Wed, 17 Jul 2002 05:57:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA26011 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 05:58:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24335; Wed, 17 Jul 2002 05:15:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24306 for ; Wed, 17 Jul 2002 05:15:50 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10686 for ; Wed, 17 Jul 2002 05:14:54 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6H9FE302265; Wed, 17 Jul 2002 04:15:14 -0500 From: "Dean Willis" To: "=?iso-8859-1?B?J7f5tPa/rSc=?=" , Subject: RE: [Sip] Please, Give me the answer to "bis" Date: Wed, 17 Jul 2002 04:15:00 -0500 Message-ID: <005001c22d72$6e91dd50$7e4d5d85@TXDWILLIS2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C22D48.85BBD550" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <022601c22cac$b9452a30$041b3dd3@LocalHost> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C22D48.85BBD550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Literally, German for the English word "to", but often meaning "between". One will see store hours posted in terms like "9 bis 18" It has been common in ITU to use the suffix "bis" on a specification to indicate an interim version for as long as I can remember. =20 -- Dean =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = =B7=F9=B4=F6=BF=AD Sent: Tuesday, July 16, 2002 4:40 AM To: sip@ietf.org Subject: [Sip] Please, Give me the answer to "bis" Dear,=20 =20 I'm now in charge of testing of VoIP systems in TTA, which is 3rd party testing authority about IT equipments in Korea. What I want to know is just about the meaning of "bis" in "RFC 2543bis-09". =20 Sir, do you happen to know about "bis"? Please give me a hand? =20 I'd like to get the answer from you : Abbreviation of "bis" or the real meaning of "bis" =20 =20 Yours sincerely! =20 =20 =20 =20 Duk-yell Yoo Tel : +82-31-724-0164 e-Mail : yoodl87@tta.or.kr =20 Engineering Staff Open Testbed team Network Test Center IT Testing Laboratory=20 TTA(Telecommunications Technology Association), Republic of Korea ------=_NextPart_000_0051_01C22D48.85BBD550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Literally, German for the English word "to", but often meaning = "between".=20 One will see store hours posted in terms like "9 bis 18" It has been = common in=20 ITU to use the suffix "bis" on a specification to indicate an = interim=20 version for as long as I can remember.
 
--
Dean
 
-----Original Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of=20 =B7=F9=B4=F6=BF­
Sent: Tuesday, July 16, 2002 4:40 = AM
To:=20 sip@ietf.org
Subject: [Sip] Please, Give me the answer to=20 "bis"

Dear,
 
I'm now in charge of testing of VoIP systems in = TTA, which=20 is 3rd party testing authority about IT equipments in = Korea.
What I want to know is just about the meaning = of "bis"=20 in "RFC 2543bis-09".
 
Sir, do you happen to know about "bis"? Please give me a hand?
 
I'd like to get the answer from you  : = Abbreviation of=20 "bis" or the real meaning of "bis"
 
 
Yours sincerely!
 
 
 
 
Duk-yell Yoo
Tel : +82-31-724-0164
e-Mail : yoodl87@tta.or.kr
 
Engineering Staff
Open Testbed team
Network Test Center
IT Testing Laboratory
TTA(Telecommunications Technology Association), = Republic of=20 = Korea
------=_NextPart_000_0051_01C22D48.85BBD550-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 06:01:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11317 for ; Wed, 17 Jul 2002 06:01:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26627 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 06:02:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24380; Wed, 17 Jul 2002 05:16:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24343 for ; Wed, 17 Jul 2002 05:15:57 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10688 for ; Wed, 17 Jul 2002 05:15:00 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6H9FG302268; Wed, 17 Jul 2002 04:15:16 -0500 From: "Dean Willis" To: "'Cullen Jennings'" , Cc: "'Avshalom Houri'" Subject: RE: [Sip] The cost of UDP Date: Wed, 17 Jul 2002 04:15:00 -0500 Message-ID: <005501c22d72$704cfad0$7e4d5d85@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > If a host supported several IP address on a single interface, > it might be able to do more than 64k TCP connections. Should > work in theory but probably does not work in practice. Nope. It is a kernel limitation on the number of file handles available, as I understand it. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 07:12:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12567 for ; Wed, 17 Jul 2002 07:11:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA29819 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 07:12:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27158; Wed, 17 Jul 2002 06:23:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27124 for ; Wed, 17 Jul 2002 06:23:19 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11576 for ; Wed, 17 Jul 2002 06:22:20 -0400 (EDT) From: duncan.mills@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id LAA08418; Wed, 17 Jul 2002 11:22:46 +0100 (BST) Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67]) by mailguard1 (4.6.1.91) with ESMTP id for ; Wed, 17 Jul 2002 11:23:35 +0100 Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 17 Jul 2002 11:23:05 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id <3GHYAGW2>; Wed, 17 Jul 2002 11:23:03 +0100 Message-Id: To: dean.willis@softarmor.com, yoodl87@tta.or.kr, sip@ietf.org Subject: RE: [Sip] Please, Give me the answer to "bis" Date: Wed, 17 Jul 2002 11:22:56 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22D7B.EF25D3FA" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C22D7B.EF25D3FA Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I thought... =20 'Bis' came from some latin or greek or something meaning 2nd. And Ter = means 3rd... =20 =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: 17 July 2002 10:15 To: '=B7=F9=B4=F6=BF=AD'; sip@ietf.org Subject: RE: [Sip] Please, Give me the answer to "bis" Literally, German for the English word "to", but often meaning = "between". One will see store hours posted in terms like "9 bis 18" It has been = common in ITU to use the suffix "bis" on a specification to indicate an = interim version for as long as I can remember. =20 -- Dean =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = =B7=F9=B4=F6=BF=AD Sent: Tuesday, July 16, 2002 4:40 AM To: sip@ietf.org Subject: [Sip] Please, Give me the answer to "bis" Dear,=20 =20 I'm now in charge of testing of VoIP systems in TTA, which is 3rd party testing authority about IT equipments in Korea. What I want to know is just about the meaning of "bis" in "RFC = 2543bis-09". =20 Sir, do you happen to know about "bis"? Please give me a hand? =20 I'd like to get the answer from you : Abbreviation of "bis" or the = real meaning of "bis" =20 =20 Yours sincerely! =20 =20 =20 =20 Duk-yell Yoo Tel : +82-31-724-0164 e-Mail : yoodl87@tta.or.kr =20 =20 Engineering Staff Open Testbed team Network Test Center IT Testing Laboratory=20 TTA(Telecommunications Technology Association), Republic of Korea ------_=_NextPart_001_01C22D7B.EF25D3FA Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Message
I=20 thought...
 
'Bis'=20 came from some latin or greek or something meaning 2nd.  And Ter = means=20 3rd...
 
 
-----Original Message-----
From: Dean Willis=20 [mailto:dean.willis@softarmor.com]
Sent: 17 July 2002=20 10:15
To: '=B7=F9=B4=F6=BF­'; = sip@ietf.org
Subject: RE: [Sip]=20 Please, Give me the answer to "bis"

Literally, German for the English word "to", but often = meaning=20 "between". One will see store hours posted in terms like "9 bis 18" = It has=20 been common in ITU to use the suffix "bis" on a specification to=20 indicate an interim version for as long as I can=20 remember.
 
--
Dean
 
-----Original Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of=20 =B7=F9=B4=F6=BF­
Sent: Tuesday, July 16, 2002 = 4:40 AM
To:=20 sip@ietf.org
Subject: [Sip] Please, Give me the answer to = "bis"

Dear,
 
I'm now in charge of testing of VoIP systems in = TTA, which=20 is 3rd party testing authority about IT equipments in=20 Korea.
What I want to know is just about the = meaning of=20 "bis" in "RFC 2543bis-09".
 
Sir, do you happen to = know about "bis"? Please give me a hand?
 
I'd like to get the answer from you  : = Abbreviation=20 of "bis" or the real meaning of "bis"
 
 
Yours sincerely!
 
 
 
 
Duk-yell Yoo
Tel : +82-31-724-0164
e-Mail : yoodl87@tta.or.kr
 
Engineering Staff
Open Testbed team
Network Test Center
IT Testing Laboratory
TTA(Telecommunications Technology Association), = Republic=20 of=20 Korea
------_=_NextPart_001_01C22D7B.EF25D3FA-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 07:22:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12863 for ; Wed, 17 Jul 2002 07:22:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA00367 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 07:23:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28333; Wed, 17 Jul 2002 06:44:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28302 for ; Wed, 17 Jul 2002 06:44:38 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11979 for ; Wed, 17 Jul 2002 06:43:40 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6HAiNwh016358; Wed, 17 Jul 2002 06:44:23 -0400 (EDT) Received: from cs.columbia.edu (cta.dyn.ietf54.wide.ad.jp [133.93.77.218]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6HAiFKM020940 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Jul 2002 06:44:17 -0400 (EDT) Message-ID: <3D354A4A.8080008@cs.columbia.edu> Date: Wed, 17 Jul 2002 06:43:22 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: duncan.mills@vf.vodafone.co.uk CC: dean.willis@softarmor.com, yoodl87@tta.or.kr, sip@ietf.org Subject: Re: [Sip] Please, Give me the answer to "bis" References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Merriam Webster says: Main Entry: bis Pronunciation: 'bis Function: adverb Etymology: Latin, from Old Latin dvis; akin to Old High German zwiro twice, Latin duo two -- more at TWO Main Entry: ter- Function: combining form Etymology: Latin, from ter; akin to Greek & Sanskrit tris three times, Latin tres three -- more at THREE : three times : threefold : three duncan.mills@vf.vodafone.co.uk wrote: > I thought... > > 'Bis' came from some latin or greek or something meaning 2nd. And Ter means > 3rd... > > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 17 July 2002 10:15 > To: 'ˇů´öż­'; sip@ietf.org > Subject: RE: [Sip] Please, Give me the answer to "bis" > > > Literally, German for the English word "to", but often meaning "between". > One will see store hours posted in terms like "9 bis 18" It has been common > in ITU to use the suffix "bis" on a specification to indicate an interim > version for as long as I can remember. > > -- > Dean > > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of ˇů´öż­ > Sent: Tuesday, July 16, 2002 4:40 AM > To: sip@ietf.org > Subject: [Sip] Please, Give me the answer to "bis" > > > > > Dear, > > I'm now in charge of testing of VoIP systems in TTA, which is 3rd party > testing authority about IT equipments in Korea. > What I want to know is just about the meaning of "bis" in "RFC 2543bis-09". > > Sir, do you happen to know about "bis"? Please give me a hand? > > I'd like to get the answer from you : Abbreviation of "bis" or the real > meaning of "bis" > > > Yours sincerely! > > > > > Duk-yell Yoo > Tel : +82-31-724-0164 > e-Mail : yoodl87@tta.or.kr > > Engineering Staff > Open Testbed team > Network Test Center > IT Testing Laboratory > TTA(Telecommunications Technology Association), Republic of Korea > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 09:46:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16344 for ; Wed, 17 Jul 2002 09:46:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10338 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 09:47:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05839; Wed, 17 Jul 2002 08:50:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05810 for ; Wed, 17 Jul 2002 08:50:20 -0400 (EDT) Received: from mailhost.baypackets.com (baypacket-114-139-del.baypackets.com [203.196.139.114] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14861 for ; Wed, 17 Jul 2002 08:49:18 -0400 (EDT) Received: from suresh (suresh [192.168.1.199]) by mailhost.baypackets.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12199; Wed, 17 Jul 2002 18:23:35 +0530 (IST) From: "Suresh Arora" To: "Medhavi Bhatia" , Subject: RE: [Sip] CANCEL FAQs Date: Wed, 17 Jul 2002 18:14:33 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <003501c22d45$22511e10$0100000a@nextone.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think UAS can send CANCEL to UAC for a re-INVITE (if requested session characteristics are not supported by Server). -Suresh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Medhavi Bhatia Sent: Wednesday, July 17, 2002 9:21 AM To: sip@ietf.org Subject: Re: [Sip] CANCEL FAQs This stuff generally belongs to the implementor's list: sip-implementors Generally CANCEL should not be used for transactions which are bound to complete quickly, and never for transactions for which you havent received a provisional (1xx) response. So the answer for (1) would be: probably not. Also the UAS cannot cancel a transaction started by the UAC (I guess that's what you meant), so it cannot generate the CANCEL ever. ----- Original Message ----- From: "Sp.Raja" To: Sent: Tuesday, July 16, 2002 6:25 AM Subject: [Sip] CANCEL FAQs > Please help me out by answering these questions. > > 1. Can CANCEL be used to cancel a bye ? > > 2. Can CANCEL be send by the called entity (UAS) ? If yes then under what > circumstances > > - Sp.Raja > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 10:26:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17606 for ; Wed, 17 Jul 2002 10:26:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13471 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 10:27:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09356; Wed, 17 Jul 2002 09:32:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09326 for ; Wed, 17 Jul 2002 09:32:27 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16048 for ; Wed, 17 Jul 2002 09:31:27 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sip@ietf.org; Wed, 17 Jul 2002 15:31:10 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 15:31:53 +0200 Message-Id: From: "Alexeitsev, D" To: sip@ietf.org Date: Wed, 17 Jul 2002 15:31:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Dialog independent session control response Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello All The UPDATE method was defined for the dialog independent control of the session. Would it not be necessary to define an equivalent provisional response, that would allow to control the session without impacting the dialog state? As currently the 183 response is widely used for this proposes and it's actually not clean in terms of call and bearer control separation. Greeting, Denis Alexeitsev _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 12:24:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21589 for ; Wed, 17 Jul 2002 12:24:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01470 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 12:25:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18681; Wed, 17 Jul 2002 11:55:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18638 for ; Wed, 17 Jul 2002 11:55:24 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19775 for ; Wed, 17 Jul 2002 11:54:28 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6HFsoOu013966; Wed, 17 Jul 2002 08:54:50 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE13425; Wed, 17 Jul 2002 08:50:19 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA01050; Wed, 17 Jul 2002 08:54:53 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15669.37709.46298.601697@thomasm-u1.cisco.com> Date: Wed, 17 Jul 2002 08:54:53 -0700 (PDT) To: "Dean Willis" Cc: "'Cullen Jennings'" , , "'Avshalom Houri'" Subject: RE: [Sip] The cost of UDP In-Reply-To: <005501c22d72$704cfad0$7e4d5d85@TXDWILLIS2> References: <005501c22d72$704cfad0$7e4d5d85@TXDWILLIS2> 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! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > > If a host supported several IP address on a single interface, > > it might be able to do more than 64k TCP connections. Should > > work in theory but probably does not work in practice. > > Nope. It is a kernel limitation on the number of file handles available, > as I understand it. This doesn't really strike me as a reason to avoid something. It may be crufty to change, but there is nothing sacrosanct about 16 bit file handles. There are *lots* of services where you'd like to pile as many occassional users as possible onto the server. IM comes to mind here too. That said, I think that this entire discussion is somewhat missing the point: how does post dial delay fare with all things considered (e2e, qos, security) with TCP and UDP? A self-contained signed UDP exchange (kerberos, SMIME...) would take 2 messages (invite/response). The equivalent with TCP and TLS would take 10 messages (3, 5, 2). This is in the realm of IKE la-la land. It's probably even gnarlier with QoS preconditions. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 17 18:15:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01170 for ; Wed, 17 Jul 2002 18:15:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04377 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 18:16:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03310; Wed, 17 Jul 2002 17:45:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03279 for ; Wed, 17 Jul 2002 17:45:26 -0400 (EDT) Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00591 for ; Wed, 17 Jul 2002 17:44:27 -0400 (EDT) Received: from deewana (pool-138-88-43-198.res.east.verizon.net [138.88.43.198]) by devonshire.cnchost.com id RAA23354; Wed, 17 Jul 2002 17:45:16 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <012701c22ddd$3554d6d0$0100000a@nextone.com> From: "Medhavi Bhatia" To: "Michael Thomas" , "Dean Willis" Cc: "'Cullen Jennings'" , , "'Avshalom Houri'" References: <005501c22d72$704cfad0$7e4d5d85@TXDWILLIS2> <15669.37709.46298.601697@thomasm-u1.cisco.com> Subject: Re: [Sip] The cost of UDP Date: Wed, 17 Jul 2002 17:59:21 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I dont think it comes from file descriptors. There are several packages out there, which keep on stretching this limit. Moreover I assume one file descriptors will be 64 bits. I think its the TCP port size in the protocol, 16 bits. ----- Original Message ----- From: "Michael Thomas" To: "Dean Willis" Cc: "'Cullen Jennings'" ; ; "'Avshalom Houri'" Sent: Wednesday, July 17, 2002 11:54 AM Subject: RE: [Sip] The cost of UDP > Dean Willis writes: > > > If a host supported several IP address on a single interface, > > > it might be able to do more than 64k TCP connections. Should > > > work in theory but probably does not work in practice. > > > > Nope. It is a kernel limitation on the number of file handles available, > > as I understand it. > > This doesn't really strike me as a reason to avoid > something. It may be crufty to change, but there > is nothing sacrosanct about 16 bit file > handles. There are *lots* of services where you'd > like to pile as many occassional users as possible > onto the server. IM comes to mind here too. > > That said, I think that this entire discussion is > somewhat missing the point: how does post dial > delay fare with all things considered (e2e, qos, > security) with TCP and UDP? A self-contained > signed UDP exchange (kerberos, SMIME...) would > take 2 messages (invite/response). The equivalent > with TCP and TLS would take 10 messages (3, 5, 2). > This is in the realm of IKE la-la land. It's > probably even gnarlier with QoS preconditions. > > Mike > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 17 21:08:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05137 for ; Wed, 17 Jul 2002 21:08:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA13823 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 21:09:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA11436; Wed, 17 Jul 2002 20:42:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA11405 for ; Wed, 17 Jul 2002 20:42:45 -0400 (EDT) Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04120 for ; Wed, 17 Jul 2002 20:41:44 -0400 (EDT) Received: from deewana (pool-138-88-43-198.res.east.verizon.net [138.88.43.198]) by devonshire.cnchost.com id UAA26159; Wed, 17 Jul 2002 20:42:25 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <015401c22df5$f39ff8a0$0100000a@nextone.com> From: "Medhavi Bhatia" To: "Michael Thomas" , "Dean Willis" , "Jiri Kuthan" Cc: "'Cullen Jennings'" , , "'Avshalom Houri'" References: <005501c22d72$704cfad0$7e4d5d85@TXDWILLIS2> <15669.37709.46298.601697@thomasm-u1.cisco.com> <5.1.0.14.0.20020718004818.023552a0@iptel.org> Subject: Re: [Sip] The cost of UDP Date: Wed, 17 Jul 2002 20:56:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Several systems store the 32 bit descriptor in a 16 bit quantity, like the sfio package from AT&T. My thinking is that all these limits still come from the idea of ports used in udp/tcp. ----- Original Message ----- From: "Jiri Kuthan" To: "Medhavi Bhatia" ; "Michael Thomas" ; "Dean Willis" Cc: "'Cullen Jennings'" ; ; "'Avshalom Houri'" Sent: Wednesday, July 17, 2002 6:49 PM Subject: Re: [Sip] The cost of UDP > TCP connections in operating systems I know are identified by > quad-tupel {src_ip, dst_ip, src_port, dst_port}. Many more bits > than just 16. If an operating system has 64k limitation on > number of open TCP, than it is an implementation choice. > > -Jiri > > At 11:59 PM 7/17/2002, Medhavi Bhatia wrote: > >I dont think it comes from file descriptors. There are > >several packages out there, which keep on stretching this limit. > >Moreover I assume one file descriptors will be 64 bits. > > > >I think its the TCP port size in the protocol, 16 bits. > > > >----- Original Message ----- > >From: "Michael Thomas" > >To: "Dean Willis" > >Cc: "'Cullen Jennings'" ; ; "'Avshalom > >Houri'" > >Sent: Wednesday, July 17, 2002 11:54 AM > >Subject: RE: [Sip] The cost of UDP > > > > > >> Dean Willis writes: > >> > > If a host supported several IP address on a single interface, > >> > > it might be able to do more than 64k TCP connections. Should > >> > > work in theory but probably does not work in practice. > >> > > >> > Nope. It is a kernel limitation on the number of file handles > >available, > >> > as I understand it. > >> > >> This doesn't really strike me as a reason to avoid > >> something. It may be crufty to change, but there > >> is nothing sacrosanct about 16 bit file > >> handles. There are *lots* of services where you'd > >> like to pile as many occassional users as possible > >> onto the server. IM comes to mind here too. > >> > >> That said, I think that this entire discussion is > >> somewhat missing the point: how does post dial > >> delay fare with all things considered (e2e, qos, > >> security) with TCP and UDP? A self-contained > >> signed UDP exchange (kerberos, SMIME...) would > >> take 2 messages (invite/response). The equivalent > >> with TCP and TLS would take 10 messages (3, 5, 2). > >> This is in the realm of IKE la-la land. It's > >> probably even gnarlier with QoS preconditions. > >> > >> Mike > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 17 21:19:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05378 for ; Wed, 17 Jul 2002 21:19:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14291 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 21:20:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12036; Wed, 17 Jul 2002 20:51:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12005 for ; Wed, 17 Jul 2002 20:50:59 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04519 for ; Wed, 17 Jul 2002 20:50:02 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6I0oqwh029610; Wed, 17 Jul 2002 20:50:52 -0400 (EDT) Received: from cs.columbia.edu (cta.dyn.ietf54.wide.ad.jp [133.93.77.218]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6I0okKM021894 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Jul 2002 20:50:48 -0400 (EDT) Message-ID: <3D3610B0.5090307@cs.columbia.edu> Date: Wed, 17 Jul 2002 20:49:52 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Medhavi Bhatia CC: Michael Thomas , Dean Willis , Jiri Kuthan , "'Cullen Jennings'" , sip@ietf.org, "'Avshalom Houri'" Subject: Re: [Sip] The cost of UDP References: <005501c22d72$704cfad0$7e4d5d85@TXDWILLIS2> <15669.37709.46298.601697@thomasm-u1.cisco.com> <5.1.0.14.0.20020718004818.023552a0@iptel.org> <015401c22df5$f39ff8a0$0100000a@nextone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just in case there is confusion: The port limitation does not limit the number of concurrent connections. A TCP connection is identified by four quantities: source/destination port, source/destination address. Thus, there's no limit imposed by 16-bit ports unless you count the uninteresting case where all such connections go to the same destination address. Medhavi Bhatia wrote: > Several systems store the 32 bit descriptor in > a 16 bit quantity, like the sfio package from AT&T. > > My thinking is that all these limits still come from the idea > of ports used in udp/tcp. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 17 22:03:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06830 for ; Wed, 17 Jul 2002 22:03:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA17348 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 22:04:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14679; Wed, 17 Jul 2002 21:26:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06566 for ; Wed, 17 Jul 2002 19:16:14 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02150 for ; Wed, 17 Jul 2002 19:15:17 -0400 (EDT) Received: from jku2.iptel.org (jku2.dyn.ietf54.wide.ad.jp [133.93.72.184]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g6HNFCH29507; Thu, 18 Jul 2002 01:15:13 +0200 Message-Id: <5.1.0.14.0.20020718004818.023552a0@iptel.org> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 18 Jul 2002 00:49:56 +0200 To: "Medhavi Bhatia" , "Michael Thomas" , "Dean Willis" From: Jiri Kuthan Subject: Re: [Sip] The cost of UDP Cc: "'Cullen Jennings'" , , "'Avshalom Houri'" In-Reply-To: <012701c22ddd$3554d6d0$0100000a@nextone.com> References: <005501c22d72$704cfad0$7e4d5d85@TXDWILLIS2> <15669.37709.46298.601697@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org TCP connections in operating systems I know are identified by quad-tupel {src_ip, dst_ip, src_port, dst_port}. Many more bits than just 16. If an operating system has 64k limitation on number of open TCP, than it is an implementation choice. -Jiri At 11:59 PM 7/17/2002, Medhavi Bhatia wrote: >I dont think it comes from file descriptors. There are >several packages out there, which keep on stretching this limit. >Moreover I assume one file descriptors will be 64 bits. > >I think its the TCP port size in the protocol, 16 bits. > >----- Original Message ----- >From: "Michael Thomas" >To: "Dean Willis" >Cc: "'Cullen Jennings'" ; ; "'Avshalom >Houri'" >Sent: Wednesday, July 17, 2002 11:54 AM >Subject: RE: [Sip] The cost of UDP > > >> Dean Willis writes: >> > > If a host supported several IP address on a single interface, >> > > it might be able to do more than 64k TCP connections. Should >> > > work in theory but probably does not work in practice. >> > >> > Nope. It is a kernel limitation on the number of file handles >available, >> > as I understand it. >> >> This doesn't really strike me as a reason to avoid >> something. It may be crufty to change, but there >> is nothing sacrosanct about 16 bit file >> handles. There are *lots* of services where you'd >> like to pile as many occassional users as possible >> onto the server. IM comes to mind here too. >> >> That said, I think that this entire discussion is >> somewhat missing the point: how does post dial >> delay fare with all things considered (e2e, qos, >> security) with TCP and UDP? A self-contained >> signed UDP exchange (kerberos, SMIME...) would >> take 2 messages (invite/response). The equivalent >> with TCP and TLS would take 10 messages (3, 5, 2). >> This is in the realm of IKE la-la land. It's >> probably even gnarlier with QoS preconditions. >> >> Mike >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 17 22:04:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06857 for ; Wed, 17 Jul 2002 22:04:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA17404 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 22:05:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15778; Wed, 17 Jul 2002 21:39:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15739 for ; Wed, 17 Jul 2002 21:39:28 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05902 for ; Wed, 17 Jul 2002 21:38:29 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6I1ck308068; Wed, 17 Jul 2002 20:38:47 -0500 From: "Dean Willis" To: "'Michael Thomas'" Cc: "'Cullen Jennings'" , , "'Avshalom Houri'" Subject: RE: [Sip] The cost of UDP Date: Wed, 17 Jul 2002 20:38:31 -0500 Message-ID: <006301c22dfb$d3f11ab0$7e4d5d85@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <15669.37709.46298.601697@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > That said, I think that this entire discussion is > somewhat missing the point: how does post dial > delay fare with all things considered (e2e, qos, > security) with TCP and UDP? A self-contained > signed UDP exchange (kerberos, SMIME...) would > take 2 messages (invite/response). The equivalent > with TCP and TLS would take 10 messages (3, 5, 2). > This is in the realm of IKE la-la land. It's > probably even gnarlier with QoS preconditions. Well, there is a little issue with fragmentation, so while only two MESSAGES might be required, it could well be many PACKETS. And given any probability of loss, a retry of an entire message occurs, many many more packets. And of course there is always the unstated issue of key management -- somewhere in there you also have to take into account the talking to the ticket server and so on. But Mike has a real point here -- the reality is much messier than the simplfied models that often get discussed, and we probably do need to make a habit of looking at a lot of these issues in more detail. In my experience, proper security of any kind is non-trivial and often considered prohibitively expensive. I believe this accounts for the generally poor level of security we find in the real world. In other words, experience dictates that some things may be worth doing, but NOT doing right. Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jul 17 22:07:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06887 for ; Wed, 17 Jul 2002 22:07:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA17464 for sip-archive@odin.ietf.org; Wed, 17 Jul 2002 22:08:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14669; Wed, 17 Jul 2002 21:26:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13755 for ; Wed, 17 Jul 2002 13:07:29 -0400 (EDT) Received: from stamail.telecom.sna.samsung.com (mail1.sta.samsung.com [63.166.115.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23477 for ; Wed, 17 Jul 2002 13:06:32 -0400 (EDT) Received: by stamail.telecom.sna.samsung.com with Internet Mail Service (5.5.2653.19) id <37042T2F>; Wed, 17 Jul 2002 12:11:32 -0500 Message-ID: <4B9386E83999D411997100508BAF206A061F4FBE@stamail.telecom.sna.samsung.com> From: Kedar Patil To: "'Sp.Raja'" Cc: sip@ietf.org Subject: RE: [Sip] CANCEL FAQs Date: Wed, 17 Jul 2002 12:11:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DB4.F980B480" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C22DB4.F980B480 Content-Type: text/plain; charset="iso-8859-1" Hi, (1) RFC 3261, section 9.1 : ================================================================= A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. ========================================================== and ================================================================= If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. ================================================================= Practically, even if you send CANCEL to BYE, 3 possibilities exist - - if it reaches before BYE, it will be rejected with 481. - if it reaches after BYE, UAS will process BYE first, i.e. it will send final resp. to BYE first, then process CANCEL, which will rejected with 481. - if CANCEL to BYE is received by a stateful proxy server, it is a race condition. ( I guess it can be so even with CANCEL to INVITE via a stateful proxy, is it?). (2) Any UA that initiates a request is a UAC. Now if called UA initiates INVITE (actually re-INVITE), then it should be able to CANCEL it too. thanks, = Kedar = -----Original Message----- From: Sp.Raja [mailto:spraja@isofttechindia.com] Sent: Tuesday, July 16, 2002 5:26 AM To: sip@ietf.org Subject: [Sip] CANCEL FAQs Please help me out by answering these questions. 1. Can CANCEL be used to cancel a bye ? 2. Can CANCEL be send by the called entity (UAS) ? If yes then under what circumstances - Sp.Raja ------_=_NextPart_001_01C22DB4.F980B480 Content-Type: text/html; charset="iso-8859-1"
Hi,
 
(1) RFC 3261, section 9.1 :
 
=================================================================
   A CANCEL request SHOULD NOT be sent to cancel a request other than
   INVITE.
==========================================================
 
and
 
=================================================================
If no provisional response has been received, the CANCEL request MUST
NOT be sent; rather, the client MUST wait for the arrival of a
provisional response before sending the request.
=================================================================
 
Practically, even if you send CANCEL to BYE, 3 possibilities exist -
 
 - if it reaches before BYE, it will be rejected with 481.
 - if it reaches after BYE, UAS will process BYE first, i.e. it will send final resp. to BYE first,
   then process CANCEL, which will rejected with 481.
 - if CANCEL to BYE is received by a stateful proxy server, it is a race condition. ( I guess it
   can be so even with CANCEL to INVITE via a stateful proxy, is it?).
 
(2) Any UA that initiates a request is a UAC.
Now if called UA initiates INVITE (actually re-INVITE), then it should be able to CANCEL it too.
 
thanks,
= Kedar =
 
-----Original Message-----
From: Sp.Raja [mailto:spraja@isofttechindia.com]
Sent: Tuesday, July 16, 2002 5:26 AM
To: sip@ietf.org
Subject: [Sip] CANCEL FAQs

Please help me out by answering these questions.
 
1. Can CANCEL be used to cancel a bye ?
 
2. Can CANCEL be send by the called entity (UAS) ? If yes then under what circumstances
 
- Sp.Raja
------_=_NextPart_001_01C22DB4.F980B480-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jul 18 01:11:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11540 for ; Thu, 18 Jul 2002 01:11:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA03258 for sip-archive@odin.ietf.org; Thu, 18 Jul 2002 01:12:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25774; Thu, 18 Jul 2002 00:50:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24041 for ; Thu, 18 Jul 2002 00:21:45 -0400 (EDT) Received: from pub.isofttechindia.com ([203.199.202.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10543 for ; Thu, 18 Jul 2002 00:20:46 -0400 (EDT) Received: from isoft ([192.168.0.235]) by pub.isofttechindia.com (8.11.0/8.11.0) with SMTP id g6I4IVV10576 for ; Thu, 18 Jul 2002 09:48:31 +0530 From: "Sp.Raja" To: Date: Thu, 18 Jul 2002 09:57:08 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] BYE race and re-INVITE doubt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Please clear my doubts on the following 1. What is expected out of the SIP element when it receives BYE after sending a BYE? Ex. Let UA1 and UA2 be two user agents and P1, P2 be proxies UA1 P1 P2 UA2 |\ | | /| | \ | | / | | \ | | / | | \ | | / | |BYE \ | | / BYE| | \>|\ /|* | | | | | | | | | What will P1 and P2 do now after receiving BYE? They have already received BYE from the opposite side and yet to receive the response for it. 2. When can re-INVITE be send? I assume it can be send only after receiving ACK or sending ACK accordingly. What is expected out of the proxy in the following cases? Does it simply drops the re-INVITE? UAC sending re-INVITE after sending INVITE and yet to receive final response UAC sending re-INVITE instead of ACK after sending INVITE, received final response UAS sending re-INVITE after receiving INVITE UAS sending re-INVITE after sending final response to INVITE and before receiving ACK _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jul 18 01:15:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11604 for ; Thu, 18 Jul 2002 01:15:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA05472 for sip-archive@odin.ietf.org; Thu, 18 Jul 2002 01:16:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25161; Thu, 18 Jul 2002 00:34:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25129 for ; Thu, 18 Jul 2002 00:34:51 -0400 (EDT) Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10920 for ; Thu, 18 Jul 2002 00:33:44 -0400 (EDT) Received: from [10.10.13.95] (helo=ranjit) by btlmail.bplmail.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17V2tk-0008Pe-00; Thu, 18 Jul 2002 09:58:16 +0530 Message-ID: <002d01c22e14$71b7f4e0$5f0d0a0a@ranjit> Reply-To: "Ranjit Avasarala" From: "Ranjit Avasarala" To: "Suresh Arora" , "Medhavi Bhatia" , References: Subject: Re: [Sip] CANCEL FAQs Date: Thu, 18 Jul 2002 10:04:46 +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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit u cannot send CANCEL for re-invite as u won't be getting any ringing tone as response Ranjit ----- Original Message ----- From: Suresh Arora To: Medhavi Bhatia ; Sent: Wednesday, July 17, 2002 6:14 PM Subject: RE: [Sip] CANCEL FAQs > I think UAS can send CANCEL to UAC for a re-INVITE (if requested session > characteristics are not supported by Server). > > -Suresh > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Medhavi > Bhatia > Sent: Wednesday, July 17, 2002 9:21 AM > To: sip@ietf.org > Subject: Re: [Sip] CANCEL FAQs > > > This stuff generally belongs to the implementor's list: sip-implementors > > > Generally CANCEL should not be used for transactions which are bound to > complete > quickly, and never for transactions for which you havent received a > provisional (1xx) > response. So the answer for (1) would be: probably not. Also the UAS cannot > cancel > a transaction started by the UAC (I guess that's what you meant), so it > cannot generate > the CANCEL ever. > > ----- Original Message ----- > From: "Sp.Raja" > To: > Sent: Tuesday, July 16, 2002 6:25 AM > Subject: [Sip] CANCEL FAQs > > > > Please help me out by answering these questions. > > > > 1. Can CANCEL be used to cancel a bye ? > > > > 2. Can CANCEL be send by the called entity (UAS) ? If yes then under what > > circumstances > > > > - Sp.Raja > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jul 18 05:52:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26982 for ; Thu, 18 Jul 2002 05:52:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA21776 for sip-archive@odin.ietf.org; Thu, 18 Jul 2002 05:53:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20221; Thu, 18 Jul 2002 05:27:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20192 for ; Thu, 18 Jul 2002 05:27:43 -0400 (EDT) Received: from dyn-tx-app-007.dfw.dynamicsoft.com ([63.110.3.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26639 for ; Thu, 18 Jul 2002 05:26:44 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6I3ad118852; Wed, 17 Jul 2002 22:36:46 -0500 Subject: Re: [Sip] CANCEL FAQs From: Robert Sparks To: Ranjit Avasarala Cc: Suresh Arora , Medhavi Bhatia , sip@ietf.org In-Reply-To: <002d01c22e14$71b7f4e0$5f0d0a0a@ranjit> References: <002d01c22e14$71b7f4e0$5f0d0a0a@ranjit> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 18 Jul 2002 18:26:18 +0900 Message-Id: <1026984391.2530.12.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'm going to respond to this on the sip-implementors list. That is the right forum to ask these kind of questions (and to answer them). This list focuses on the SIP working groups current design issues. If you haven't subscribed to sip-implementors (and are interested), the information you need to do so can be found at http://www.cs.columbia.edu/~hgs/sip/list.html RjS On Thu, 2002-07-18 at 13:34, Ranjit Avasarala wrote: > u cannot send CANCEL for re-invite as u won't be getting any ringing tone as > response > > Ranjit > ----- Original Message ----- > From: Suresh Arora > To: Medhavi Bhatia ; > Sent: Wednesday, July 17, 2002 6:14 PM > Subject: RE: [Sip] CANCEL FAQs > > > > I think UAS can send CANCEL to UAC for a re-INVITE (if requested session > > characteristics are not supported by Server). > > > > -Suresh > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Medhavi > > Bhatia > > Sent: Wednesday, July 17, 2002 9:21 AM > > To: sip@ietf.org > > Subject: Re: [Sip] CANCEL FAQs > > > > > > This stuff generally belongs to the implementor's list: sip-implementors > > > > > > Generally CANCEL should not be used for transactions which are bound to > > complete > > quickly, and never for transactions for which you havent received a > > provisional (1xx) > > response. So the answer for (1) would be: probably not. Also the UAS > cannot > > cancel > > a transaction started by the UAC (I guess that's what you meant), so it > > cannot generate > > the CANCEL ever. > > > > ----- Original Message ----- > > From: "Sp.Raja" > > To: > > Sent: Tuesday, July 16, 2002 6:25 AM > > Subject: [Sip] CANCEL FAQs > > > > > > > Please help me out by answering these questions. > > > > > > 1. Can CANCEL be used to cancel a bye ? > > > > > > 2. Can CANCEL be send by the called entity (UAS) ? If yes then under > what > > > circumstances > > > > > > - Sp.Raja > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jul 18 08:31:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00240 for ; Thu, 18 Jul 2002 08:31:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00998 for sip-archive@odin.ietf.org; Thu, 18 Jul 2002 08:32:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28575; Thu, 18 Jul 2002 07:50:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28543 for ; Thu, 18 Jul 2002 07:50:07 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29487 for ; Thu, 18 Jul 2002 07:49:08 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6IBo5Rb019682; Thu, 18 Jul 2002 13:50:06 +0200 (MEST) Received: from lmf.ericsson.se (vrkua2-122.ao.ericsson.se [150.236.87.122]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3YS055XB; Thu, 18 Jul 2002 13:50:04 +0200 Message-ID: <3D355D31.48DC554B@lmf.ericsson.se> Date: Wed, 17 Jul 2002 15:04:01 +0300 X-Sybari-Trust: e2260e06 8340f2bf 109f9f4a 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AC Mahendran CC: sip@ietf.org, jari.arkko@lmf.ericsson.se, vesa.torvinen@lmf.ericsson.se Subject: Re: [Sip] draft-ietf-sip-sec-agree-04.txt References: <5.1.0.14.2.20020711143204.02656460@clea.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, In the particular example you are referring to, the server did not need to include any header in the response in order to establish the chosen security. However, in the general case, the server will chose which information it should include in the response based on the security-client header. Modifying the security-client header can of course be used for a DoS attack, but keep in mind that what we are trying to avoid is a bid-down attack. Regards, Gonzalo AC Mahendran wrote: > > I have question regarding the purpose of the "Security-Client" field. Based > on the description, it looks like this field is not used by the server in > any way. Can someone explain the purpose of this field? > > thanks, > AC > > Ps: In the "Server Initiated" (Section 3.4.2) procedures, this field is not > used. By the same reasoning, this field should not be applicable to the > "Client Initiated" procedures as well. > > At 12:33 PM 7/7/2002 -0400, Internet-Drafts@ietf.org wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > >This draft is a work item of the Session Initiation Protocol Working Group > >of the IETF. > > > > Title : Security Mechanism Agreement for SIP Sessions > > Author(s) : J. Arkko et al. > > Filename : draft-ietf-sip-sec-agree-04.txt > > Pages : 17 > > Date : 05-Jul-02 > > > >SIP has a number of security mechanisms. Some of them have been built > >in to the SIP protocol, such as HTTP authentication or secure > >attachments. These mechanisms have even alternative algorithms and > >parameters. SIP does not currently provide any mechanism for > >selecting which security mechanisms to use between two entities. In > >particular, even if some mechanisms such as OPTIONS were used to make > >this selection, the selection would be vulnerable against the > >Bidding-Down attack. This document defines three header fields for > >negotiating the security mechanisms within SIP between a SIP entity > >and its next SIP hop. A SIP entity applying this mechanism must > >always require some minimum security (i.e. integrity protection) from > >all communicating parties in order to secure the negotiation, but the > >negotiation can agree on which specific minimum security is used. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-04.txt > > > >To remove yourself from the IETF Announcement list, send a message to > >ietf-announce-request with the word unsubscribe in the body of the message. > > > >Internet-Drafts are also available by anonymous FTP. Login with the username > >"anonymous" and a password of your e-mail address. After logging in, > >type "cd internet-drafts" and then > > "get draft-ietf-sip-sec-agree-04.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-ietf-sip-sec-agree-04.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > >Content-Type: text/plain > >Content-ID: <20020705142509.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-sip-sec-agree-04.txt > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 19 07:56:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06167 for ; Fri, 19 Jul 2002 07:56:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01234 for sip-archive@odin.ietf.org; Fri, 19 Jul 2002 07:57:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00065; Fri, 19 Jul 2002 07:16:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00029 for ; Fri, 19 Jul 2002 07:15:57 -0400 (EDT) Received: from ksmax (dclient217-162-98-98.hispeed.ch [217.162.98.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05165 for ; Fri, 19 Jul 2002 07:14:57 -0400 (EDT) Received: from ksmax ([127.0.0.1]) by ksmax with Microsoft SMTPSVC(6.0.2600.1); Fri, 19 Jul 2002 13:15:51 +0200 Message-ID: <001301c22f15$9a6e6520$6262a2d9@ksmax> From: "Matthias Konrad" To: "Sp.Raja" , References: Subject: Re: [Sip] BYE race and re-INVITE doubt Date: Fri, 19 Jul 2002 13:14:58 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 19 Jul 2002 11:15:51.0795 (UTC) FILETIME=[A4599C30:01C22F15] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I think that a stateful proxy doesn't care about any of the cases you described. A proxy, as far as I know, shouldn't hold any dialog states. He just knows about INVITE and nonINVITE transaction states. If that is true, he doesnt even know, that the two BYE Requests belongs to the same dialog. ----- Original Message ----- From: "Sp.Raja" To: Sent: Thursday, July 18, 2002 6:27 AM Subject: [Sip] BYE race and re-INVITE doubt > Hi, > > Please clear my doubts on the following > > 1. What is expected out of the SIP element when it receives BYE after > sending a BYE? > Ex. Let UA1 and UA2 be two user agents and P1, P2 be proxies > > UA1 P1 P2 UA2 > |\ | | /| > | \ | | / | > | \ | | / | > | \ | | / | > |BYE \ | | / BYE| > | \>|\ /| | | \ / | | > | | \ / | | > | | \ | | > | | / \ | | > | ** | > | | | | > | | | | > > What will P1 and P2 do now after receiving BYE? They have already received > BYE from the opposite side and yet to receive the response for it. > > > 2. When can re-INVITE be send? > I assume it can be send only after receiving ACK or sending ACK accordingly. > What is expected out of the proxy in the following cases? Does it simply > drops the re-INVITE? > > UAC sending re-INVITE after sending INVITE and yet to receive final response > UAC sending re-INVITE instead of ACK after sending INVITE, received final > response > UAS sending re-INVITE after receiving INVITE > UAS sending re-INVITE after sending final response to INVITE and before > receiving ACK > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 19 09:25:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07584 for ; Fri, 19 Jul 2002 09:25:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04844 for sip-archive@odin.ietf.org; Fri, 19 Jul 2002 09:26:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03426; Fri, 19 Jul 2002 08:48:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03393 for ; Fri, 19 Jul 2002 08:47:59 -0400 (EDT) Received: from marfik.upv.es (marfik.cc.upv.es [158.42.2.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06984 for ; Fri, 19 Jul 2002 08:47:01 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by marfik.upv.es (8.11.6/8.11.6) with ESMTP id g6JCpTR21947 for ; Fri, 19 Jul 2002 14:51:30 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g6JClt327591; Fri, 19 Jul 2002 14:47:55 +0200 (METDST) Received: from merak.cc.upv.es (merak.cc.upv.es [158.42.4.9]) by smtp2.upv.es (8.11.4/8.11.4) with ESMTP id g6JCltH20588; Fri, 19 Jul 2002 14:47:55 +0200 Received: (from www@localhost) by merak.cc.upv.es (8.11.0/8.11.0) id g6JCltp05946; Fri, 19 Jul 2002 14:47:55 +0200 X-Authentication-Warning: merak.cc.upv.es: www set sender to salreyca@teleco.upv.es using -f To: sip@ietf.org Message-ID: <1027082874.3d380a7ade2e0@webmail.upv.es> Date: Fri, 19 Jul 2002 14:47:54 +0200 (CEST) From: Salvador Rey Calatayud MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 192.35.17.27 Content-Transfer-Encoding: 8bit Subject: [Sip] offer/answer exchanges Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi everyone, as for the transaction state diagrams, and section 14.1 of RFC 3261, a UAS that had received an INVITE(not blank) cannot send another one, and thus start a new offer/answer cycle, until it sends a 200ok, or receives the ACK for a 300-699 response. why is the rule different for 200ok than for other responses? section 14.1 RFC 3261 "2. If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE." I think UPDATE and this are not alligned since the UPDATE specification says that another offer cannot be sent until a previous 1xxrel containing a descriptor is acknowledged with a PRACK (playing the role of ACK to 200ok in basic SIP). I include section 5.1 of UPDATE-02 "and for the callee: o If the UPDATE is being sent before the completion of the INVITE transaction, and the initial INVITE contained an offer, the UPDATE cannot be sent unless the callee has generated an answer in a reliable provisional response, !!has received a PRACK for that reliable provisional response!!, has not received any requests (PRACK or UPDATE) with offers that it has not answered, and has not sent any UPDATE requests containing offers that have not been answered." comments? regards, Salva _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jul 19 18:42:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18492 for ; Fri, 19 Jul 2002 18:42:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01106 for sip-archive@odin.ietf.org; Fri, 19 Jul 2002 18:43:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29130; Fri, 19 Jul 2002 17:58:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29100 for ; Fri, 19 Jul 2002 17:58:51 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18069 for ; Fri, 19 Jul 2002 17:57:52 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6JLwLP01651; Fri, 19 Jul 2002 17:58:21 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA08238; Fri, 19 Jul 2002 16:58:20 -0500 (CDT) Message-ID: <3D388B6B.4060403@lucent.com> Date: Fri, 19 Jul 2002 16:58:03 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: SIP LIST , Vijay Gurbani References: <9BF66EBF6BEFD942915B4D4D45C051F325F46A@DYN-TX-EXCH-001.dynamicsoft.com> <3D3626F3.3080106@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Simple] -05 MESSAGE and Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This has been an interesting discussion with more people weighing in the 'leave it alone' category. However, here is an additional point to consider: Expires is one of the headers that can be encrypted. An S/MIME encrypted MESSAGE request containing 'Expires: 0' arriving at a relay UAS will get the same processing as will an unencrypted MESSAGE with 'Expires: 3600' -- probably not good. The Priority header, on the other hand, is not permitted to be encrypted (Table 3, RFC 3261); thus relays can make use of it. Jonathan Rosenberg gave a concise explanation on why Priority and 'Expires: 0' to mean immediate delivery are different: > I believe that priority is quite different. A message can be for > immediate delivery, and be either urgent ("my house is on fire") or > not ("leaving now for lunch"). A message can be OK for storage (some > non-zero expires) and be urgent ("I need that business presentation > by 10pm!") or non-urgent ("Did you see that movie"). The fact that two > things can be used orthogonally is a sign that they are, in fact, two > different things. In this context, maybe Priority is not the right header, but it is the closest we have in base SIP to impart immediate delivery. The whole point of 'Expires: 0' in the MESSAGE I-D is for the relay UAS and the destination UAS to act on this request immediately. Since the Expire header can be encrypted, the directive of immediate delivery is lost at the relay UAS. Priority preserves it, and in fact, to avoid any further ambiguity, the MESSAGE I-D can further restrict the presence of the Priority header in only those IM messages that denote urgency of some sort, and thus need special processing by the relays. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 22 04:47:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28661 for ; Mon, 22 Jul 2002 04:47:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA01055 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 04:48:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29261; Mon, 22 Jul 2002 04:14:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29232 for ; Mon, 22 Jul 2002 04:14:05 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28102 for ; Mon, 22 Jul 2002 04:13:03 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6M8CQd15583 for ; Mon, 22 Jul 2002 11:12:26 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 11:13:57 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 11:13:57 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 11:13:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23157.B9626BC2" Subject: RE: [Sip] (no subject) Date: Mon, 22 Jul 2002 11:13:56 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203E8@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] (no subject) Thread-Index: AcIsnQnIuwd0j2+JSs+N5y+O+UnglAEunAbg To: , , X-OriginalArrivalTime: 22 Jul 2002 08:13:56.0980 (UTC) FILETIME=[B9DA4340:01C23157] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C23157.B9626BC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 17.2.3 Matching Requests to Server Transactions has a protocol = change (or is that not called a protocol change?). =20 Regards, Hisham=20 -----Original Message----- From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, July 16, 2002 10:44 AM To: 'ABDUL SATTAR SHAIK'; 'sip@ietf.org' Subject: RE: [Sip] (no subject) There were a number of relatively small things fixed.=20 For example, several ABNF errors were reported after bis-09 and before RFC3261 which were fixed. I believe we will provide a diff to highlight the changes. This is harder than you might think because the RFC editor completely redid the formatting, so creating a diff is not really easy. =20 =20 There are no actual protocol changes. =20 Brian -----Original Message----- From: ABDUL SATTAR SHAIK [mailto:abdulss@migv.mot.com] Sent: Tuesday, July 16, 2002 2:06 AM To: 'sip@ietf.org' Subject: [Sip] (no subject) Hi=20 what are the differences between rfc2543-bis-09 and rfc 3261?=20 I didn't find a single difference in these two.=20 I think the bis-09 is published as 3261 since bis-09 expires by august. = AmI right ?=20 Thanks=20 abdul sattar=20 ------_=_NextPart_001_01C23157.B9626BC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Section 17.2.3 Matching Requests to Server=20 Transactions has a protocol change (or is that not called a = protocol=20 change?).
 
Regards,
Hisham 
-----Original Message-----
From: ext Rosen, Brian=20 [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, July 16, = 2002 10:44=20 AM
To: 'ABDUL SATTAR SHAIK'; = 'sip@ietf.org'
Subject: RE:=20 [Sip] (no subject)

There were=20 a number of relatively small things fixed. 
For=20 example, several ABNF errors were reported after = bis-09
and before=20 RFC3261 which were fixed.   I believe we = will
provide a=20 diff to highlight the changes.  This is harder = than
you might=20 think because the RFC editor completely redid the
formatting,=20 so creating a diff is not really easy. 
 
There are=20 no actual protocol changes.
 
Brian
-----Original Message-----
From: ABDUL SATTAR = SHAIK=20 [mailto:abdulss@migv.mot.com]
Sent: Tuesday, July 16, 2002 = 2:06=20 AM
To: 'sip@ietf.org'
Subject: [Sip] (no=20 subject)

Hi
what are=20 the differences between rfc2543-bis-09 and rfc 3261?

I  didn't find a single = difference in these=20 two.

I think the bis-09 is  published = as 3261=20 since bis-09 expires by august.

AmI right ?

Thanks
abdul=20 sattar


------_=_NextPart_001_01C23157.B9626BC2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 22 09:54:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04323 for ; Mon, 22 Jul 2002 09:54:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17746 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 09:55:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15970; Mon, 22 Jul 2002 09:26:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15937 for ; Mon, 22 Jul 2002 09:26:36 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03723 for ; Mon, 22 Jul 2002 09:25:36 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MDPlCU001751 for ; Mon, 22 Jul 2002 09:25:48 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306APZSQ>; Mon, 22 Jul 2002 08:26:06 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2EA@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: sip@ietf.org Subject: RE: [Sip] Proposed change in draft-ietf-sip-nat Date: Mon, 22 Jul 2002 08:26:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I would like to apologise to Pete for the comments below. They were intended as banter between colleagues and not meant to be cc'ed to the list. /a > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Sunday, July 14, 2002 20:15 > To: Pete Cordell; Jonathan Rosenberg; Cullen Jennings > Cc: sip@ietf.org > Subject: RE: [Sip] Proposed change in draft-ietf-sip-nat > > > > -----Original Message----- > > From: Pete Cordell [mailto:pcordell@ridgewaysystems.com] > > > > So why not acknowledge the editorial error (which > > requires no action) and move on. > > Wow. I never thought I'd see the day that the SIP Working Group > mailing list devolved to the level of an old-fashioned Usenet-style > spelling flame. > > Thanks, Pete. It's a first. > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 22 10:03:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04544 for ; Mon, 22 Jul 2002 10:03:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18645 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 10:04:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17466; Mon, 22 Jul 2002 09:48:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17437 for ; Mon, 22 Jul 2002 09:48:03 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04188 for ; Mon, 22 Jul 2002 09:47:02 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MDlthZ047170; Mon, 22 Jul 2002 08:47:55 -0500 (CDT) Message-ID: <3D3C0CFE.1020307@dynamicsoft.com> Date: Mon, 22 Jul 2002 08:47:42 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: SIP LIST References: <9BF66EBF6BEFD942915B4D4D45C051F325F46A@DYN-TX-EXCH-001.dynamicsoft.com> <3D3626F3.3080106@dynamicsoft.com> <3D388B6B.4060403@lucent.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Simple] -05 MESSAGE and Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It seems to me that if the UAC cares about intermediaries seeing the expires header, it would put an expires header in the outer message. Vijay K. Gurbani wrote: > This has been an interesting discussion with more people weighing > in the 'leave it alone' category. However, here is an additional > point to consider: Expires is one of the headers that can be > encrypted. An S/MIME encrypted MESSAGE request containing 'Expires: 0' > arriving at a relay UAS will get the same processing as will > an unencrypted MESSAGE with 'Expires: 3600' -- probably not good. The > Priority header, on the other hand, is not permitted to be encrypted > (Table 3, RFC 3261); thus relays can make use of it. > > Jonathan Rosenberg gave a concise explanation on why Priority and > 'Expires: 0' to mean immediate delivery are different: > > > I believe that priority is quite different. A message can be for > > immediate delivery, and be either urgent ("my house is on fire") or > > not ("leaving now for lunch"). A message can be OK for storage (some > > non-zero expires) and be urgent ("I need that business presentation > > by 10pm!") or non-urgent ("Did you see that movie"). The fact that two > > things can be used orthogonally is a sign that they are, in fact, two > > different things. > > In this context, maybe Priority is not the right header, but it is > the closest we have in base SIP to impart immediate delivery. > > The whole point of 'Expires: 0' in the MESSAGE I-D is for the relay UAS > and the destination UAS to act on this request immediately. Since the > Expire header can be encrypted, the directive of immediate delivery is > lost at the relay UAS. Priority preserves it, and in fact, to avoid any > further ambiguity, the MESSAGE I-D can further restrict the presence of > the Priority header in only those IM messages that denote urgency of > some sort, and thus need special processing by the relays. > > Regards, > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 22 10:52:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06084 for ; Mon, 22 Jul 2002 10:52:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21975 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 10:53:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19853; Mon, 22 Jul 2002 10:27:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19822 for ; Mon, 22 Jul 2002 10:27:15 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05068 for ; Mon, 22 Jul 2002 10:26:14 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6MEQhH06152; Mon, 22 Jul 2002 10:26:43 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA02389; Mon, 22 Jul 2002 09:26:25 -0500 (CDT) Message-ID: <3D3C15FB.8080908@lucent.com> Date: Mon, 22 Jul 2002 09:26:03 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: SIP LIST References: <9BF66EBF6BEFD942915B4D4D45C051F325F46A@DYN-TX-EXCH-001.dynamicsoft.com> <3D3626F3.3080106@dynamicsoft.com> <3D388B6B.4060403@lucent.com> <3D3C0CFE.1020307@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Simple] -05 MESSAGE and Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell wrote: > It seems to me that if the UAC cares about intermediaries seeing the > expires header, it would put an expires header in the outer message. It could; but really, why duplicate the information? RFC 2076 (Common Internet Message Headers) says that 'Priority' can "influence transmission speed and delivery". Which seems to fit exactly with what we want to do. In fact, the more I think of it, the more I am convinced that overloading 'Expires: 0' to mean something completely different in MESSAGE is not a good idea; especially after a precedent has been established by REGISTER and SUBSCRIBE to use 'Expires: 0' to mean 'no longer valid'. It's been pointed out that Priority is not the right header, but I just don't see why not. Expires is deemed to be an end-to-end header; as such, why use it for routing purposes by relays? Whereas, Priority appears to be exactly for this purpose. Adam has proposed the 'Urgency' header; but I don't think we need to make up yet another new header for this and update deployed parsers; Priority handles many shades of urgencies and emergencies. IMHO, giving 'Expires: 0' an overloaded meaning, while having a header ('Priority') that can be used for expedited delivery is what leads to problems of the kind Jonathan alluded to: > A message can be for immediate delivery, and be either urgent ("my > house is on fire") or not ("leaving now for lunch"). A message can be > OK for storage (some non-zero expires) and be urgent ("I need that > business presentation by 10pm!") or non-urgent ("Did you see that > movie"). If, on the other hand, we simply specify 'Priority: Urgent' (or 'Priority: Emergency'), both the UA and the relays should act immediately on that message. No need to add new semantics to 'Expires: 0'. In the final analysis, what is the harm if we can make the MESSAGE PDU self explanatory? I would think that almost everyone will agree that 'Priority: Urgent' is more self-documenting than 'Expires: 0'. As I suggested earlier, the MESSAGE I-D can mandate that 'Priority: Urgent' or 'Priority: Emergency' be only used when, as 3261 says, "life, limb, or property are in imminent danger." Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 22 11:37:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07760 for ; Mon, 22 Jul 2002 11:37:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26400 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 11:38:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23575; Mon, 22 Jul 2002 11:11:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23544 for ; Mon, 22 Jul 2002 11:11:10 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06692 for ; Mon, 22 Jul 2002 11:10:04 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MF9nCU002792; Mon, 22 Jul 2002 11:10:12 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306APZTM>; Mon, 22 Jul 2002 10:10:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2F0@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Vijay K. Gurbani'" , Ben Campbell Cc: SIP LIST Subject: RE: [Sip] Re: [Simple] -05 MESSAGE and Expires header Date: Mon, 22 Jul 2002 10:10:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > Adam has proposed the 'Urgency' header No, I didn't. I attempted to outline that what we're talking about isn't priority in any sense of the word. We're talking about urgency. I asked Hisham whether he was making a proposal for a new header -- but it was asked with a certain amount of irony. I didn't expect that he was doing so, and crafted the rest of my message with the assumption that his answer would be "no". My argument remains that "Expires" is the most appropriate header for this purpose. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 22 12:04:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08986 for ; Mon, 22 Jul 2002 12:04:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01435 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 12:05:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26526; Mon, 22 Jul 2002 11:39:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26494 for ; Mon, 22 Jul 2002 11:39:12 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07806 for ; Mon, 22 Jul 2002 11:38:11 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6MFcee24012; Mon, 22 Jul 2002 11:38:40 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA10949; Mon, 22 Jul 2002 10:38:37 -0500 (CDT) Message-ID: <3D3C26E4.8010403@lucent.com> Date: Mon, 22 Jul 2002 10:38:12 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Ben Campbell , SIP LIST Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header References: <9BF66EBF6BEFD942915B4D4D45C051F377A2F0@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Adam Roach wrote: >>-----Original Message----- >>From: Vijay K. Gurbani [mailto:vkg@lucent.com] >> >>Adam has proposed the 'Urgency' header > > No, I didn't. Okay; my apologies. I did detect the irony, but absent a face- to-face conversation, I wasn't sure if you were being serious or flippant. Glad to know we won't be making up a new header. > I attempted to outline that what we're talking about isn't > priority in any sense of the word. > > We're talking about urgency. If I may, I think we are imparting urgency to an IM based on the *content* of the IM. In other words, to use one of your examples: > High Priority, Low Urgency: > Note to new residents: failure to file income taxes by April > 15th can lead to substantial penalties. Absence other information (like the date that this IM was sent), urgency is meaningless. For example, if this IM was sent on April 14th, I would think that it would be classified with high urgency. If, OTOH, it was sent on April 16th, its urgency is extremely low. And a relay should not be put in position to use many heuristics for figuring out which IMs should get immediate attention. > My argument remains that "Expires" is the most appropriate > header for this purpose. Right; I see I haven't convinced you yet :-) - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 22 12:56:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15865 for ; Mon, 22 Jul 2002 12:56:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10620 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 12:57:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09298; Mon, 22 Jul 2002 12:19:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09197 for ; Mon, 22 Jul 2002 12:19:16 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10652 for ; Mon, 22 Jul 2002 12:18:14 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MGJDhZ059496; Mon, 22 Jul 2002 11:19:13 -0500 (CDT) Message-ID: <3D3C3073.9000209@dynamicsoft.com> Date: Mon, 22 Jul 2002 11:18:59 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Adam Roach , SIP LIST Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header References: <9BF66EBF6BEFD942915B4D4D45C051F377A2F0@DYN-TX-EXCH-001.dynamicsoft.com> <3D3C26E4.8010403@lucent.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Adam Roach wrote: > >>> -----Original Message----- >>> From: Vijay K. Gurbani [mailto:vkg@lucent.com] >>> >>> Adam has proposed the 'Urgency' header >> >> >> No, I didn't. > > > Okay; my apologies. I did detect the irony, but absent a face- > to-face conversation, I wasn't sure if you were being serious or > flippant. Glad to know we won't be making up a new header. > >> I attempted to outline that what we're talking about isn't >> priority in any sense of the word. >> >> We're talking about urgency. > > > If I may, I think we are imparting urgency to an IM based on the > *content* of the IM. In other words, to use one of your examples: > >> High Priority, Low Urgency: >> Note to new residents: failure to file income taxes by April >> 15th can lead to substantial penalties. > > > Absence other information (like the date that this IM was sent), > urgency is meaningless. For example, if this IM was sent on April > 14th, I would think that it would be classified with high urgency. > If, OTOH, it was sent on April 16th, its urgency is extremely low. > And a relay should not be put in position to use many heuristics > for figuring out which IMs should get immediate attention. > OK, let me extend Adam's example: The message is sent on March 15. It has high priority, but low urgency. (And I assume that Adam was not suggesting that the relay understand the content of the note to determine urgency and priority--he was simply suggesting a situation where a sender might mark the message as high priority but low urgency.) >> My argument remains that "Expires" is the most appropriate >> header for this purpose. > > > Right; I see I haven't convinced you yet :-) > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 22 13:39:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20408 for ; Mon, 22 Jul 2002 13:39:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09490 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 13:40:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17757; Mon, 22 Jul 2002 13:06:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17693 for ; Mon, 22 Jul 2002 13:06:47 -0400 (EDT) Received: from web11605.mail.yahoo.com (web11605.mail.yahoo.com [216.136.172.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16939 for ; Mon, 22 Jul 2002 13:05:45 -0400 (EDT) Message-ID: <20020722170645.11779.qmail@web11605.mail.yahoo.com> Received: from [131.107.3.83] by web11605.mail.yahoo.com via HTTP; Mon, 22 Jul 2002 10:06:45 PDT Date: Mon, 22 Jul 2002 10:06:45 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header To: Ben Campbell , "Vijay K. Gurbani" Cc: Adam Roach , SIP LIST In-Reply-To: <3D3C3073.9000209@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org So we have three things we might want to represent: 1) Priority -- we use the Priority header for this 2) Timeliness of content -- we use Expires: header for this 3) Urgency -- we don't currently have a way to represent this Obviously 2 & 3 are related but not identical. The message doesn't have to be urgent in order for you to request immediate delivery. I think solving (2) is enough for now. It is the more interesting case for gateways and other intermediaries that have to decide between a store-and-forward or immediate delivery approach. In other words, stick with what we have today in the draft. /sean __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 22 14:31:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25682 for ; Mon, 22 Jul 2002 14:31:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09626 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 14:32:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24419; Mon, 22 Jul 2002 14:05:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24362 for ; Mon, 22 Jul 2002 14:05:28 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23031 for ; Mon, 22 Jul 2002 14:04:25 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6MI4r316730; Mon, 22 Jul 2002 13:04:53 -0500 From: "Dean Willis" To: Cc: Date: Mon, 22 Jul 2002 13:04:26 -0500 Message-ID: <003b01c231aa$37e0b5b0$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <042201c22788$dd63dca0$eb036e3f@TXDWILLIS2> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Response Summary -- Should service route discovery be standards track or p-header? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I raised the follwing on July 9: > Should the SIP Service route Discovery draft be an > informational P-header or should it be standards track? Some > have argued that it is more general than usual for P-headers. > It seems to me to be useful whenever it is useful for a > registrar to return routing infromation that UAs may use when > they want request routing services from the domain served by > that registrar. Almost all response were in favor of making this standards track. Several people dissented with arguments along the lines of "Let's make it a P-header so that we can use this as a test case for proving that P-headers might not be a good idea". While I'm not entirely opposed to this sort of protest action, it doesn't seem right to me in this case. So, I think we have a rough consensus for taking this work onto standards track. I believe very little change is needed to the existing document to adapt it for standards-track -- basically, delete the P-, and update the references to include 3261. The draft has already had extensive review within the working group, so I think we should be able to complete a new WGLC fairly easily. I would suggest that we adopt it as a charter item with a milestone of delivery to IESG in August, with expected delivery being "very early August". Comments? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jul 22 17:34:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11741 for ; Mon, 22 Jul 2002 17:34:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10330 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 17:35:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28847; Mon, 22 Jul 2002 17:13:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02165 for ; Thu, 18 Jul 2002 13:51:58 -0400 (EDT) Received: from hotmail.com (f183.law12.hotmail.com [64.4.19.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09064 for ; Thu, 18 Jul 2002 13:50:59 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Jul 2002 10:51:27 -0700 Received: from 192.75.88.232 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 18 Jul 2002 17:51:27 GMT X-Originating-IP: [192.75.88.232] From: "Taja Ja" To: sip@ietf.org Cc: mkadoch@ele.etsmtl.ca Date: Thu, 18 Jul 2002 13:51:27 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2002 17:51:27.0349 (UTC) FILETIME=[BD6DFA50:01C22E83] Subject: [Sip] SIP and RTP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi , If someone can help understand how SIP uses RTP. (we have two users agent installed on 2 different PCs they SIP together but I don't know how to call/use RTP) Any help is greatly apperciated. Thanks for your time.Taher. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jul 22 17:56:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13711 for ; Mon, 22 Jul 2002 17:56:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21828 for sip-archive@odin.ietf.org; Mon, 22 Jul 2002 17:57:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08365; Mon, 22 Jul 2002 17:31:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08292 for ; Mon, 22 Jul 2002 17:31:21 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11406 for ; Mon, 22 Jul 2002 17:30:19 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA13606; Mon, 22 Jul 2002 14:30:39 -0700 (PDT) Message-Id: <4.1.20020722162045.030538a8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 22 Jul 2002 16:30:31 -0500 To: "Taja Ja" , sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] SIP and RTP Cc: mkadoch@ele.etsmtl.ca In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 01:51 PM 7/18/2002 -0400, Taja Ja wrote: >Hi , > > If someone can help understand how SIP uses RTP. > (we have two users agent installed on 2 different PCs > they SIP together but I don't know how to call/use RTP) Within the INVITE is SDP (capabilities negotiation) for the type of (for example) RTP session the UAC wants to have with the UAS. The SDP specifies the payload type/codec and other such details for that proposed session. Simplistically, if the UAS replies with a 200 OK Response, the session is created with the SDP parameters specified from the UAC (after the UAC sends a final ACK to the UAS) RFC 3264 is a good reference for this explanation in the Offer-Answer Model where both UAs become aware of the capabilities of each other prior to session establishment. > > Any help is greatly apperciated. > >Thanks for your time.Taher. > > > > >_________________________________________________________________ >MSN Photos is the easiest way to share and print your photos: >http://photos.msn.com/support/worldwide.aspx > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jul 23 01:36:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21062 for ; Tue, 23 Jul 2002 01:36:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA13222 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 01:37:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19103; Tue, 23 Jul 2002 00:55:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19042 for ; Tue, 23 Jul 2002 00:55:12 -0400 (EDT) Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18535 for ; Tue, 23 Jul 2002 00:54:08 -0400 (EDT) Received: from m1.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id NAA28799 for ; Tue, 23 Jul 2002 13:54:39 +0900 (JST) (envelope-from shingo_fujimoto@jp.fujitsu.com) Received: from dm.akashi.flab.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0206-Fujitsu Domain Master) id NAA05174 for ; Tue, 23 Jul 2002 13:54:38 +0900 (JST) (envelope-from shingo_fujimoto@jp.fujitsu.com) Received: from dm.akashi.flab.fujitsu.co.jp by dm.akashi.flab.fujitsu.co.jp (8.9.3/3.7W-020129-Fujitsu Labs. Akashi Domain Mail Master) id NAA25684; Tue, 23 Jul 2002 13:54:37 +0900 (JST) Received: from kmailserv.akashi.flab.fujitsu.co.jp ([10.254.200.15]) by dm.akashi.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2002072313543722504 for ; Tue, 23 Jul 2002 13:54:37 +0900 Received: from jp.fujitsu.com (suzume.pssys.flab.fujitsu.co.jp [10.254.215.64]) by kmailserv.akashi.flab.fujitsu.co.jp (8.8.8+Sun/8.8.8) with ESMTP id NAA08309 for ; Tue, 23 Jul 2002 13:54:36 +0900 (JST) Message-ID: <3D3CE1C9.4080505@jp.fujitsu.com> Date: Tue, 23 Jul 2002 13:55:37 +0900 From: Shingo Fujimoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: ja,en-US,en MIME-Version: 1.0 To: SIP-WG Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] language info in SIP headers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello. I would like to raise the new issue to solve. SIP RFC specified UTF-8 friendly transport, but I think that did not specified the way to use multi bytes characters in header part of SIP messages. If I use Japanese Kanji letters in From: header (as display name), the receiver UA cannot determine which language of characters are used in UTF-8 encoded text. Additionally, since UTF-8 CJK kanji characters are overlapped between Chinese, Japanese, and Korean, sometimes UA can not determine which font should be used to display them. MIME part 3 and updated RFC2231 introduced some solution for this problem with combination of character set and language tag. However RFC2231 always required escaping 8bit-flaged characters, there are huge overhead to express multi byte characters. As another option, recent Unicode 3.x specification includes "language tag" characters to solve this problem, but it is not common to support such new feature in the any UTF-8 handling libraries. I guess that results corrupted display in UAs. My suggestion about this, we should prepare supplemental document for SIP which specify the way to express international characters with language information in header part (modified RFC2231 or UTF-8 with "lang tag" support). I would like to hear your opinion. Thank you. -- ====================================== SHINGO FUJIMOTO FUJITSU LABORATORIES LIMITED E-mail: shingo_fujimoto@jp.fujitsu.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jul 23 03:01:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01424 for ; Tue, 23 Jul 2002 03:01:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18088 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 03:02:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15988; Tue, 23 Jul 2002 02:28:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15943 for ; Tue, 23 Jul 2002 02:28:53 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00898 for ; Tue, 23 Jul 2002 02:27:50 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6N6TOi09679 for ; Tue, 23 Jul 2002 09:29:25 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 09:28:51 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 09:28:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Re: [Simple] -05 MESSAGE and Expires header Date: Tue, 23 Jul 2002 09:28:50 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203F2@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] Re: [Simple] -05 MESSAGE and Expires header Thread-Index: AcIxokD1X/EzOSp1Q4a/HTta87/C2QAbiMkg To: , , Cc: , X-OriginalArrivalTime: 23 Jul 2002 06:28:51.0419 (UTC) FILETIME=[35DBC2B0:01C23212] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA15944 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit So, a MESSAGE with Expires: 10 means it has 10 seconds before it's stale while a MESSAGE with Expires: 0 means it will never be stale? How do u inform the receiver that a message is stale? /Hisham > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: Monday, July 22, 2002 8:07 PM > To: Ben Campbell; Vijay K. Gurbani > Cc: Adam Roach; SIP LIST > Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header > > > So we have three things we might want to > represent: > > 1) Priority -- we use the Priority header for this > 2) Timeliness of content -- we use Expires: header > for this > 3) Urgency -- we don't currently have a way to > represent this > > Obviously 2 & 3 are related but not identical. > The message doesn't have to be urgent in order > for you to request immediate delivery. I think > solving (2) is enough for now. It is the more > interesting case for gateways and other > intermediaries that have to decide between a > store-and-forward or immediate delivery approach. > In other words, stick with what we have today in > the draft. > > /sean > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jul 23 03:03:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01484 for ; Tue, 23 Jul 2002 03:03:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18331 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 03:04:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16890; Tue, 23 Jul 2002 02:39:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16859 for ; Tue, 23 Jul 2002 02:39:07 -0400 (EDT) Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01054 for ; Tue, 23 Jul 2002 02:38:06 -0400 (EDT) Message-ID: <20020723063906.84113.qmail@web11607.mail.yahoo.com> Received: from [12.235.154.217] by web11607.mail.yahoo.com via HTTP; Mon, 22 Jul 2002 23:39:06 PDT Date: Mon, 22 Jul 2002 23:39:06 -0700 (PDT) From: Sean Olson Subject: RE: [Sip] Re: [Simple] -05 MESSAGE and Expires header To: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, vkg@lucent.com Cc: adam@dynamicsoft.com, sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7C203F2@esebe019.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I fail to see why Expires: 0 means the message will never expire. How does 0 equate to infinity? An Expires: 0 from the sender, in my opinion, should indicate that this message should be delivered immediately or not at all. I don't think it should be used for the sender (or gateway or proxy) to indicate that a message is "stale". By stale, I assume you mean a message that was intended for immediate delivery, but was actually stored instead -- this is not something existing SIP headers do a good job of representing. I wouldn't try to hack Expires: to fit this. Furthermore, I don't think this is a problem that the message draft should have to solve. Until someone comes up with a more complete draft for offline message retrieval, I think we can punt this. Or is that what you were offering to do? --- hisham.khartabil@nokia.com wrote: > So, a MESSAGE with Expires: 10 means it has 10 > seconds before it's stale while a MESSAGE with > Expires: 0 means it will never be stale? > > How do u inform the receiver that a message is > stale? > > /Hisham > > > -----Original Message----- > > From: ext Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Monday, July 22, 2002 8:07 PM > > To: Ben Campbell; Vijay K. Gurbani > > Cc: Adam Roach; SIP LIST > > Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and > Expires header > > > > > > So we have three things we might want to > > represent: > > > > 1) Priority -- we use the Priority header for this > > 2) Timeliness of content -- we use Expires: header > > for this > > 3) Urgency -- we don't currently have a way to > > represent this > > > > Obviously 2 & 3 are related but not identical. > > The message doesn't have to be urgent in order > > for you to request immediate delivery. I think > > solving (2) is enough for now. It is the more > > interesting case for gateways and other > > intermediaries that have to decide between a > > store-and-forward or immediate delivery approach. > > In other words, stick with what we have today in > > the draft. > > > > /sean > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Health - Feel better, live better > > http://health.yahoo.com > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jul 23 03:03:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01501 for ; Tue, 23 Jul 2002 03:03:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18342 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 03:04:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16926; Tue, 23 Jul 2002 02:39:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16898 for ; Tue, 23 Jul 2002 02:39:13 -0400 (EDT) Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01058 for ; Tue, 23 Jul 2002 02:38:13 -0400 (EDT) Message-ID: <20020723063913.84127.qmail@web11607.mail.yahoo.com> Received: from [12.235.154.217] by web11607.mail.yahoo.com via HTTP; Mon, 22 Jul 2002 23:39:13 PDT Date: Mon, 22 Jul 2002 23:39:13 -0700 (PDT) From: Sean Olson Subject: RE: [Sip] Re: [Simple] -05 MESSAGE and Expires header To: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, vkg@lucent.com Cc: adam@dynamicsoft.com, sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7C203F2@esebe019.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I fail to see why Expires: 0 means the message will never expire. How does 0 equate to infinity? An Expires: 0 from the sender, in my opinion, should indicate that this message should be delivered immediately or not at all. I don't think it should be used for the sender (or gateway or proxy) to indicate that a message is "stale". By stale, I assume you mean a message that was intended for immediate delivery, but was actually stored instead -- this is not something existing SIP headers do a good job of representing. I wouldn't try to hack Expires: to fit this. Furthermore, I don't think this is a problem that the message draft should have to solve. Until someone comes up with a more complete draft for offline message retrieval, I think we can punt this. Or is that what you were offering to do? --- hisham.khartabil@nokia.com wrote: > So, a MESSAGE with Expires: 10 means it has 10 > seconds before it's stale while a MESSAGE with > Expires: 0 means it will never be stale? > > How do u inform the receiver that a message is > stale? > > /Hisham > > > -----Original Message----- > > From: ext Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Monday, July 22, 2002 8:07 PM > > To: Ben Campbell; Vijay K. Gurbani > > Cc: Adam Roach; SIP LIST > > Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and > Expires header > > > > > > So we have three things we might want to > > represent: > > > > 1) Priority -- we use the Priority header for this > > 2) Timeliness of content -- we use Expires: header > > for this > > 3) Urgency -- we don't currently have a way to > > represent this > > > > Obviously 2 & 3 are related but not identical. > > The message doesn't have to be urgent in order > > for you to request immediate delivery. I think > > solving (2) is enough for now. It is the more > > interesting case for gateways and other > > intermediaries that have to decide between a > > store-and-forward or immediate delivery approach. > > In other words, stick with what we have today in > > the draft. > > > > /sean > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Health - Feel better, live better > > http://health.yahoo.com > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 23 04:23:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03240 for ; Tue, 23 Jul 2002 04:23:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22592 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 04:24:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20847; Tue, 23 Jul 2002 03:57:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20821 for ; Tue, 23 Jul 2002 03:57:07 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02734 for ; Tue, 23 Jul 2002 03:56:06 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g6N7v4l02512; Tue, 23 Jul 2002 09:57:05 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g6N7v4321009; Tue, 23 Jul 2002 09:57:04 +0200 (MEST) Received: from cs.columbia.edu ([139.21.148.224]) by mail-y.mchp.siemens.de with ESMTP id g6N7uxcH020570; Tue, 23 Jul 2002 09:56:59 +0200 (MET DST) Message-ID: <3D3D0C1A.7020307@cs.columbia.edu> Date: Tue, 23 Jul 2002 03:56:10 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shingo Fujimoto CC: SIP-WG Subject: Re: [Sip] language info in SIP headers References: <3D3CE1C9.4080505@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This is actually a fairly thorny problem. From a previous private discussion, there are only a few possible solutions: - RFC 2482 or http://www.unicode.org/unicode/reports/tr27/#tag provide language tagging, as you noted. While I have not seen an official statement from the IESG on this, I believe 10646 language tagging has generally been deprecated. It's not quite clear whether the reasons (I believe, nesting) for that apply to short text such as Subject or Organization. - For header fields that allow parameters, I believe the best option is to add a language parameter, as in From: "Somebody" ;language="en" This doesn't allow multiple languages within the same header field, but is probably useful and sufficient as a hint for text-to-speech and other UI rendering. It is also backward-compatible. This works for From, To and a few others, such as the NAI header fields. - For header fields that don't allow parameters (Subject, Organization, etc.), there are no good options. In general, I believe we should avoid such header fields in the future. One possible kludge suggested in private conversation would be to add a descriptive header that tells you what language each header field contains. Or, simpler but less space-efficient, something like Subject-Language: jp Organization-Language: en-us Any other suggestions? Shingo Fujimoto wrote: > Hello. I would like to raise the new issue to solve. > > SIP RFC specified UTF-8 friendly transport, but I think that did not > specified the way to use multi bytes characters in header part of > SIP messages. > > If I use Japanese Kanji letters in From: header (as display name), > the receiver UA cannot determine which language of characters are > used in UTF-8 encoded text. Additionally, since UTF-8 CJK kanji > characters are overlapped between Chinese, Japanese, and Korean, > sometimes UA can not determine which font should be used to display > them. > > MIME part 3 and updated RFC2231 introduced some solution for this > problem with combination of character set and language tag. However > RFC2231 always required escaping 8bit-flaged characters, there are > huge overhead to express multi byte characters. > > As another option, recent Unicode 3.x specification includes > "language tag" characters to solve this problem, but it is not > common to support such new feature in the any UTF-8 handling > libraries. I guess that results corrupted display in UAs. > > My suggestion about this, we should prepare supplemental document > for SIP which specify the way to express international characters > with language information in header part (modified RFC2231 or UTF-8 > with "lang tag" support). > > I would like to hear your opinion. > > Thank you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 23 04:26:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03374 for ; Tue, 23 Jul 2002 04:26:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22727 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 04:27:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20543; Tue, 23 Jul 2002 03:51:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20512 for ; Tue, 23 Jul 2002 03:51:29 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02605 for ; Tue, 23 Jul 2002 03:50:28 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6N7pwi05759 for ; Tue, 23 Jul 2002 10:51:58 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 10:51:25 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 10:51:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Re: [Simple] -05 MESSAGE and Expires header Date: Tue, 23 Jul 2002 10:51:24 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203F4@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] Re: [Simple] -05 MESSAGE and Expires header Thread-Index: AcIyE6a+Pb+8QXmiTme4Glu1d52crAACMXag To: , , Cc: , X-OriginalArrivalTime: 23 Jul 2002 07:51:25.0395 (UTC) FILETIME=[BEA88230:01C2321D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA20513 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I would like some interpretation for a few messages in terms of immediate delivery, urgency and expiration of a message: 1. MESSAGE ... Priority: non-urgent Expires: 0 ... I'm leaving for lunch right now 2. MESSAGE ... Priority: emergency Expires: 3600 ... your house is on fire 3. MESSAGE ... ... Date: Tue, 23 Jul 2002 7:25:00 GMT Expires: 60 4. MESSAGE ... ... Date: Tue, 23 Jul 2002 7:25:00 GMT Expires: 0 Do messages 1 and 2 get immediate delivery? Another question: This immediate delivery debate is only talking about Store and Forward type of servers of gateways. What about other intermediaries? They certainly can't use the expires-header to decide on speed of delivery of a message. We need a new mechanism here. Again I ask the question: Is this done in IEPREP? Regards, Hisham > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, July 23, 2002 9:39 AM > To: Khartabil Hisham (NMP/Helsinki); bcampbell@dynamicsoft.com; > vkg@lucent.com > Cc: adam@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] Re: [Simple] -05 MESSAGE and Expires header > > > I fail to see why Expires: 0 means the message > will never expire. How does 0 equate to infinity? > > An Expires: 0 from the sender, in my opinion, > should indicate that this message should be delivered > immediately or not at all. I don't think it should > be used for the sender (or gateway or proxy) to > indicate that a message is "stale". > > By stale, > I assume you mean a message that was intended for > immediate delivery, but was actually stored instead > -- this is not something existing SIP headers do a > good job of representing. I wouldn't try to hack > Expires: to fit this. Furthermore, I don't think > this is a problem that the message draft should have > to solve. Until someone comes up with a more complete > draft for offline message retrieval, I think we can > punt this. Or is that what you were offering to do? > > > --- hisham.khartabil@nokia.com wrote: > > So, a MESSAGE with Expires: 10 means it has 10 > > seconds before it's stale while a MESSAGE with > > Expires: 0 means it will never be stale? > > > > How do u inform the receiver that a message is > > stale? > > > > /Hisham > > > > > -----Original Message----- > > > From: ext Sean Olson [mailto:seancolson@yahoo.com] > > > Sent: Monday, July 22, 2002 8:07 PM > > > To: Ben Campbell; Vijay K. Gurbani > > > Cc: Adam Roach; SIP LIST > > > Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and > > Expires header > > > > > > > > > So we have three things we might want to > > > represent: > > > > > > 1) Priority -- we use the Priority header for this > > > 2) Timeliness of content -- we use Expires: header > > > for this > > > 3) Urgency -- we don't currently have a way to > > > represent this > > > > > > Obviously 2 & 3 are related but not identical. > > > The message doesn't have to be urgent in order > > > for you to request immediate delivery. I think > > > solving (2) is enough for now. It is the more > > > interesting case for gateways and other > > > intermediaries that have to decide between a > > > store-and-forward or immediate delivery approach. > > > In other words, stick with what we have today in > > > the draft. > > > > > > /sean > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Yahoo! Health - Feel better, live better > > > http://health.yahoo.com > > > > > > _______________________________________________ > > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > > Protocol > > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 23 06:15:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05167 for ; Tue, 23 Jul 2002 06:15:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29065 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 06:16:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27287; Tue, 23 Jul 2002 05:50:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27254 for ; Tue, 23 Jul 2002 05:49:57 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04648 for ; Tue, 23 Jul 2002 05:48:54 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g6N9ns005638; Tue, 23 Jul 2002 11:49:55 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g6N9ns317674; Tue, 23 Jul 2002 11:49:54 +0200 (MEST) Received: from cs.columbia.edu ([139.21.148.224]) by mail-y.mchp.siemens.de with ESMTP id g6N9nmcH022482; Tue, 23 Jul 2002 11:49:48 +0200 (MET DST) Message-ID: <3D3D268B.8030803@cs.columbia.edu> Date: Tue, 23 Jul 2002 05:48:59 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shingo Fujimoto CC: SIP-WG Subject: Re: [Sip] language info in SIP headers References: <3D3CE1C9.4080505@jp.fujitsu.com> <3D3D0C1A.7020307@cs.columbia.edu> <3D3D22C6.2080208@jp.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The reason I prefer this approach is that SIP messages must be small > if it runs over UDP. "language tag" will add only few bytes. > > Problem is backward compatibility with widely deployed SIP implementations. > Another option is use MIME part3 with small modification. > Since current MIME part3 did not allow to use any 8 bit flagged > characters in MIME headers, encoding always escapes UTF-8 characters. > > This is an example of MIME part3 header. > > From: =?UTF-8*JP?B??= > > "base64" part is escaped and increased its size with 1.5 times or more. > > If we define new encoding, say 'U', which only escape special > charactors ('=','?',and '%' with '%xx' escaping). > > From: =?UTF-8*JP?U??= > > This extension saves overhead on 8 bit charactors, and will not > suffer any older implementations. > > Additionally, if we can assume utf-8 and 'U' encoding, then we can > minimize the escaping syntax too. > > From: =?JP??= > > This still valid as display name value. > > Both Keith and Ned suggested me that if we define 'U' encoding, it > should be limited within SIP specification. > I would suggest you write up a short I-D on the subject. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 23 06:15:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05183 for ; Tue, 23 Jul 2002 06:15:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29181 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 06:16:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26834; Tue, 23 Jul 2002 05:32:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26803 for ; Tue, 23 Jul 2002 05:32:36 -0400 (EDT) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04426 for ; Tue, 23 Jul 2002 05:31:33 -0400 (EDT) Received: from m5.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id SAA23473 for ; Tue, 23 Jul 2002 18:32:02 +0900 (JST) (envelope-from shingo_fujimoto@jp.fujitsu.com) Received: from dm.akashi.flab.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-0206-Fujitsu Domain Master) id SAA26108 for ; Tue, 23 Jul 2002 18:32:00 +0900 (envelope-from shingo_fujimoto@jp.fujitsu.com) Received: from dm.akashi.flab.fujitsu.co.jp by dm.akashi.flab.fujitsu.co.jp (8.9.3/3.7W-020129-Fujitsu Labs. Akashi Domain Mail Master) id SAA00952; Tue, 23 Jul 2002 18:32:00 +0900 (JST) Received: from kmailserv.akashi.flab.fujitsu.co.jp ([10.254.200.15]) by dm.akashi.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2002072318315921665 ; Tue, 23 Jul 2002 18:31:59 +0900 Received: from jp.fujitsu.com (suzume.pssys.flab.fujitsu.co.jp [10.254.215.64]) by kmailserv.akashi.flab.fujitsu.co.jp (8.8.8+Sun/8.8.8) with ESMTP id SAA27160; Tue, 23 Jul 2002 18:31:59 +0900 (JST) Message-ID: <3D3D22C6.2080208@jp.fujitsu.com> Date: Tue, 23 Jul 2002 18:32:54 +0900 From: Shingo Fujimoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: ja,en-US,en MIME-Version: 1.0 To: Henning Schulzrinne CC: SIP-WG Subject: Re: [Sip] language info in SIP headers References: <3D3CE1C9.4080505@jp.fujitsu.com> <3D3D0C1A.7020307@cs.columbia.edu> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am happy to hear you already had some discussions. Henning Schulzrinne wrote: > - RFC 2482 or http://www.unicode.org/unicode/reports/tr27/#tag provide > language tagging, as you noted. While I have not seen an official > statement from the IESG on this, I believe 10646 language tagging has > generally been deprecated. It's not quite clear whether the reasons (I > believe, nesting) for that apply to short text such as Subject or > Organization. You are probably right. Here is the comment from Ned Freed, one of the RFC2231 authors: > Language indicators in a pure UTF-8 environment like SIP headers have to be > stored as part of the UTF-8 string itself. The plane 14 language tags described > in > > http://www.unicode.org/unicode/reports/tr27/#tag > > are the only means of doing this that I'm aware of. However, the use > of such tags is, as the text indicates, strongly discouraged. > > It is the Unicode Technical Committee's belief that > > The requirement for language information embedded in plain text data is often > overstated. > > As such, I see little chance for support for such tagging in the context of SIP > headers being widely deployed. > > Ned > The reason I prefer this approach is that SIP messages must be small if it runs over UDP. "language tag" will add only few bytes. Problem is backward compatibility with widely deployed SIP implementations. > - For header fields that allow parameters, I believe the best option is > to add a language parameter, as in > > From: "Somebody" ;language="en" > > This doesn't allow multiple languages within the same header field, but > is probably useful and sufficient as a hint for text-to-speech and other > UI rendering. It is also backward-compatible. This works for From, To > and a few others, such as the NAI header fields. I think this approach is fair. I guess it is quite rare to use multiple languages are used in short text field. > - For header fields that don't allow parameters (Subject, Organization, > etc.), there are no good options. In general, I believe we should avoid > such header fields in the future. One possible kludge suggested in > private conversation would be to add a descriptive header that tells you > what language each header field contains. Or, simpler but less > space-efficient, something like > > Subject-Language: jp > Organization-Language: en-us I think these are also as good as previous one. > Any other suggestions? Another option is use MIME part3 with small modification. Since current MIME part3 did not allow to use any 8 bit flagged characters in MIME headers, encoding always escapes UTF-8 characters. This is an example of MIME part3 header. From: =?UTF-8*JP?B??= "base64" part is escaped and increased its size with 1.5 times or more. If we define new encoding, say 'U', which only escape special charactors ('=','?',and '%' with '%xx' escaping). From: =?UTF-8*JP?U??= This extension saves overhead on 8 bit charactors, and will not suffer any older implementations. Additionally, if we can assume utf-8 and 'U' encoding, then we can minimize the escaping syntax too. From: =?JP??= This still valid as display name value. Both Keith and Ned suggested me that if we define 'U' encoding, it should be limited within SIP specification. -- ====================================== SHINGO FUJIMOTO FUJITSU LABORATORIES LIMITED E-mail: shingo_fujimoto@jp.fujitsu.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 23 12:20:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21259 for ; Tue, 23 Jul 2002 12:20:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25433 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 12:21:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20312; Tue, 23 Jul 2002 11:39:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20280 for ; Tue, 23 Jul 2002 11:39:28 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18640 for ; Tue, 23 Jul 2002 11:38:26 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6NFdPW14135; Tue, 23 Jul 2002 11:39:25 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA04920; Tue, 23 Jul 2002 10:39:24 -0500 (CDT) Message-ID: <3D3D7890.9040207@lucent.com> Date: Tue, 23 Jul 2002 10:38:56 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, adam@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header References: <20020723063906.84113.qmail@web11607.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean Olson wrote: > I fail to see why Expires: 0 means the message > will never expire. How does 0 equate to infinity? > > An Expires: 0 from the sender, in my opinion, > should indicate that this message should be delivered > immediately or not at all. I don't think it should > be used for the sender (or gateway or proxy) to > indicate that a message is "stale". Staleness is what 'Expires: 0' currently implies for REGISTER and SUBSCRIBE. And I realize that I am fighting a loosing battle, but for all it is worth, it will be good to accord only that semantic to 'Expires: 0', and no more. Now, before everyone flames me, I do realize that the MESSAGE I-D does not allow for this behavior, nor are there any requirements in section 5.4 of RFC 2779 to that effect. But there have been many times when I have sent an email which I wish I could retract. If in the future we want to do the same for stored IMs (i.e. ones that elicited a 202 response), we will not be able to use 'Expires: 0' for this purpose. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 23 13:21:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24873 for ; Tue, 23 Jul 2002 13:21:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29712 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 13:22:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27469; Tue, 23 Jul 2002 12:45:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27436 for ; Tue, 23 Jul 2002 12:44:59 -0400 (EDT) Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22397 for ; Tue, 23 Jul 2002 12:43:57 -0400 (EDT) Message-ID: <20020723164458.80813.qmail@web11604.mail.yahoo.com> Received: from [131.107.3.79] by web11604.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 09:44:58 PDT Date: Tue, 23 Jul 2002 09:44:58 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header To: "Vijay K. Gurbani" Cc: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, adam@dynamicsoft.com, sip@ietf.org In-Reply-To: <3D3D7890.9040207@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm not necessarily disagreeing with you. I think the problem is that people have different notions of what "stale" means for a MESSAGE request. Does stale simply mean the message is old or does it imply that the message is invalid in some sense? Would you render a "stale" MESSAGE to the user or should the User Agent drop it on the floor? I don't see how "Expires: 0" could be used to retract an instant message. My interpretation of "Expires: 0" is that if it hit an intermediary which could not immediately deliver the MESSAGE to the appropriate destination, it would not store the MESSAGE and return a 202, rather it would return something like a 480 response. /sean --- "Vijay K. Gurbani" wrote: > Sean Olson wrote: > > I fail to see why Expires: 0 means the message > > will never expire. How does 0 equate to infinity? > > > > An Expires: 0 from the sender, in my opinion, > > should indicate that this message should be > delivered > > immediately or not at all. I don't think it should > > be used for the sender (or gateway or proxy) to > > indicate that a message is "stale". > > Staleness is what 'Expires: 0' currently implies for > REGISTER > and SUBSCRIBE. And I realize that I am fighting a > loosing battle, > but for all it is worth, it will be good to accord > only that semantic > to 'Expires: 0', and no more. > > Now, before everyone flames me, I do realize that > the MESSAGE I-D does > not allow for this behavior, nor are there any > requirements in > section 5.4 of RFC 2779 to that effect. But there > have been many > times when I have sent an email which I wish I could > retract. If > in the future we want to do the same for stored IMs > (i.e. ones that > elicited a 202 response), we will not be able to use > 'Expires: 0' for > this purpose. > > - vijay > -- > Vijay K. Gurbani > vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and > Services > Lucent Technologies/Bell Labs Innovations, 2000 > Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 > 0216 > __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jul 23 15:30:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00730 for ; Tue, 23 Jul 2002 15:30:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11473 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 15:31:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08289; Tue, 23 Jul 2002 14:53:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08260 for ; Tue, 23 Jul 2002 14:53:49 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29000 for ; Tue, 23 Jul 2002 14:52:46 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6NIrHR15428 for ; Tue, 23 Jul 2002 14:53:17 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id <3963BZYW>; Tue, 23 Jul 2002 19:53:16 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EA5F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'hisham.khartabil@nokia.com'" , seancolson@yahoo.com, bcampbell@dynamicsoft.com, vkg@lucent.com Cc: adam@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] Re: [Simple] -05 MESSAGE and Expires header Date: Tue, 23 Jul 2002 19:53:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org To the best of my knowledge, emergency calls have no more requirement for immediate delivery over and above any other SIP call. There is a requirement of guarantee of reliable delivery to an appropriate emergency service answer point. In the case of local network congestion, all callers, including callers of the emergency service, will have equal difficulty in getting their INVITE through. IEPREP is not dealing with emergency service, IEPREP is dealing with the ability of preferential authenticated callers to make calls at times of an emergency with preferential allocation of resources to make that call possible. These could potentially additionally be emergency service calls, but are more likely to be the chief of fire service calling local water supply chief or any other similar form of communication. IEPREP is also meant to state requirements. Therefore any decision on what the protocol does in any particular condition, and what protocol is required to meet the requirements, rests with SIP, not with IEPREP, even when the issue is an IEPREP requirements statement. Keith > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 23 July 2002 08:51 > To: seancolson@yahoo.com; bcampbell@dynamicsoft.com; vkg@lucent.com > Cc: adam@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] Re: [Simple] -05 MESSAGE and Expires header > > > I would like some interpretation for a few messages in terms > of immediate delivery, urgency and expiration of a message: > > 1. > MESSAGE ... > Priority: non-urgent > Expires: 0 > ... > I'm leaving for lunch right now > > 2. > MESSAGE ... > Priority: emergency > Expires: 3600 > ... > your house is on fire > > 3. > MESSAGE ... > ... > Date: Tue, 23 Jul 2002 7:25:00 GMT > Expires: 60 > > 4. > MESSAGE ... > ... > Date: Tue, 23 Jul 2002 7:25:00 GMT > Expires: 0 > > > Do messages 1 and 2 get immediate delivery? > > Another question: This immediate delivery debate is only > talking about Store and Forward type of servers of gateways. > What about other intermediaries? They certainly can't use the > expires-header to decide on speed of delivery of a message. > We need a new mechanism here. Again I ask the question: Is > this done in IEPREP? > > Regards, > Hisham > > > -----Original Message----- > > From: ext Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Tuesday, July 23, 2002 9:39 AM > > To: Khartabil Hisham (NMP/Helsinki); bcampbell@dynamicsoft.com; > > vkg@lucent.com > > Cc: adam@dynamicsoft.com; sip@ietf.org > > Subject: RE: [Sip] Re: [Simple] -05 MESSAGE and Expires header > > > > > > I fail to see why Expires: 0 means the message > > will never expire. How does 0 equate to infinity? > > > > An Expires: 0 from the sender, in my opinion, > > should indicate that this message should be delivered > > immediately or not at all. I don't think it should > > be used for the sender (or gateway or proxy) to > > indicate that a message is "stale". > > > > By stale, > > I assume you mean a message that was intended for > > immediate delivery, but was actually stored instead > > -- this is not something existing SIP headers do a > > good job of representing. I wouldn't try to hack > > Expires: to fit this. Furthermore, I don't think > > this is a problem that the message draft should have > > to solve. Until someone comes up with a more complete > > draft for offline message retrieval, I think we can > > punt this. Or is that what you were offering to do? > > > > > > --- hisham.khartabil@nokia.com wrote: > > > So, a MESSAGE with Expires: 10 means it has 10 > > > seconds before it's stale while a MESSAGE with > > > Expires: 0 means it will never be stale? > > > > > > How do u inform the receiver that a message is > > > stale? > > > > > > /Hisham > > > > > > > -----Original Message----- > > > > From: ext Sean Olson [mailto:seancolson@yahoo.com] > > > > Sent: Monday, July 22, 2002 8:07 PM > > > > To: Ben Campbell; Vijay K. Gurbani > > > > Cc: Adam Roach; SIP LIST > > > > Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and > > > Expires header > > > > > > > > > > > > So we have three things we might want to > > > > represent: > > > > > > > > 1) Priority -- we use the Priority header for this > > > > 2) Timeliness of content -- we use Expires: header > > > > for this > > > > 3) Urgency -- we don't currently have a way to > > > > represent this > > > > > > > > Obviously 2 & 3 are related but not identical. > > > > The message doesn't have to be urgent in order > > > > for you to request immediate delivery. I think > > > > solving (2) is enough for now. It is the more > > > > interesting case for gateways and other > > > > intermediaries that have to decide between a > > > > store-and-forward or immediate delivery approach. > > > > In other words, stick with what we have today in > > > > the draft. > > > > > > > > /sean > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Yahoo! Health - Feel better, live better > > > > http://health.yahoo.com > > > > > > > > _______________________________________________ > > > > Sip mailing list > > > https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP > > > Protocol > > > > Use sip-implementors@cs.columbia.edu for questions > > > on current sip > > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Health - Feel better, live better > > http://health.yahoo.com > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jul 23 16:12:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02643 for ; Tue, 23 Jul 2002 16:12:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15049 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 16:13:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13125; Tue, 23 Jul 2002 15:46:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13078 for ; Tue, 23 Jul 2002 15:45:54 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01587 for ; Tue, 23 Jul 2002 15:44:48 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6NJjH712111; Tue, 23 Jul 2002 15:45:17 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA07730; Tue, 23 Jul 2002 14:45:16 -0500 (CDT) Message-ID: <3D3DB234.4090100@lucent.com> Date: Tue, 23 Jul 2002 14:44:52 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: bcampbell@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header References: <20020723164458.80813.qmail@web11604.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean Olson wrote: [...] > I don't see how "Expires: 0" could be used to > retract an instant message. It can't right now; and there aren't any requirements for it either. However, by using 'Expires: 0' to mean immediate delivery now, we may be closing the door on using it for retraction in the future. I am of the opinion that there is another header which can provide immediate delivery (maybe not a best fit, but all the same, an alternative to overloading 'Expires: 0'). Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jul 23 18:27:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06180 for ; Tue, 23 Jul 2002 18:27:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22467 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 18:28:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22114; Tue, 23 Jul 2002 18:08:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22085 for ; Tue, 23 Jul 2002 18:08:10 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05730 for ; Tue, 23 Jul 2002 18:07:07 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6NM7shZ082134; Tue, 23 Jul 2002 17:07:55 -0500 (CDT) Message-ID: <3D3DD3A3.8070309@dynamicsoft.com> Date: Tue, 23 Jul 2002 17:07:31 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , SIP LIST CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, dsardana@seven.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com References: <3D3C2FBC.1090205@dynamicsoft.com> <3D3DD086.3070903@dynamicsoft.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Simple] -05 MESSAGE and Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I concur. I have had many responses suggesting we leave it alone, and only a couple of people arguing for a change. The draft currently leaves most of the handling of Expires as a matter of local policy. I think that is the appropriate level of detail for the MESSAGE specification. Since the majority of the controversy concerns store and forward relays, I will echo Sean's statement that if we choose to standardize such relays, that specification if free to further constrain relay behavior. Also, as mentioned in the wg meeting, this discussion belongs on the SIP list, as it concerns a SIP work item. I have tried moving it there, but it doesn't seem to stick. Please direct any future discussion to the SIP list. Jonathan Rosenberg wrote: > I still believe that we should follow Robert's advice as offered in the > SIMPLE session. We are now down to arguing the interpretation of the > terms priority, urgency, and expiration. This is an argument for which > there is no right answer. Since 3261 allows each method to define a > method-specific meaning for Expires, we are well within the scope of the > specifications. No one has found a technical flaw in this approach. At > least several people (myself included) feel its reasonable if not > perfect. Robert's advice was to leave it be unless people found it to be > broken. I would rather finish this specification finally, rather than > debating the relative interpretations of the terms in play here. > > -Jonathan R. > > Ben Campbell wrote: > >> hisham.khartabil@nokia.com wrote: >> >>> Well, you read my mind. I wanted to get consensus that Priority header >> >> >> is for user interface purposes only before I do so. >> >> As I mentioned in a separate mail, priority _can_ be used for routing >> purposes. But it means something different than urgency. >> >> >>> Should we do something like that or are these issues part of the >> >> >> ieprep work? >> >>> Regards, >>> Hisham >>> >>> >>> >>>> -----Original Message----- >>>> From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>>> Sent: Monday, July 22, 2002 4:51 PM >>>> To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach >>>> Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com; >>>> Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com >>>> Subject: RE: [Simple] -05 MESSAGE and Expires header >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>> - When is a message urgent but does not require immediate delivery? >>>> >>>> >>>> Are you proposing an "Urgency" header, or confusing priority with >>>> urgency? I'll see if I can accurately demonstrate their orthangonality. >>>> >>>> High Priority, Low Urgency: >>>> Note to new residents: failure to file income taxes by April >>>> 15th can lead to substantial penalties. >>>> >>>> Low Priority, High Urgency: >>>> You have 5 minutes to come by and pick up the rest of your lunch >>>> or I'm going to throw it away. >>>> High Priority, High Urgency: >>>> There's a tornado coming your way! >>>> >>>> Low Priority, Low Urgency: >>>> Llamas can make four distinct noises: humming, clucking, orgling, and >>>> a high pitched, rhythmic alarm sound. >>>> >>>> /a >>>> >>> >>> >> >> >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jul 23 18:34:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06275 for ; Tue, 23 Jul 2002 18:34:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23125 for sip-archive@odin.ietf.org; Tue, 23 Jul 2002 18:35:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22195; Tue, 23 Jul 2002 18:09:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22169 for ; Tue, 23 Jul 2002 18:09:02 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05756 for ; Tue, 23 Jul 2002 18:07:59 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6NM8mhZ082208; Tue, 23 Jul 2002 17:08:49 -0500 (CDT) Message-ID: <3D3DD3D9.5020706@dynamicsoft.com> Date: Tue, 23 Jul 2002 17:08:25 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , SIP LIST CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, dsardana@seven.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com References: <3D3C2FBC.1090205@dynamicsoft.com> <3D3DD086.3070903@dynamicsoft.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Simple] -05 MESSAGE and Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I concur. I have had many responses suggesting we leave it alone, and only a couple of people arguing for a change. The draft currently leaves most of the handling of Expires as a matter of local policy. I think that is the appropriate level of detail for the MESSAGE specification. Since the majority of the controversy concerns store and forward relays, I will echo Sean's statement that if we choose to standardize such relays, that specification if free to further constrain relay behavior. Also, as mentioned in the wg meeting, this discussion belongs on the SIP list, as it concerns a SIP work item. I have tried moving it there, but it doesn't seem to stick. Please direct any future discussion to the SIP list. Jonathan Rosenberg wrote: > I still believe that we should follow Robert's advice as offered in the > SIMPLE session. We are now down to arguing the interpretation of the > terms priority, urgency, and expiration. This is an argument for which > there is no right answer. Since 3261 allows each method to define a > method-specific meaning for Expires, we are well within the scope of the > specifications. No one has found a technical flaw in this approach. At > least several people (myself included) feel its reasonable if not > perfect. Robert's advice was to leave it be unless people found it to be > broken. I would rather finish this specification finally, rather than > debating the relative interpretations of the terms in play here. > > -Jonathan R. > > Ben Campbell wrote: > >> hisham.khartabil@nokia.com wrote: >> >>> Well, you read my mind. I wanted to get consensus that Priority header >> >> >> is for user interface purposes only before I do so. >> >> As I mentioned in a separate mail, priority _can_ be used for routing >> purposes. But it means something different than urgency. >> >> >>> Should we do something like that or are these issues part of the >> >> >> ieprep work? >> >>> Regards, >>> Hisham >>> >>> >>> >>>> -----Original Message----- >>>> From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>>> Sent: Monday, July 22, 2002 4:51 PM >>>> To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach >>>> Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com; >>>> Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com >>>> Subject: RE: [Simple] -05 MESSAGE and Expires header >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>> - When is a message urgent but does not require immediate delivery? >>>> >>>> >>>> Are you proposing an "Urgency" header, or confusing priority with >>>> urgency? I'll see if I can accurately demonstrate their orthangonality. >>>> >>>> High Priority, Low Urgency: >>>> Note to new residents: failure to file income taxes by April >>>> 15th can lead to substantial penalties. >>>> >>>> Low Priority, High Urgency: >>>> You have 5 minutes to come by and pick up the rest of your lunch >>>> or I'm going to throw it away. >>>> High Priority, High Urgency: >>>> There's a tornado coming your way! >>>> >>>> Low Priority, Low Urgency: >>>> Llamas can make four distinct noises: humming, clucking, orgling, and >>>> a high pitched, rhythmic alarm sound. >>>> >>>> /a >>>> >>> >>> >> >> >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 08:06:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01702 for ; Wed, 24 Jul 2002 08:06:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA04460 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 02:23:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20125; Wed, 24 Jul 2002 01:52:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20092 for ; Wed, 24 Jul 2002 01:52:54 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16511 for ; Wed, 24 Jul 2002 01:51:51 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6O5qIYH017609; Wed, 24 Jul 2002 01:52:18 -0400 (EDT) Message-ID: <3D3E4091.8030200@dynamicsoft.com> Date: Wed, 24 Jul 2002 01:52:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Changes from bis-09 to RFC 3261 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, There were approximately 150 changes made to bis-09 for the generation of RFC 3261. Coming up with this list was an exercise in extremely detailed and painful review of the document, something which took us a great deal of time. The vast majority of these were typos, comma insertions, indentation fixes, and so on. However, there were a few dozen changes that reflect "bug fixes" which were reported between bis-09 and RFC 3261. Here is a summary of those of any significance whatsoever (you will find most to be trivial): * The definition of header field was not quite right. We corrected it to: Header Field: A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row. * The definition and mechanisms for URL encoding were based on a normative reference to RFC 1738. This RFC has been obsoleted by RFC 2396. The references were updated to point to RFC 2396, and RFC 1738 was removed from the list of references. * The specification did not define the default language for text body parts. HTTP specifies that it's ISO-8859-1. Our reference to HTTP 1.1 for the definition of the Content-Type header would lead you to believe that this is the default for SIP too. However, since SIP uses UTF-8, this default makes no sense. So, we have explicitly stated that the default charset is UTF-8. You will find this text in section 7.4.1: "SIP messages MAY contain binary bodies or body parts. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "UTF-8". " * There are constraints on when a UAS can be stateless. Stateless UAS are really meant for handling unauthenticated requests, and are not a general behavior. As an example, you can't really be a stateless registrar. This is now explicitly called out in Section 8.2.7, first paragraph: "..the response and resends it, just as if it were replying to the first instance of the request. A UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical. This rules out stateless registrars, for example." * It was pointed out that the rules for matching a CANCEL to its transaction were not quite right if you went through the formal process. We've corrected that, with the new text in Section 9.2, paragraph 1: "The TU determines the transaction to be cancelled by taking the CANCEL request, and then assuming that the request method is anything but CANCEL or ACK and applying the transaction" ^^^^^^ * Bis-09 defined the behavior of CANCEL on any method besides CANCEL as a "no-op". However, it didn't define what no-op meant. So, we removed the term no-op. The text, in Section 9.2, paragraph 4, now reads: "A CANCEL request has no impact on the processing of transactions with any other method defined in this specification." * The specification was inconsistent in its interpretation of a missing Expires header and expires contact param in a REGISTER request. One section said it meant the client means for 3600, the other said it was a server defined minimum. With the new rules on the inability of a server to reduce the client requested value, there would be no way to have the client allow the server to choose unless we went with the latter definition. So, we did. Section 10.2.1.1, last paragraph, now reads: "If neither mechanism for expressing a suggested expiration time is present in a REGISTER, the client is indicating its desire for the server to choose." * In REGISTER requests, the "scope" of the q-value was defined to be relative to "other bindings present in the REGISTER message or existing within the location service of the registrar". Those are two different scopes. Which is it? Its the location service within the registrar. The text in Section 10.2.1.2 now reads: "The "q" parameter indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record." * bis-09 was inconsistent in its failure handling for REGISTER between Contact: * and a URI in the Contact header. In the former case, an out of sequence REGISTER did not update the specific binding with the ordering failure, but the others could be updated, and in the latter case, the update failed. Since we have specified that all request processing is atomic, the Contact: * treatment was not right. Therefore, the text in bullet 6 of Section 10.3 was updated to indicate that the update is aborted, and the request fails, in the event of a sequence error. * The wording in section 10.3, bullet 7, was inconsistent. On one hand, it said the server had to use values when explicitly specified, but also said that it could shorten the interval. This has been clarified. The values in the Expires header or expires contact param are the client requested expirations, and the server can shorten those. * A question arose as to whether a forked INVITE request resulted in multiple offer/answer exchanges (one for each dialog established) or just one offer/answer exchange. Its multiple. This has been clarified in Section 13.2.1, paragraph 8: "..parameters that apply to those means, and addresses for receiving media from the offerer. An offer/answer exchange is within the context of a dialog, so that if a SIP INVITE results in multiple dialogs, each is a separate offer/answer exchange." * Text in bis-09 seemed to imply that you could always generate a new offer in a request as long as you had no outstanding offers. However, thats true in addition to any method-specific rules, such as the ones outline for UPDATE. This has been clarified in Section 13.2.1, bullet 4: "After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in requests based on rules specified for that method, but only if it has received answers to any previous offers, and has not sent any offers to which it hasn't gotten an answer." * Similarly, there was some text in bis-09 which led you to believe that were only two possible offer/answer exchanges (INVITE/200 or 200/ACK) that were EVER possible. Thats not right. Its only the case for elements compliant to bis alone. If you support UPDATE, there are more possible. This is clarified in Section 13.2.1, 4th from last paragraph: "Concretely, the above rules specify two exchanges for UAs compliant to this specification alone - the offer is in...." * The rules for timer C in bis-09 might lead you to believe that retransmits of the INVITE can refresh timer C. Thats not so; its only provisional responses. This is now clarified in Section 13.3.1.1, next to last paragraph: "A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction." * There was some confusion reported at sipit over whether a branch ID needs to be distinct for each transaction through a spiral. Many implementations apparently were inserting the same branch ID in each pass, which is not right. This has been clarified in Section 16.6, bullet point 8, first paragraph: "This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch, and contain the requisite magic cookie. Note that this implies that the branch parameter will be different for different instances of a spiraled or looped request through a proxy." * The recommended algorithm for computing a branch ID in Section 16.6, bullet point 8, omitted the Via header in the hash. Its now been included. ^^^^^^^^^^ * The spec was inconsistent in UA and proxy handling of transport failures. A proxy was supposed to return a 400, whilst a UA, a 503. Its been made consistent to 503. This results in a change in the text of Section 16.9, which now reads: "If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response." * It was reported that the processing of timer D in the transaction layer was wrong. This is the timer that fires in the INVITE client transaction after it has ceased waiting for retransmits of the final response, in order to send an ACK. Bis-09 said to inform the TU of a timeout. However, this is not a failure condition, so that makes no sense. As such, Section 17.1.1.2, now reads: "If timer D fires while the client transaction is in the "Completed" state, the client transaction MUST move to the terminated state." ^ * Bis-09 defined a response retransmission as any response that matches a transaction matched by a previous response. Thats true ONLY for final responses. It doesn't work for provisional. Since there is no normative text associated with the term "response retransmission", we removed this definition entirely from Section 17.1.3. * We clarified that, when moving to terminated state for client invite transactions, you need to delete the transaction immediately. * The rules in Section 17.2.3, for matching a request to a transaction when the branch ID had the cookie, were not quite right. In particular, they were wrong for CANCEL. The rules were updated: The request matches a transaction if: 1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and 2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and 3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE. * Section 18.1.1 led you to believe that if a request was too large for UDP, and you resent it, it had to be with TCP. ACtually, it can be with any congestion controlled transport (as defined by RFC 2914). We also clarified that if you change transports, the Via transport value needs to change. * Section 19.1.4, 4th bullet, had made reference to characters in the unsafe character set, indicating that those needed to be escape-encoded in URLs. However, RFC 2396 doesn't define "unsafe" characters - that is legacy from RFC 1738, which is obsoleted by 2396. So, the mention of unsafe characters was removed. * It was pointed out that the lexical reordering rules for converting a tel URL to a SIP URL could result in a user part that was not a valid telephone-subscriber as defined in RFC 2806. The specific problem is that 2806 requires the isdn-subaddress and post-dial parameters to appear before any extension parameters. If you simply order the parameters without excepting these two, you might place an extension param before post-dial or isdn-subaddress, which is illegal. This has been fixed, including an example which had this problem. See Section 19.1.6. * It was pointed out that the definition of "optional" headers in table 2/3 only discussed UA insertion of the header. However, some optional headers are only inserted by proxies (such as Record-Route). So, the definition of optional in Section 20 was updated to include any element, not just a UA. * There were a bunch of places were the spec said "the syntax of this header is defined in Section XXX of [HXXX], referring to RFC 2616. However, we incorporated most of that syntax into bis, so these statements were no longer correct. They were removed. * Rules for equality matching of From and To header fields were absent, even though there were references elsewhere in the text to the existence of such rules. They were added. See Sections 20.20 and 20.39. * Section 20.22 indicated that the recommended value for Max-Forwards is 70. Of course, that is the recommended INITIAL value. That was clarified. * The qop="auth" attribute was missing from the example Proxy-Authenticate message in Section 20.27. It was added. It was also missing from Section 20.44, and was added there too. * The spec was inconsistent on the maximum value of the expires Contact parameter and the Expires header field. They were made consistent. The maximum value is (2**32)-1. * Table 2/3 indicated that Retry-After was allowed in the 500 and 503 response codes, but Section 20.33 only mentioned the 503 response code. Section 20.33 was updated to include the 500 code as well. * Section 20.35, on the Server header, had an example which led you to believe that the field was used by proxy servers. Its not - its just UAS. The example was updated to fix that. * Section 20.37, on the Unsupported header field, failed to mention that a compact form was defined (the other headers with compact forms explicitly mention it in their section 20's). A mention was added. * The transaction matching algorithm requires rules for equality of Via header fields, but none was defined. A rule was added, see Section 20.42. * Section 21.4.15 indicated that inclusion of the unsupported extensions in a 420 response was a SHOULD. This is inconsistent with other text that said it was a MUST. Its a MUST. Section 21.4.15 was updated to reflect that. * Section 22.3 mentioned that "Proxy-Authentication" header, which doesn't exist. Its "Proxy-Authenticate". It was fixed. * Some text in Section 23.2, paragraph 3, was missing in bis-09 because of a latex conversion error. Specifically, the text should have said that the body is structured as an S/MIME multipart/signed CMS SignedData body. Its been fixed. * Section 23.3 had an example with the Content-Transfer-Encoding header in it. This header is no longer used, and so was removed. * Section 24.1, last paragraph, message F2, was missing the tag in the To field. It was added. * Section 26.2.1 had a mention of the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite, but had no reference to where such a suite is defined. Its RFC 3268, and a reference to that was added. * The BNF had this construct where there was a list of choices, and one of the elements in the choice was optional: foo = bar / baz / [boo] turns out, this is actually not right, since it allows for an empty value for foo, which is not what is intended. Therefore, the text that described this convention, and all usages of it in the BNF, were removed. * The BNF for the user part of the SIP/SIPS URI allowed for an empty username and an @ sign; that is "sip:@foo.com" was valid according to the BNF. Its not. The BNF for the SIP-URI and SIPS-URI constructions was updated to correct this. Here is the change that was made (^ characters indicate where the change is): OLD SIP-URI = "sip:" [ userinfo "@" ] hostport uri-parameters [ headers ] SIPS-URI = "sips:" [ userinfo "@" ] hostport uri-parameters [ headers ] userinfo = [ user / telephone-subscriber [ ":" password ]] user = *( unreserved / escaped / user-unreserved ) NEW SIP-URI = "sip:" [ userinfo ] hostport ^^ delete "@" uri-parameters [ headers ] SIPS-URI = "sips:" [ userinfo ] hostport ^^ delete "@" uri-parameters [ headers ] userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" ^ ^ ^^^^ user = 1*( unreserved / escaped / user-unreserved ) ^ * The Accept, Accept-Encoding, and Accept-Language and Allow BNF were all updated to allow for the header to have an empty value. * The BNF for rfc1123-date was wrong. It was missing a space after the comma. It was corrected thusly: OLD rfc1123-date = wkday "," date1 SP time SP "GMT" NEW rfc1123-date = wkday "," SP date1 SP time SP "GMT" ^^ * The BNF for the Timestamp header was wrong. It was missing an explicit LWS between the the send time and the delay. It was added. The BNF was changed thusly: OLD Timestamp = "Timestamp" HCOLON 1*(DIGIT) [ "." *(DIGIT) ] [ delay ] NEW Timestamp = "Timestamp" HCOLON 1*(DIGIT) [ "." *(DIGIT) ] [ LWS delay ] ^^^ THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 08:32:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09306 for ; Wed, 24 Jul 2002 08:32:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20887 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 08:34:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16966; Wed, 24 Jul 2002 08:08:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16935 for ; Wed, 24 Jul 2002 08:08:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01914 for ; Wed, 24 Jul 2002 08:07:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6O8Hwi19818 for ; Wed, 24 Jul 2002 11:17:58 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Jul 2002 11:17:25 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 11:17:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 24 Jul 2002 11:17:24 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20400@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] -05 MESSAGE and Expires header Thread-Index: AcIyrqiDCYKZXWuhSvaKhlIo1ee8BAAOpbMQ To: , X-OriginalArrivalTime: 24 Jul 2002 08:17:25.0255 (UTC) FILETIME=[8AD20170:01C232EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA16936 Subject: [Sip] RE: [Simple] -05 MESSAGE and Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit We don't want the expires-header to be used as a source for routing decisions. We also don't want to special case "expires: 0". Why should routing depend on the value on the expires header? I quote Jonathan "The general notion is that it indicates a lifetime of something; a point after which the thing is no longer valid." You to have some general meaning of expires, otherwise I can say expires of 0 for a new method FOO means "don't FOO me back" or "explode your phone". If the general notion is what Jonathan said above (and what Adam said below), then Expires: 0 in a MESSAGE means that the MESSAGE expiration occurs in zero seconds. It doesn't mean immediate delivery. I think the best thing to do is to remove the text. Other methods don't define the meaning of "Expires: 0". Regards, Hisham > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Wednesday, July 24, 2002 4:09 AM > To: 'Bobby Sardana'; Adam Roach > Cc: Jonathan Rosenberg; Ben Campbell; Khartabil Hisham (NMP/Helsinki); > vkg@lucent.com; Ya-Ching.Tan@icn.siemens.de; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] -05 MESSAGE and Expires header > > > > -----Original Message----- > > From: Bobby Sardana [mailto:dsardana@seven.com] > > > > The proposal is simple: (not sure from a complete > > applicability point of > > view, but here it is) > > > > a. Expire signifies a unit of time > > Agreed. > > > b. For methods that have the Expire header, the unit of time > > determines > > the method validitity. > > There's a problem with that approach. For SUBSCRIBE and REGISTER, > the "Expires" header doesn't indicate the period of validity of > the request (which is presumably what you mean by "method validity"); > it indicates the period of validity for what is *created* by the > request. The analog for INVITE would be "Session-Expires". > > > The only exception here is 0, which can mean > > "expired" or "infinite". > > There are actually three problems here. > > 1. Historically, "0" has never been treated > as a special case in SIP expirations. (More > on this below). > > 2. "Expires: 0" does not mean "expired" (that > would, in theory, be represented by a negative > number -- but we don't do that); it means that > expiration occurs in zero seconds (i.e. > instantaneously). For the purposes of instant > messages, that's exactly what we want to convey: > "this mesage expires instantaneously -- so, send > it on or consider it stale" (where handling of > stale messages is a matter of local policy). > > 3. Zero has *never* meant infinity in a SIP > "Expires" context. The convention for "infinity" > is to use 4294967295 (2^32-1), which ends up being > over 136 years -- long enough to mean "infinity" for > the purposes of a computer protocol. > > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 08:35:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09994 for ; Wed, 24 Jul 2002 08:35:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21262 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 08:36:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18484; Wed, 24 Jul 2002 08:17:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18453 for ; Wed, 24 Jul 2002 08:17:17 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04929 for ; Wed, 24 Jul 2002 08:16:13 -0400 (EDT) Received: from jku2.fokus.gmd.de (port-212-202-171-189.reverse.qdsl-home.de [212.202.171.189]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g6O8YBd29340; Wed, 24 Jul 2002 10:34:11 +0200 Message-Id: <5.1.0.14.0.20020724101741.0455c820@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Jul 2002 10:23:23 +0200 To: Sachin Shenoy , sip@ietf.org From: Jiri Kuthan In-Reply-To: <4.3.2.7.1.20020724131427.00ebe770@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Re: [Sip-implementors] Loop detection & Via's branch Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Indeed. Using previous branch in calculating next branch disables loop detection. Sounds like a spec inconsistency. -Jiri (moved to SIP mailing list) At 09:47 AM 7/24/2002, Sachin Shenoy wrote: >Hi, > >In RFC 3261 [16.6 (8)] it says that, for loop detection at proxy, >we should calculate the branch using top most Via header also. >I guess while using top-most Via header we should avoid using the branch. If branch is also used, the loop can go undetected as >the branch could be unique, even when the request has looped. >(8.1.1.7 Says branch has to be unique across space and time). > >Hope I got it right. If I have missed anything please let me >know. > >Thanks >Sachin > > >16.6 (8) >"This is to ensure that if the >request is routed back to the proxy and one of those fields >changes, it is treated as a spiral and not a loop (see Section >16.3). A common way to create this value is to compute a >cryptographic hash of the To tag, From tag, Call-ID header >field, the Request-URI of the request received (before >translation), *the topmost Via header*, and the sequence number >from the CSeq header field, in addition to any Proxy-Require >and Proxy-Authorization header fields that may be present." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 09:33:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15891 for ; Wed, 24 Jul 2002 09:33:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25938 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 09:34:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17310; Wed, 24 Jul 2002 08:10:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17281 for ; Wed, 24 Jul 2002 08:10:49 -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 IAA02900; Wed, 24 Jul 2002 08:09:44 -0400 (EDT) Message-Id: <200207241209.IAA02900@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 24 Jul 2002 08:09:44 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP Refer Method Author(s) : R. Sparks Filename : draft-ietf-sip-refer-06.txt Pages : 21 Date : 23-Jul-02 This document defines the REFER method. This SIP extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the the refer event package and the Refer-To request header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-refer-06.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-refer-06.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: <20020723150338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020723150338.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 10:03:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17581 for ; Wed, 24 Jul 2002 10:03:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27966 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 10:04:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26510; Wed, 24 Jul 2002 09:43:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26065 for ; Wed, 24 Jul 2002 09:36:16 -0400 (EDT) Received: from esuims01.esamsungumit.com (mail.esamsungumit.com [203.122.29.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16014 for ; Wed, 24 Jul 2002 09:35:07 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Wed, 24 Jul 2002 19:05:07 +0530 Message-ID: <89CFEE6120A0224EA07781892EC0B48B9040B9@esuims01.esamsungumit.com> Thread-Topic: [Sip] Re: [Simple] -05 MESSAGE and Expires header Thread-Index: AcIybaQ8Nqh0SFiMT4CBtyDZS/gnkAAqQTIQ From: "ShavinderPal Singh" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA26066 Subject: [Sip] Grammar for Refer-To and Referred-By Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Can anyone help me in finding the Grammar for the Refer-To and Referred-By headers, which are present in the REFER message? I could not find their mention in RFC 3261. Thanks & Regards s Ph.: 091-124-6383474 (e 250) __________________________________________ I had a good grip on life, but then the handle broke. -----Original Message----- From: Sean Olson [mailto:seancolson@yahoo.com] Sent: Tuesday, July 23, 2002 10:15 PM To: Vijay K. Gurbani Cc: hisham.khartabil@nokia.com; bcampbell@dynamicsoft.com; adam@dynamicsoft.com; sip@ietf.org Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header I'm not necessarily disagreeing with you. I think the problem is that people have different notions of what "stale" means for a MESSAGE request. Does stale simply mean the message is old or does it imply that the message is invalid in some sense? Would you render a "stale" MESSAGE to the user or should the User Agent drop it on the floor? I don't see how "Expires: 0" could be used to retract an instant message. My interpretation of "Expires: 0" is that if it hit an intermediary which could not immediately deliver the MESSAGE to the appropriate destination, it would not store the MESSAGE and return a 202, rather it would return something like a 480 response. /sean --- "Vijay K. Gurbani" wrote: > Sean Olson wrote: > > I fail to see why Expires: 0 means the message > > will never expire. How does 0 equate to infinity? > > > > An Expires: 0 from the sender, in my opinion, > > should indicate that this message should be > delivered > > immediately or not at all. I don't think it should > > be used for the sender (or gateway or proxy) to > > indicate that a message is "stale". > > Staleness is what 'Expires: 0' currently implies for > REGISTER > and SUBSCRIBE. And I realize that I am fighting a > loosing battle, > but for all it is worth, it will be good to accord > only that semantic > to 'Expires: 0', and no more. > > Now, before everyone flames me, I do realize that > the MESSAGE I-D does > not allow for this behavior, nor are there any > requirements in > section 5.4 of RFC 2779 to that effect. But there > have been many > times when I have sent an email which I wish I could > retract. If > in the future we want to do the same for stored IMs > (i.e. ones that > elicited a 202 response), we will not be able to use > 'Expires: 0' for > this purpose. > > - vijay > -- > Vijay K. Gurbani > vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and > Services > Lucent Technologies/Bell Labs Innovations, 2000 > Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 > 0216 > __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 10:23:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18570 for ; Wed, 24 Jul 2002 10:23:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28676 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 10:24:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26889; Wed, 24 Jul 2002 09:54:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26858 for ; Wed, 24 Jul 2002 09:54:08 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16984 for ; Wed, 24 Jul 2002 09:53:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27322; Wed, 24 Jul 2002 09:53:35 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11623; Wed, 24 Jul 2002 09:53:36 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W9800RB>; Wed, 24 Jul 2002 09:53:35 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B56E8@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'ShavinderPal Singh'" , sip@ietf.org Subject: RE: [Sip] Grammar for Refer-To and Referred-By Date: Wed, 24 Jul 2002 09:53:35 -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@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-06.txt > -----Original Message----- > From: ShavinderPal Singh [mailto:ShavinderPal.Singh@ssdsi.com] > Sent: Wednesday, July 24, 2002 9:35 AM > To: sip@ietf.org > Subject: [Sip] Grammar for Refer-To and Referred-By > > > Hi, > > Can anyone help me in finding the Grammar for the Refer-To and > Referred-By headers, which are present in the REFER message? > I could not find their mention in RFC 3261. > > Thanks & Regards > s > > Ph.: 091-124-6383474 (e 250) > __________________________________________ > I had a good grip on life, but then the handle broke. > > > > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, July 23, 2002 10:15 PM > To: Vijay K. Gurbani > Cc: hisham.khartabil@nokia.com; bcampbell@dynamicsoft.com; > adam@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header > > > I'm not necessarily disagreeing with you. > I think the problem is that people have different > notions of what "stale" means for a MESSAGE request. > Does stale simply mean the message is old or does > it imply that the message is invalid in some sense? > Would you render a "stale" MESSAGE to the user or > should the User Agent drop it on the floor? > > I don't see how "Expires: 0" could be used to > retract an instant message. My interpretation > of "Expires: 0" is that if it hit an intermediary > which could not immediately deliver the MESSAGE > to the appropriate destination, it would not store > the MESSAGE and return a 202, rather it would > return something like a 480 response. > > /sean > > --- "Vijay K. Gurbani" wrote: > > Sean Olson wrote: > > > I fail to see why Expires: 0 means the message > > > will never expire. How does 0 equate to infinity? > > > > > > An Expires: 0 from the sender, in my opinion, > > > should indicate that this message should be > > delivered > > > immediately or not at all. I don't think it should > > > be used for the sender (or gateway or proxy) to > > > indicate that a message is "stale". > > > > Staleness is what 'Expires: 0' currently implies for > > REGISTER > > and SUBSCRIBE. And I realize that I am fighting a > > loosing battle, > > but for all it is worth, it will be good to accord > > only that semantic > > to 'Expires: 0', and no more. > > > > Now, before everyone flames me, I do realize that > > the MESSAGE I-D does > > not allow for this behavior, nor are there any > > requirements in > > section 5.4 of RFC 2779 to that effect. But there > > have been many > > times when I have sent an email which I wish I could > > retract. If > > in the future we want to do the same for stored IMs > > (i.e. ones that > > elicited a 202 response), we will not be able to use > > 'Expires: 0' for > > this purpose. > > > > - vijay > > -- > > Vijay K. Gurbani > > vkg@{lucent.com,research.bell-labs.com,acm.org} > > Wireless Networks Group/Internet Software and > > Services > > Lucent Technologies/Bell Labs Innovations, 2000 > > Lucent Lane, Rm 6G-440 > > Naperville, Illinois 60566 Voice: +1 630 224 > > 0216 > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 10:54:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20140 for ; Wed, 24 Jul 2002 10:54:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01124 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 10:55:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28895; Wed, 24 Jul 2002 10:28:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28862 for ; Wed, 24 Jul 2002 10:28:41 -0400 (EDT) Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18814 for ; Wed, 24 Jul 2002 10:27:32 -0400 (EDT) Received: from [10.10.13.95] (helo=ranjit) by btlmail.bplmail.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17XN1d-0007ZA-00; Wed, 24 Jul 2002 19:52:01 +0530 Message-ID: <006a01c2331e$79915bc0$5f0d0a0a@ranjit> Reply-To: "Ranjit Avasarala" From: "Ranjit Avasarala" To: "ShavinderPal Singh" , References: <89CFEE6120A0224EA07781892EC0B48B9040B9@esuims01.esamsungumit.com> Subject: Re: [Sip] Grammar for Refer-To and Referred-By Date: Wed, 24 Jul 2002 19:59:10 +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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit For Refer-To header refer draft-ietf-sip-refer-06.txt and for referred-by refer draft-ietf-sip-referredby-00.txt HTH Ranjit ----- Original Message ----- From: ShavinderPal Singh To: Sent: Wednesday, July 24, 2002 7:05 PM Subject: [Sip] Grammar for Refer-To and Referred-By > Hi, > > Can anyone help me in finding the Grammar for the Refer-To and > Referred-By headers, which are present in the REFER message? > I could not find their mention in RFC 3261. > > Thanks & Regards > s > > Ph.: 091-124-6383474 (e 250) > __________________________________________ > I had a good grip on life, but then the handle broke. > > > > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, July 23, 2002 10:15 PM > To: Vijay K. Gurbani > Cc: hisham.khartabil@nokia.com; bcampbell@dynamicsoft.com; > adam@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] Re: [Simple] -05 MESSAGE and Expires header > > > I'm not necessarily disagreeing with you. > I think the problem is that people have different > notions of what "stale" means for a MESSAGE request. > Does stale simply mean the message is old or does > it imply that the message is invalid in some sense? > Would you render a "stale" MESSAGE to the user or > should the User Agent drop it on the floor? > > I don't see how "Expires: 0" could be used to > retract an instant message. My interpretation > of "Expires: 0" is that if it hit an intermediary > which could not immediately deliver the MESSAGE > to the appropriate destination, it would not store > the MESSAGE and return a 202, rather it would > return something like a 480 response. > > /sean > > --- "Vijay K. Gurbani" wrote: > > Sean Olson wrote: > > > I fail to see why Expires: 0 means the message > > > will never expire. How does 0 equate to infinity? > > > > > > An Expires: 0 from the sender, in my opinion, > > > should indicate that this message should be > > delivered > > > immediately or not at all. I don't think it should > > > be used for the sender (or gateway or proxy) to > > > indicate that a message is "stale". > > > > Staleness is what 'Expires: 0' currently implies for > > REGISTER > > and SUBSCRIBE. And I realize that I am fighting a > > loosing battle, > > but for all it is worth, it will be good to accord > > only that semantic > > to 'Expires: 0', and no more. > > > > Now, before everyone flames me, I do realize that > > the MESSAGE I-D does > > not allow for this behavior, nor are there any > > requirements in > > section 5.4 of RFC 2779 to that effect. But there > > have been many > > times when I have sent an email which I wish I could > > retract. If > > in the future we want to do the same for stored IMs > > (i.e. ones that > > elicited a 202 response), we will not be able to use > > 'Expires: 0' for > > this purpose. > > > > - vijay > > -- > > Vijay K. Gurbani > > vkg@{lucent.com,research.bell-labs.com,acm.org} > > Wireless Networks Group/Internet Software and > > Services > > Lucent Technologies/Bell Labs Innovations, 2000 > > Lucent Lane, Rm 6G-440 > > Naperville, Illinois 60566 Voice: +1 630 224 > > 0216 > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 12:31:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23155 for ; Wed, 24 Jul 2002 12:31:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08970 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 12:32:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07081; Wed, 24 Jul 2002 12:03:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07050 for ; Wed, 24 Jul 2002 12:03:45 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22350 for ; Wed, 24 Jul 2002 12:02:40 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6OG2nCU018525; Wed, 24 Jul 2002 12:02:50 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306AP5CF>; Wed, 24 Jul 2002 11:03:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A31A@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Adam Roach , sip@ietf.org Subject: RE: [Sip] RE: [Simple] -05 MESSAGE and Expires header Date: Wed, 24 Jul 2002 11:03:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > We don't want the expires-header to be used as a source for > routing decisions. We also don't want to special case "expires: 0". > > Why should routing depend on the value on the expires header? Proxies can route on whatever makes sense for them. If I want a proxy to route based on whether some string appears in the Subject field, I can. If I want it to route based on a hash of the SDP, I can. If I want it to route based on the second digit of the hour portion of the date field, I can. You can argue that such things might not be useful (and I'll agree) but a proxy can make routing decisions based on whatever makes sense for whatever service they are designed to provide. So, if I (as a service provider) want to deploy a node that bases its behavior on the "Expires" header -- either because it makes sense for me, or provides a wanted service for my users -- then that's what I'm going to do. I don't think the MESSAGE spec needs to mention this in any way, though. (As an analogy, 3261 does not mention anything about making routing decisions based on the "Accept-Language" field -- but you can certainly imagine circumstances in which it would make sense to do so). > I think the best thing to do is to remove the text. Other > methods don't define the meaning of "Expires: 0". Except section 10.2.2 of RFC 3261 (REGISTER). And section 3.1.4.3 of RFC 3265 (SUBSCRIBE). While "Expires: 0" isn't a special case, it is (obviously) cause for confusion (otherwise we wouldn't have a huge discussion thread spanning two mailing lists arguing about its meaning). So, from a purely theoretical perspective, your point has some validity: the meaning of "Expires: 0" *can* be deduced using rigorous and consistent thinking. However, from a *practical* perspective, it's obvious that some people would get the semantics of "Expires: 0" wrong unless there is some guidance provided -- and varying semantics will harm interoperability. I argue for a consistent handling, but explicit text the clarifies the issue to leave no room for misinterpretation. I further argue that the current document already satisifies this request. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 12:53:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23723 for ; Wed, 24 Jul 2002 12:53:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09985 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 12:54:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08071; Wed, 24 Jul 2002 12:24:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08034 for ; Wed, 24 Jul 2002 12:24:29 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22921 for ; Wed, 24 Jul 2002 12:23:24 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6OGNvJ28528; Wed, 24 Jul 2002 12:23:57 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA08380; Wed, 24 Jul 2002 11:23:56 -0500 (CDT) Message-ID: <3D3ED47E.4000007@lucent.com> Date: Wed, 24 Jul 2002 11:23:26 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , Ben Campbell CC: sip@ietf.org References: <3D3C2FBC.1090205@dynamicsoft.com> <3D3DD086.3070903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Simple] -05 MESSAGE and Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > Robert's advice was to leave it be unless people found it to be > broken. I would rather finish this specification finally, rather than > debating the relative interpretations of the terms in play here. Jonathan/Ben: It was not my intention to delay the specification when I originally posted this question to the SIMPLE list in Yokohama (heck, I did not even think that it would engender such passion :-)). Out of a set of 9 people who have contributed to this thread, 1/3 (including me) think that 'Expires: 0' should NOT be used. So that settles the issue in favor of keeping status quo. > No one has found a technical flaw in this approach These are the technical flaws as I see them, none of which are show stoppers: (1) Expires is generally considered to be an e2e header; however, MESSAGE I-D uses it for decision making in intermediaries (I will note that even in RFC 3261, it is suggested that proxies not use Expires header in determining when to teardown a session that is being set up) (2) Expires will need to be duplicated in the 'outer' headers if S/MIME is being used The philosophical flaws are probably more egregious; these are: (1) Violates the self-describing aspect of SIP headers by overloading 'Expires: 0' to imply immediate delivery (2) Non-congruence of usage with respect to REGISTER and SUBSCRIBE (3) Leaves open the possibility that future requests will interpret 'Expires: 0' in other unknown subtle ways (4) Why overload it if there is another header that approximates immediate delivery to both intermediaries and end points (5) While IMs send in session mode probably cannot be with- drawn; maybe in the future IMs in page mode could be. For example, an IM with an 'Expires: 60' which elicits a 202 response from a relay, could be retracted. If so, we loose the ability to use 'Expires: 0' for retraction Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 13:57:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25827 for ; Wed, 24 Jul 2002 13:57:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12930 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 13:58:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12118; Wed, 24 Jul 2002 13:32:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12086 for ; Wed, 24 Jul 2002 13:32:26 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25198 for ; Wed, 24 Jul 2002 13:31:21 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OHVeYH017947; Wed, 24 Jul 2002 13:31:41 -0400 (EDT) Message-ID: <3D3EE47A.8090404@dynamicsoft.com> Date: Wed, 24 Jul 2002 13:31:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shingo Fujimoto CC: Henning Schulzrinne , SIP-WG Subject: Re: [Sip] language info in SIP headers References: <3D3D22C6.2080208@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Shingo Fujimoto wrote: > I am happy to hear you already had some discussions. Henning and I were trying to determine the "right" thing to to regarding language tagging, and found, as you are finding, that it is a far from simple answer.... specific comment inline: > > Henning Schulzrinne wrote: > > >>- RFC 2482 or http://www.unicode.org/unicode/reports/tr27/#tag provide >>language tagging, as you noted. While I have not seen an official >>statement from the IESG on this, I believe 10646 language tagging has >>generally been deprecated. It's not quite clear whether the reasons (I >>believe, nesting) for that apply to short text such as Subject or >>Organization. > > > > You are probably right. > > Here is the comment from Ned Freed, one of the RFC2231 authors: > > >>Language indicators in a pure UTF-8 environment like SIP headers have > > to be > >>stored as part of the UTF-8 string itself. The plane 14 language tags > > described > >>in >> >> http://www.unicode.org/unicode/reports/tr27/#tag >> >>are the only means of doing this that I'm aware of. However, the use >>of such tags is, as the text indicates, strongly discouraged. >> >>It is the Unicode Technical Committee's belief that >> >> The requirement for language information embedded in plain text data > > is often > >> overstated. >> >>As such, I see little chance for support for such tagging in the > > context of SIP > >>headers being widely deployed. >> >> Ned I think the point Ned is making here, is that language tagging is not all that useful in practice. With UTF-8, you can render Kanji characters. You need the language tagging IFF some automata needs to do something special based on knowledge of the language, such as translation or text to speech. However, it is far from clear whether that information is truly needed. Translation of names (like those in Subject, From, To) is not likely to work in any case, nor is it clear that the language tag is needed for it... > The reason I prefer this approach is that SIP messages must be small > if it runs over UDP. "language tag" will add only few bytes. > Well, as Ned indicated, and Henning repeated, the in-band language tagging provided by UTF-8 is not considered acceptable, and we would not be able to write a specification which recommends it as the solution for sip. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 15:17:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28662 for ; Wed, 24 Jul 2002 15:17:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17921 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 15:18:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12752; Wed, 24 Jul 2002 13:50:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12721 for ; Wed, 24 Jul 2002 13:50:47 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25693 for ; Wed, 24 Jul 2002 13:49:42 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g6OHoie10324; Wed, 24 Jul 2002 19:50:44 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g6OHohR15863; Wed, 24 Jul 2002 19:50:43 +0200 (MEST) Received: from cs.columbia.edu (mhpa6v8c [139.23.202.84]) by mail-y.mchp.siemens.de with ESMTP id g6OHoacH016941; Wed, 24 Jul 2002 19:50:36 +0200 (MET DST) Message-ID: <3D3EE8BB.1050600@cs.columbia.edu> Date: Wed, 24 Jul 2002 13:49:47 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Shingo Fujimoto , SIP-WG , Ned.Freed@innosoft.com Subject: Re: [Sip] language info in SIP headers References: <3D3D22C6.2080208@jp.fujitsu.com> <3D3EE47A.8090404@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I think the point Ned is making here, is that language > tagging is not all that useful in practice. With UTF-8, > you can render Kanji characters. You need the language > tagging IFF some automata needs to do something special > based on knowledge of the language, such as translation > or text to speech. However, it is far from clear whether > that information is truly needed. Translation of names > (like those in Subject, From, To) is not likely to work > in any case, nor is it clear that the language tag is > needed for it... You're about to step into the Han unification minefield. From my limited understanding, the same Unicode/10646 code point is rendered differently depending on the language (Japanese, Chinese, etc.). I don't know if this is also true for text-to-speech. Certainly, text-to-speech is useful for all three headers, e.g., in a voicemail system. Jonathan Rosenberg ;lang=de and Jonathan Rosenberg ;lang=en sound very different. > Well, as Ned indicated, and Henning repeated, the in-band > language tagging provided by UTF-8 is not considered > acceptable, and we would not be able to write a specification > which recommends it as the solution for sip. I think he meant the ?=jp? marking, not UTF-8 language tagging. (That said, it isn't clear to me why this would be inherently better, except maybe to avoid tripping non-language-tag-capable 10646 renderers and annoy the user with random characters instead... The arguments against tagging seem to be about the same in either syntax - nesting, and all that.) A pragmatic choice is to say that To/From don't need UTF or ?=? tagging, since ;language=jp will work just fine, without annoying users with random ASCII art. The Subject header is more difficult, but there, a smart text-to-speech renderer can usually guess at the language by checking its dictionary. From my vague recollection, very few words are needed to do fairly accurate language recognition, excepting deliberate attempts to create phrases that are meaningful in two languages. Google seems to do an ok guessing job on most web pages, for example. (Guessing isn't pretty, but many users aren't going to bother marking their Subject line anyway and routinely use multiple languages, so that device configuration isn't sufficient.) > > -Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 17:18:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02934 for ; Wed, 24 Jul 2002 17:18:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26488 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 17:19:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24276; Wed, 24 Jul 2002 16:46:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24247 for ; Wed, 24 Jul 2002 16:46:11 -0400 (EDT) Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02139 for ; Wed, 24 Jul 2002 16:45:06 -0400 (EDT) Message-ID: <20020724204608.49648.qmail@web11602.mail.yahoo.com> Received: from [131.107.3.70] by web11602.mail.yahoo.com via HTTP; Wed, 24 Jul 2002 13:46:08 PDT Date: Wed, 24 Jul 2002 13:46:08 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] language info in SIP headers To: Henning Schulzrinne , Jonathan Rosenberg Cc: Shingo Fujimoto , SIP-WG , Ned.Freed@innosoft.com In-Reply-To: <3D3EE8BB.1050600@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Is there a problem to be solved here that cannot be handled by Accept-Language and Content-Language? I realize these only cover the payload and not the headers. My assumption is that most of the information that you would need to extract from the headers can either be treated as a string of octets by an automata -or- is for human consumption and therefore it is sufficient if these can be rendered appropriately to the end user (ignoring the Han unification problem for now) which UTF-8 should cover. Proper names as in the From/To are a good example of this. What automata application cannot make use of the Accept-Language header to do its job? (I'm not saying one does not exist, I would just like clarification of the problem we are trying to solve here) Regards, Sean Olson --- Henning Schulzrinne wrote: > > I think the point Ned is making here, is that > language > > tagging is not all that useful in practice. With > UTF-8, > > you can render Kanji characters. You need the > language > > tagging IFF some automata needs to do something > special > > based on knowledge of the language, such as > translation > > or text to speech. However, it is far from clear > whether > > that information is truly needed. Translation of > names > > (like those in Subject, From, To) is not likely to > work > > in any case, nor is it clear that the language tag > is > > needed for it... > > You're about to step into the Han unification > minefield. From my limited > understanding, the same Unicode/10646 code point is > rendered differently > depending on the language (Japanese, Chinese, etc.). > I don't know if > this is also true for text-to-speech. Certainly, > text-to-speech is > useful for all three headers, e.g., in a voicemail > system. Jonathan > Rosenberg ;lang=de and Jonathan Rosenberg ;lang=en > sound very different. > > > Well, as Ned indicated, and Henning repeated, the > in-band > > language tagging provided by UTF-8 is not > considered > > acceptable, and we would not be able to write a > specification > > which recommends it as the solution for sip. > > I think he meant the ?=jp? marking, not UTF-8 > language tagging. (That > said, it isn't clear to me why this would be > inherently better, except > maybe to avoid tripping non-language-tag-capable > 10646 renderers and > annoy the user with random characters instead... The > arguments against > tagging seem to be about the same in either syntax - > nesting, and all that.) > > A pragmatic choice is to say that To/From don't need > UTF or ?=? tagging, > since ;language=jp will work just fine, without > annoying users with > random ASCII art. The Subject header is more > difficult, but there, a > smart text-to-speech renderer can usually guess at > the language by > checking its dictionary. From my vague recollection, > very few words are > needed to do fairly accurate language recognition, > excepting deliberate > attempts to create phrases that are meaningful in > two languages. Google > seems to do an ok guessing job on most web pages, > for example. (Guessing > isn't pretty, but many users aren't going to bother > marking their > Subject line anyway and routinely use multiple > languages, so that device > configuration isn't sufficient.) > > > > > -Jonathan R. > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 17:41:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03347 for ; Wed, 24 Jul 2002 17:41:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27846 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 17:43:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26306; Wed, 24 Jul 2002 17:14:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26278 for ; Wed, 24 Jul 2002 17:14:44 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02826 for ; Wed, 24 Jul 2002 17:13:39 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6OLEYwh024390; Wed, 24 Jul 2002 17:14:34 -0400 (EDT) Received: from cs.columbia.edu (dialin-212-144-146-010.arcor-ip.net [212.144.146.10]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g6OLEQKM018604 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 Jul 2002 17:14:30 -0400 (EDT) Message-ID: <3D3F187A.8090601@cs.columbia.edu> Date: Wed, 24 Jul 2002 17:13:30 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: Jonathan Rosenberg , Shingo Fujimoto , SIP-WG , Ned.Freed@innosoft.com Subject: Re: [Sip] language info in SIP headers References: <20020724204608.49648.qmail@web11602.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't think this is a major issue, but there is a semantic difference. Accept-Language lists *all* the languages I'm willing to deal with, in terms of error messages, so it might be something like Accept-Language: en, de, fr This doesn't tell the receiver text-to-speech engine anything about how to pronounce my name. As noted, for personal names, even the same ASCII string (ignoring the much more complicated CJK sets) can be pronounced quite differently, particularly where the name has been "imported". I believe the problem is more pronounced with CJK since Chinese names are rendered in "classical" Chinese, rather than simplified. (And I'm probably getting the details wrong.) Sean Olson wrote: > Is there a problem to be solved here that cannot > be handled by Accept-Language and Content-Language? > I realize these only cover the payload and not the > headers. My assumption is that most of the information > that you would need to extract from the headers > can either be treated as a string of octets by an > automata > -or- > is for human consumption and therefore it is > sufficient if these can be rendered appropriately > to the end user (ignoring the Han unification > problem for now) which UTF-8 should cover. Proper > names as in the From/To are a good example of this. > > What automata application cannot make use of the > Accept-Language header to do its job? (I'm not > saying one does not exist, I would just like > clarification of the problem we are trying to solve > here) > > Regards, > Sean Olson > > --- Henning Schulzrinne wrote: > >>>I think the point Ned is making here, is that >> >>language >> >>>tagging is not all that useful in practice. With >> >>UTF-8, >> >>>you can render Kanji characters. You need the >> >>language >> >>>tagging IFF some automata needs to do something >> >>special >> >>>based on knowledge of the language, such as >> >>translation >> >>>or text to speech. However, it is far from clear >> >>whether >> >>>that information is truly needed. Translation of >> >>names >> >>>(like those in Subject, From, To) is not likely to >> >>work >> >>>in any case, nor is it clear that the language tag >> >>is >> >>>needed for it... >> >>You're about to step into the Han unification >>minefield. From my limited >>understanding, the same Unicode/10646 code point is >>rendered differently >>depending on the language (Japanese, Chinese, etc.). >>I don't know if >>this is also true for text-to-speech. Certainly, >>text-to-speech is >>useful for all three headers, e.g., in a voicemail >>system. Jonathan >>Rosenberg ;lang=de and Jonathan Rosenberg ;lang=en >>sound very different. >> >> >>>Well, as Ned indicated, and Henning repeated, the >> >>in-band >> >>>language tagging provided by UTF-8 is not >> >>considered >> >>>acceptable, and we would not be able to write a >> >>specification >> >>>which recommends it as the solution for sip. >> >>I think he meant the ?=jp? marking, not UTF-8 >>language tagging. (That >>said, it isn't clear to me why this would be >>inherently better, except >>maybe to avoid tripping non-language-tag-capable >>10646 renderers and >>annoy the user with random characters instead... The >>arguments against >>tagging seem to be about the same in either syntax - >>nesting, and all that.) >> >>A pragmatic choice is to say that To/From don't need >>UTF or ?=? tagging, >>since ;language=jp will work just fine, without >>annoying users with >>random ASCII art. The Subject header is more >>difficult, but there, a >>smart text-to-speech renderer can usually guess at >>the language by >>checking its dictionary. From my vague recollection, >>very few words are >>needed to do fairly accurate language recognition, >>excepting deliberate >>attempts to create phrases that are meaningful in >>two languages. Google >>seems to do an ok guessing job on most web pages, >>for example. (Guessing >>isn't pretty, but many users aren't going to bother >>marking their >>Subject line anyway and routinely use multiple >>languages, so that device >>configuration isn't sufficient.) >> >> >>>-Jonathan R. >> >> >>_______________________________________________ >>Sip mailing list >>https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP >>Protocol >>Use sip-implementors@cs.columbia.edu for questions >>on current sip >>Use sipping@ietf.org for new developments on the >>application of sip > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 18:38:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04565 for ; Wed, 24 Jul 2002 18:38:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01348 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 18:39:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29790; Wed, 24 Jul 2002 18:14:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29764 for ; Wed, 24 Jul 2002 18:14:19 -0400 (EDT) Received: from airwolf.sentitonetworks.com (airwolf.sentito.com [65.202.222.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03970 for ; Wed, 24 Jul 2002 18:13:12 -0400 (EDT) Received: (qmail 1100 invoked from network); 24 Jul 2002 22:14:10 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 24 Jul 2002 22:14:10 -0000 From: "Shan Lu" To: "IETF SIP Mailing List" Date: Wed, 24 Jul 2002 18:14:43 -0400 Message-ID: <002001c2335f$8300c290$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Authentication and ACK Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, RFC3261 says server must not challenge ACK. It also says that UACs _will_ duplicate Authorization header of INVITE in ACK. I believe this "will" strength is too weak. Think of a stateless proxy that performs authentication. If it receives an ACK with no credentials, it knows it should not challenge the ACK. But what does it do? It has two options and it will have a hard time figuring out when to do what: 1. Drop it. But an ACK may be legitimately without credentials (like ACK for 200) and should be sent along. 2. Proxy it. But the INVITE may have been challenged (ACK for 407) and the UAS will receive ACK out of the blue. Not detrimental but certainly not nice. So I think the "will" requirement on UAC to include same Authorization header as INVITE in ACK needs to be strengthened to "MUST" level. Regards, Shan Lu sentitO Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 19:17:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05394 for ; Wed, 24 Jul 2002 19:17:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA03326 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 19:18:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01870; Wed, 24 Jul 2002 18:56:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01839 for ; Wed, 24 Jul 2002 18:56:03 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04871 for ; Wed, 24 Jul 2002 18:54:59 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6OMtthZ083960; Wed, 24 Jul 2002 17:55:56 -0500 (CDT) Message-ID: <3D3F3057.4060202@dynamicsoft.com> Date: Wed, 24 Jul 2002 17:55:19 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: adam@dynamicsoft.com, sip@ietf.org Subject: Compromise on Expires header in Message (was Re: [Sip] RE: [Simple] -05 MESSAGE and Expires header) References: <2038BCC78B1AD641891A0D1AE133DBB7C20400@esebe019.NOE.Nokia.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I suggest as a compromise, we simply strike any reference to a special case for Expires:0 from the draft. It really belongs in a specification for store-and-forward relays, and is probably not in scope for the MESSAGE specification. If anyone cares to write a draft for store and forward relays, I will be happy to argue the point then. The draft has already completed last call, but this seems to be a valid piece of last call feedback. In the interest of getting an update out prior to IESG review, I am submitting this change in an 06 version now. hisham.khartabil@nokia.com wrote: > We don't want the expires-header to be used as a source for routing decisions. We also don't want to special case "expires: 0". > > Why should routing depend on the value on the expires header? > > I quote Jonathan > "The general notion is that it indicates a lifetime of > something; a point after which the thing is no longer valid." > > You to have some general meaning of expires, otherwise I can say expires of 0 for a new method FOO means "don't FOO me back" or "explode your phone". If the general notion is what Jonathan said above (and what Adam said below), then Expires: 0 in a MESSAGE means that the MESSAGE expiration occurs in zero seconds. It doesn't mean immediate delivery. > > I think the best thing to do is to remove the text. Other methods don't define the meaning of "Expires: 0". > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>Sent: Wednesday, July 24, 2002 4:09 AM >>To: 'Bobby Sardana'; Adam Roach >>Cc: Jonathan Rosenberg; Ben Campbell; Khartabil Hisham (NMP/Helsinki); >>vkg@lucent.com; Ya-Ching.Tan@icn.siemens.de; >>simple@mailman.dynamicsoft.com >>Subject: RE: [Simple] -05 MESSAGE and Expires header >> >> >> >>>-----Original Message----- >>>From: Bobby Sardana [mailto:dsardana@seven.com] >>> >>>The proposal is simple: (not sure from a complete >>>applicability point of >>>view, but here it is) >>> >>>a. Expire signifies a unit of time >> >>Agreed. >> >> >>>b. For methods that have the Expire header, the unit of time >>>determines >>>the method validitity. >> >>There's a problem with that approach. For SUBSCRIBE and REGISTER, >>the "Expires" header doesn't indicate the period of validity of >>the request (which is presumably what you mean by "method validity"); >>it indicates the period of validity for what is *created* by the >>request. The analog for INVITE would be "Session-Expires". >> >> >>>The only exception here is 0, which can mean >>>"expired" or "infinite". >> >>There are actually three problems here. >> >>1. Historically, "0" has never been treated >> as a special case in SIP expirations. (More >> on this below). >> >>2. "Expires: 0" does not mean "expired" (that >> would, in theory, be represented by a negative >> number -- but we don't do that); it means that >> expiration occurs in zero seconds (i.e. >> instantaneously). For the purposes of instant >> messages, that's exactly what we want to convey: >> "this mesage expires instantaneously -- so, send >> it on or consider it stale" (where handling of >> stale messages is a matter of local policy). >> >>3. Zero has *never* meant infinity in a SIP >> "Expires" context. The convention for "infinity" >> is to use 4294967295 (2^32-1), which ends up being >> over 136 years -- long enough to mean "infinity" for >> the purposes of a computer protocol. >> >>/a >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 19:25:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05598 for ; Wed, 24 Jul 2002 19:25:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA03571 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 19:26:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02027; Wed, 24 Jul 2002 18:59:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01998 for ; Wed, 24 Jul 2002 18:59:08 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04946 for ; Wed, 24 Jul 2002 18:58:04 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6OMwCCU021520; Wed, 24 Jul 2002 18:58:12 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306AP5FG>; Wed, 24 Jul 2002 17:58:31 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A321@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , hisham.khartabil@nokia.com Cc: Adam Roach , sip@ietf.org Subject: RE: Compromise on Expires header in Message (was Re: [Sip] RE: [S imple] -05 MESSAGE and Expires header) Date: Wed, 24 Jul 2002 17:58:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree with Ben's approach. /a > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, July 24, 2002 17:55 > To: hisham.khartabil@nokia.com > Cc: adam@dynamicsoft.com; sip@ietf.org > Subject: Compromise on Expires header in Message (was Re: [Sip] RE: > [Simple] -05 MESSAGE and Expires header) > > > I suggest as a compromise, we simply strike any reference to > a special > case for Expires:0 from the draft. It really belongs in a > specification > for store-and-forward relays, and is probably not in scope for the > MESSAGE specification. > > If anyone cares to write a draft for store and forward > relays, I will be > happy to argue the point then. > > The draft has already completed last call, but this seems to > be a valid > piece of last call feedback. In the interest of getting an update out > prior to IESG review, I am submitting this change in an 06 > version now. > > > > hisham.khartabil@nokia.com wrote: > > We don't want the expires-header to be used as a source for > routing decisions. We also don't want to special case "expires: 0". > > > > Why should routing depend on the value on the expires header? > > > > I quote Jonathan > > "The general notion is that it indicates a lifetime of > > something; a point after which the thing is no longer valid." > > > > You to have some general meaning of expires, otherwise I > can say expires of 0 for a new method FOO means "don't FOO me > back" or "explode your phone". If the general notion is what > Jonathan said above (and what Adam said below), then Expires: > 0 in a MESSAGE means that the MESSAGE expiration occurs in > zero seconds. It doesn't mean immediate delivery. > > > > I think the best thing to do is to remove the text. Other > methods don't define the meaning of "Expires: 0". > > > > Regards, > > Hisham > > > > > >>-----Original Message----- > >>From: ext Adam Roach [mailto:adam@dynamicsoft.com] > >>Sent: Wednesday, July 24, 2002 4:09 AM > >>To: 'Bobby Sardana'; Adam Roach > >>Cc: Jonathan Rosenberg; Ben Campbell; Khartabil Hisham > (NMP/Helsinki); > >>vkg@lucent.com; Ya-Ching.Tan@icn.siemens.de; > >>simple@mailman.dynamicsoft.com > >>Subject: RE: [Simple] -05 MESSAGE and Expires header > >> > >> > >> > >>>-----Original Message----- > >>>From: Bobby Sardana [mailto:dsardana@seven.com] > >>> > >>>The proposal is simple: (not sure from a complete > >>>applicability point of > >>>view, but here it is) > >>> > >>>a. Expire signifies a unit of time > >> > >>Agreed. > >> > >> > >>>b. For methods that have the Expire header, the unit of time > >>>determines > >>>the method validitity. > >> > >>There's a problem with that approach. For SUBSCRIBE and REGISTER, > >>the "Expires" header doesn't indicate the period of validity of > >>the request (which is presumably what you mean by "method > validity"); > >>it indicates the period of validity for what is *created* by the > >>request. The analog for INVITE would be "Session-Expires". > >> > >> > >>>The only exception here is 0, which can mean > >>>"expired" or "infinite". > >> > >>There are actually three problems here. > >> > >>1. Historically, "0" has never been treated > >> as a special case in SIP expirations. (More > >> on this below). > >> > >>2. "Expires: 0" does not mean "expired" (that > >> would, in theory, be represented by a negative > >> number -- but we don't do that); it means that > >> expiration occurs in zero seconds (i.e. > >> instantaneously). For the purposes of instant > >> messages, that's exactly what we want to convey: > >> "this mesage expires instantaneously -- so, send > >> it on or consider it stale" (where handling of > >> stale messages is a matter of local policy). > >> > >>3. Zero has *never* meant infinity in a SIP > >> "Expires" context. The convention for "infinity" > >> is to use 4294967295 (2^32-1), which ends up being > >> over 136 years -- long enough to mean "infinity" for > >> the purposes of a computer protocol. > >> > >>/a > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 19:32:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05773 for ; Wed, 24 Jul 2002 19:32:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA04304 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 19:33:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02953; Wed, 24 Jul 2002 19:10:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02924 for ; Wed, 24 Jul 2002 19:10:01 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05163 for ; Wed, 24 Jul 2002 19:08:57 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6ON9whZ084882; Wed, 24 Jul 2002 18:09:59 -0500 (CDT) Message-ID: <3D3F33A2.8090109@dynamicsoft.com> Date: Wed, 24 Jul 2002 18:09:22 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, sip@ietf.org Subject: Re: Compromise on Expires header in Message (was Re: [Sip] RE: [Simple] -05 MESSAGE and Expires header) References: <2038BCC78B1AD641891A0D1AE133DBB7C20400@esebe019.NOE.Nokia.com> <3D3F3057.4060202@dynamicsoft.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit (Replies to self...) Well, after sending this note, I read more carefully and realized that this course of action is exactly what Hisham was suggesting. Therefore please amend the first sentence to read "I suggest we accept Hisham's proposal as a compromise..." Ben Campbell wrote: > I suggest as a compromise, we simply strike any reference to a special > case for Expires:0 from the draft. It really belongs in a specification > for store-and-forward relays, and is probably not in scope for the > MESSAGE specification. > > If anyone cares to write a draft for store and forward relays, I will be > happy to argue the point then. > > The draft has already completed last call, but this seems to be a valid > piece of last call feedback. In the interest of getting an update out > prior to IESG review, I am submitting this change in an 06 version now. > > > > hisham.khartabil@nokia.com wrote: > >> We don't want the expires-header to be used as a source for routing >> decisions. We also don't want to special case "expires: 0". >> >> Why should routing depend on the value on the expires header? >> >> I quote Jonathan >> "The general notion is that it indicates a lifetime of something; a >> point after which the thing is no longer valid." >> >> You to have some general meaning of expires, otherwise I can say >> expires of 0 for a new method FOO means "don't FOO me back" or >> "explode your phone". If the general notion is what Jonathan said >> above (and what Adam said below), then Expires: 0 in a MESSAGE means >> that the MESSAGE expiration occurs in zero seconds. It doesn't mean >> immediate delivery. >> >> I think the best thing to do is to remove the text. Other methods >> don't define the meaning of "Expires: 0". >> >> Regards, >> Hisham >> >> >>> -----Original Message----- >>> From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>> Sent: Wednesday, July 24, 2002 4:09 AM >>> To: 'Bobby Sardana'; Adam Roach >>> Cc: Jonathan Rosenberg; Ben Campbell; Khartabil Hisham (NMP/Helsinki); >>> vkg@lucent.com; Ya-Ching.Tan@icn.siemens.de; >>> simple@mailman.dynamicsoft.com >>> Subject: RE: [Simple] -05 MESSAGE and Expires header >>> >>> >>> >>>> -----Original Message----- >>>> From: Bobby Sardana [mailto:dsardana@seven.com] >>>> >>>> The proposal is simple: (not sure from a complete applicability >>>> point of >>>> view, but here it is) >>>> >>>> a. Expire signifies a unit of time >>> >>> >>> Agreed. >>> >>> >>>> b. For methods that have the Expire header, the unit of time determines >>>> the method validitity. >>> >>> >>> There's a problem with that approach. For SUBSCRIBE and REGISTER, >>> the "Expires" header doesn't indicate the period of validity of >>> the request (which is presumably what you mean by "method validity"); >>> it indicates the period of validity for what is *created* by the >>> request. The analog for INVITE would be "Session-Expires". >>> >>> >>>> The only exception here is 0, which can mean >>>> "expired" or "infinite". >>> >>> >>> There are actually three problems here. >>> 1. Historically, "0" has never been treated as a special case in >>> SIP expirations. (More >>> on this below). >>> >>> 2. "Expires: 0" does not mean "expired" (that >>> would, in theory, be represented by a negative >>> number -- but we don't do that); it means that >>> expiration occurs in zero seconds (i.e. >>> instantaneously). For the purposes of instant >>> messages, that's exactly what we want to convey: >>> "this mesage expires instantaneously -- so, send >>> it on or consider it stale" (where handling of >>> stale messages is a matter of local policy). >>> >>> 3. Zero has *never* meant infinity in a SIP >>> "Expires" context. The convention for "infinity" >>> is to use 4294967295 (2^32-1), which ends up being >>> over 136 years -- long enough to mean "infinity" for >>> the purposes of a computer protocol. >>> >>> /a >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 24 21:37:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09242 for ; Wed, 24 Jul 2002 21:37:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA11710 for sip-archive@odin.ietf.org; Wed, 24 Jul 2002 21:38:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10015; Wed, 24 Jul 2002 21:04:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09983 for ; Wed, 24 Jul 2002 21:04:11 -0400 (EDT) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08335 for ; Wed, 24 Jul 2002 21:03:07 -0400 (EDT) Received: from m6.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id KAA26941 for ; Thu, 25 Jul 2002 10:03:40 +0900 (JST) (envelope-from shingo_fujimoto@jp.fujitsu.com) Received: from dm.akashi.flab.fujitsu.co.jp by m6.gw.fujitsu.co.jp (8.9.3/3.7W-0206-Fujitsu Domain Master) id KAA28871 for ; Thu, 25 Jul 2002 10:03:39 +0900 (envelope-from shingo_fujimoto@jp.fujitsu.com) Received: from dm.akashi.flab.fujitsu.co.jp by dm.akashi.flab.fujitsu.co.jp (8.9.3/3.7W-020129-Fujitsu Labs. Akashi Domain Mail Master) id KAA11104; Thu, 25 Jul 2002 10:03:38 +0900 (JST) Received: from kmailserv.akashi.flab.fujitsu.co.jp ([10.254.200.15]) by dm.akashi.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2002072510033821419 ; Thu, 25 Jul 2002 10:03:38 +0900 Received: from jp.fujitsu.com (suzume.pssys.flab.fujitsu.co.jp [10.254.215.64]) by kmailserv.akashi.flab.fujitsu.co.jp (8.8.8+Sun/8.8.8) with ESMTP id KAA25974; Thu, 25 Jul 2002 10:03:38 +0900 (JST) Message-ID: <3D3F4EA8.6090501@jp.fujitsu.com> Date: Thu, 25 Jul 2002 10:04:40 +0900 From: Shingo Fujimoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: ja,en-US,en MIME-Version: 1.0 To: Henning Schulzrinne CC: SIP-WG Subject: Re: [Sip] language info in SIP headers References: <3D3CE1C9.4080505@jp.fujitsu.com> <3D3D0C1A.7020307@cs.columbia.edu> <3D3D22C6.2080208@jp.fujitsu.com> <3D3D268B.8030803@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I would suggest you write up a short I-D on the subject. > Yes, I will. I just wonder if I should write it as a requirement doc, or just a specification proposal doc. Because I think the requirements are some kind of simple, e.g. UTF-8 friendly and multiple language in same field. -- ====================================== SHINGO FUJIMOTO FUJITSU LABORATORIES LIMITED E-mail: shingo_fujimoto@jp.fujitsu.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 01:10:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14139 for ; Thu, 25 Jul 2002 01:10:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA24646 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 01:11:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19516; Thu, 25 Jul 2002 00:42:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19485 for ; Thu, 25 Jul 2002 00:42:21 -0400 (EDT) Received: from agamemnon.cnchost.com (agamemnon.cnchost.com [207.155.252.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13757 for ; Thu, 25 Jul 2002 00:41:16 -0400 (EDT) Received: from deewana (pool-138-88-39-8.res.east.verizon.net [138.88.39.8]) by agamemnon.cnchost.com id AAA12572; Thu, 25 Jul 2002 00:42:20 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <00fa01c23397$a5910c60$0100000a@nextone.com> From: "Medhavi Bhatia" To: Date: Thu, 25 Jul 2002 00:56:32 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] nit for rfc 3261 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am not sure if the following has already been reported as a bug/nit (wrong use of the word terminate): RFC 3261: 6 Definitions Final Response: A response that terminates a SIP transaction, _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 02:05:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22956 for ; Thu, 25 Jul 2002 02:05:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01495 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 02:06:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29742; Thu, 25 Jul 2002 01:36:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29705 for ; Thu, 25 Jul 2002 01:36:08 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14507 for ; Thu, 25 Jul 2002 01:35:02 -0400 (EDT) Received: from jku2.fokus.gmd.de (port-212-202-172-20.reverse.qdsl-home.de [212.202.172.20]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g6P5ZYd30745; Thu, 25 Jul 2002 07:35:34 +0200 Message-Id: <5.1.0.14.0.20020725071808.00b49078@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Jul 2002 07:22:00 +0200 To: "Shan Lu" , "IETF SIP Mailing List" From: Jiri Kuthan Subject: Re: [Sip] Authentication and ACK In-Reply-To: <002001c2335f$8300c290$eb00000a@SAJAK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Actually, there is no security in ACK unless you use secure transport. Resending INVITE credentials in ACK can be easily attacked by a replay attack. Whichever requirement strength you'ld like to put on sending credentials in ACK, don't expect security to improve. -Jiri At 12:14 AM 7/25/2002, Shan Lu wrote: >Hi, > >RFC3261 says server must not challenge ACK. It also says that UACs >_will_ duplicate Authorization header of INVITE in ACK. I believe this >"will" strength is too weak. Think of a stateless proxy that performs >authentication. If it receives an ACK with no credentials, it knows it >should not challenge the ACK. But what does it do? It has two options >and it will have a hard time figuring out when to do what: > >1. Drop it. But an ACK may be legitimately without credentials (like ACK >for 200) and should be sent along. > >2. Proxy it. But the INVITE may have been challenged (ACK for 407) and >the UAS will receive ACK out of the blue. Not detrimental but certainly >not nice. > >So I think the "will" requirement on UAC to include same Authorization >header as INVITE in ACK needs to be strengthened to "MUST" level. > >Regards, > >Shan Lu > >sentitO Networks > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 02:57:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24858 for ; Thu, 25 Jul 2002 02:57:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA04020 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 02:58:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03066; Thu, 25 Jul 2002 02:37:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03039 for ; Thu, 25 Jul 2002 02:37:44 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24497 for ; Thu, 25 Jul 2002 02:36:36 -0400 (EDT) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g6P6Wim09342 for ; Thu, 25 Jul 2002 12:02:44 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C01.0024582E ; Thu, 25 Jul 2002 12:06:58 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256C01.002456E3.00@sampark.hss.hns.com> Date: Thu, 25 Jul 2002 12:04:56 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] some comments on draft-ietf-sip-session-timer-09.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, some questions and comments on draft-ietf-sip-session-timer-09.txt. Pardon me if these have already been discussed before. 1.Why is it that only a session refresh request or its 2xx response supposed to refresh the session?(See section 10. Performing Refreshes) For example consider the following scenario: UAC UAS session is established with UAS as the refresher (session timer active) (session timer active) (UAC wishes to change some parameters of the session) (UAC sends an re-INVITE) --------INV----------------------------------------> (Should UAS not reset its session timer on receiving it?) <-------200 Ok----------------------------------- (Should UAC also not reset its session timer on receiving 200 OK?) 2.Section 8.1 Processing of Requests says "If the request contains a Supported header field with a value "timer", the proxy MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session- Expires header field is smaller than the minimum interval defined by the proxy's local policy. When sending the 422 response, the proxy MUST include a Min-SE header field with the value of its minimum interval.". Apart from this option, does the draft allow the proxy to increase its local minimum interval?. Can the proxy also forward the request? Can it discard the request, send no response back?if the proxy does not respond back with a 422, the requestor/refresher will not know what value to use for the session timer in its retry. The draft does not specify what (other) actions can the proxy take in this case. If there are no other possible useful actions for the proxy, then should not the MAY be changed to SHOULD? regards harsh This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 03:03:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24970 for ; Thu, 25 Jul 2002 03:03:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA04817 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 03:04:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01855; Thu, 25 Jul 2002 02:18:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01823 for ; Thu, 25 Jul 2002 02:18:18 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24267 for ; Thu, 25 Jul 2002 02:17:09 -0400 (EDT) From: seshashayi@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g6P6Cwm09232; Thu, 25 Jul 2002 11:42:59 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C01.00228AD7 ; Thu, 25 Jul 2002 11:47:17 +0530 X-Lotus-FromDomain: HSSBLR To: Jiri Kuthan cc: "Shan Lu" , "IETF SIP Mailing List" Message-ID: <65256C01.00228AA5.00@sampark.hss.hns.com> Date: Thu, 25 Jul 2002 11:47:16 +0530 Subject: Re: [Sip] Authentication and ACK Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, If the Authorization header is duplicated from INVITE to ACK, is it that servers are not supposed to treat such requests as replay attacks even though a previous request arrived with the exact same nonce-count ? This is fine in case of stateful proxies, but are stateless proxies also expected to maintain such state information to determine whether the ACK credentials are valid ? Rgds Seshu Jiri Kuthan on 07/25/2002 11:52:00 AM To: "Shan Lu" , "IETF SIP Mailing List" cc: (bcc: Seshashayi T/HSSBLR) Subject: Re: [Sip] Authentication and ACK Actually, there is no security in ACK unless you use secure transport. Resending INVITE credentials in ACK can be easily attacked by a replay attack. Whichever requirement strength you'ld like to put on sending credentials in ACK, don't expect security to improve. -Jiri At 12:14 AM 7/25/2002, Shan Lu wrote: >Hi, > >RFC3261 says server must not challenge ACK. It also says that UACs >_will_ duplicate Authorization header of INVITE in ACK. I believe this >"will" strength is too weak. Think of a stateless proxy that performs >authentication. If it receives an ACK with no credentials, it knows it >should not challenge the ACK. But what does it do? It has two options >and it will have a hard time figuring out when to do what: > >1. Drop it. But an ACK may be legitimately without credentials (like ACK >for 200) and should be sent along. > >2. Proxy it. But the INVITE may have been challenged (ACK for 407) and >the UAS will receive ACK out of the blue. Not detrimental but certainly >not nice. > >So I think the "will" requirement on UAC to include same Authorization >header as INVITE in ACK needs to be strengthened to "MUST" level. > >Regards, > >Shan Lu > >sentitO Networks > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 04:29:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26281 for ; Thu, 25 Jul 2002 04:29:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA10782 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 04:31:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06716; Thu, 25 Jul 2002 03:39:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06685 for ; Thu, 25 Jul 2002 03:38:58 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25388 for ; Thu, 25 Jul 2002 03:37:55 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 25 Jul 2002 07:39:19 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Authentication and ACK Date: Thu, 25 Jul 2002 08:39:16 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE018C23E1@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Authentication and ACK Thread-Index: AcIzpJUGBOlakCwIRjmeh1Sb4aaHvAACYkSA From: "James Undery" To: , "Jiri Kuthan" Cc: "Shan Lu" , "IETF SIP Mailing List" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA06686 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit You also have to remember that ACKs for non-2xx final responses are generated hop by hop and so can't contain any "useful" authentication. (Unless everyone in the network can authenticate you ;-) James > -----Original Message----- > From: seshashayi@hss.hns.com [mailto:seshashayi@hss.hns.com] > Sent: 25 July 2002 07:17 > To: Jiri Kuthan > Cc: Shan Lu; IETF SIP Mailing List > Subject: Re: [Sip] Authentication and ACK > > > > > Hi, > If the Authorization header is duplicated from INVITE to ACK, > is it that servers are not supposed to treat such requests > as replay attacks even though a previous request arrived with > the exact same nonce-count ? This is fine > in case of stateful proxies, but are stateless proxies also > expected to maintain such state information to determine whether > the ACK credentials are valid ? > > Rgds > Seshu > > > > > Jiri Kuthan on 07/25/2002 11:52:00 AM > > To: "Shan Lu" , "IETF SIP Mailing List" > > cc: (bcc: Seshashayi T/HSSBLR) > > Subject: Re: [Sip] Authentication and ACK > > > > > Actually, there is no security in ACK unless you use secure transport. > Resending INVITE credentials in ACK can be easily attacked by a replay > attack. Whichever requirement strength you'ld like to put on sending > credentials in ACK, don't expect security to improve. > > -Jiri > > At 12:14 AM 7/25/2002, Shan Lu wrote: > >Hi, > > > >RFC3261 says server must not challenge ACK. It also says that UACs > >_will_ duplicate Authorization header of INVITE in ACK. I > believe this > >"will" strength is too weak. Think of a stateless proxy that performs > >authentication. If it receives an ACK with no credentials, > it knows it > >should not challenge the ACK. But what does it do? It has two options > >and it will have a hard time figuring out when to do what: > > > >1. Drop it. But an ACK may be legitimately without > credentials (like ACK > >for 200) and should be sent along. > > > >2. Proxy it. But the INVITE may have been challenged (ACK > for 407) and > >the UAS will receive ACK out of the blue. Not detrimental > but certainly > >not nice. > > > >So I think the "will" requirement on UAC to include same > Authorization > >header as INVITE in ACK needs to be strengthened to "MUST" level. > > > >Regards, > > > >Shan Lu > > > >sentitO Networks > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 08:41:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01271 for ; Thu, 25 Jul 2002 08:41:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA24036 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 08:42:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21477; Thu, 25 Jul 2002 08:07:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21452 for ; Thu, 25 Jul 2002 08:07:36 -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 IAA29798; Thu, 25 Jul 2002 08:06:28 -0400 (EDT) Message-Id: <200207251206.IAA29798@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 25 Jul 2002 08:06:28 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-congestsafe-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation protocol to Assure Congestion Safety Author(s) : D. Willis, B. Campbell Filename : draft-willis-sip-congestsafe-00.txt Pages : 11 Date : 24-Jul-02 The Session Initiation Protocol allows the use of UDP for transport of SIP messages. The use of UDP inherently risks network congestion problems, as UDP itself does not define congestion prevention, avoidance, detection, or correction mechanisms. This problem is aggravated by large SIP messages which fragment at the UDP level. Transport protocols in SIP are also negotiated on a per-hop basis, at the SIP level, so SIP proxies may convert from TCP to UDP and so forth. This document defines what it means for SIP nodes to be congestion safe and specifies an extension by which a SIP User Agent may require that its requests are treated in a congestion safe manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-congestsafe-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-willis-sip-congestsafe-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-willis-sip-congestsafe-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: <20020724142818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-congestsafe-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-congestsafe-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724142818.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 09:09:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02353 for ; Thu, 25 Jul 2002 09:09:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26385 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 09:10:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24095; Thu, 25 Jul 2002 08:43:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24067 for ; Thu, 25 Jul 2002 08:43:31 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01322 for ; Thu, 25 Jul 2002 08:42:26 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g6PChSo05810 for ; Thu, 25 Jul 2002 14:43:28 +0200 (MEST) Received: from hvrz00da.hvr.siemens.de (hvrz00da.hvr.siemens.de [129.103.192.197]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g6PChRj10595 for ; Thu, 25 Jul 2002 14:43:28 +0200 (MEST) Received: by hvrz00da.hvr.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 14:43:27 +0200 Message-ID: From: BECKMANN MARK To: "'sip@ietf.org'" Date: Thu, 25 Jul 2002 14:43:25 +0200 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Comments on draft-rosenberg-sip-reg-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Jonathan, in your draft on the event package for registrations, you proposed the following FSM for the contacts registered with an adress of record: +------+ | | refreshed | | V | +------------+ +------------+ +------------+ | | | | | | | Init |----------->| Active |----------->| Terminated | | | | | | | +------------+ registered +------------+ expired +------------+ created deactivated probation unregistered rejected In section 3.1 it is described that in case an administrator wants a device to re-authenticate, the registration is terminated and the device is notified, e.g. by setting the event parameter to "deactivated". First of all, I can't see a big difference between the two events "expired" and "deactivated". "Deactivated" seems to be part of the "expired" event. In both cases the contact may be re-registered. It doesn't seem very important whether the registration is moved to the terminated state because it has expired or because it has been deactivated. Secondly, I think in case an administrator wants a device to re-authenticate, the registration of the corresponding contact should not move to the terminated state. Instead, another event (for example "re-authenticate") similar to the "refresh" event should be introduced. When this event occurs, the device is notified and the duration for which the contact remains registered is reduced and if the device fails to re-register, the registration is moved to the terminated state e.g. via the "expired" event. Thus, the FSM would look like: +------+ | | refreshed | | re-authenticate V | +------------+ +------------+ +------------+ | | | | | | | Init |----------->| Active |----------->| Terminated | | | | | | | +------------+ registered +------------+ +------------+ created expired probation unregistered rejected Best regards, Mark Mark Beckmann Siemens AG ICM MP P PS 4S2 P.O.Box 100702 phone: +49 (5341) 906 1814 D-38228 Salzgitter fax: +49 (5341) 906 2010 mailto: Mark.Beckmann@siemens.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 10:20:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05441 for ; Thu, 25 Jul 2002 10:20:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01426 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 10:21:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28543; Thu, 25 Jul 2002 09:39:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28429 for ; Thu, 25 Jul 2002 09:39:02 -0400 (EDT) Received: from airwolf.sentitonetworks.com (airwolf.sentito.com [65.202.222.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03521 for ; Thu, 25 Jul 2002 09:37:59 -0400 (EDT) Received: (qmail 3271 invoked from network); 25 Jul 2002 13:39:03 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 25 Jul 2002 13:39:03 -0000 From: "Shan Lu" To: "'James Undery'" , , "'Jiri Kuthan'" Cc: "'IETF SIP Mailing List'" Subject: RE: [Sip] Authentication and ACK Date: Thu, 25 Jul 2002 09:39:34 -0400 Message-ID: <000701c233e0$b67afec0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <45730E094814E44488F789C1CDED27AE018C23E1@GBNEWP0758M.eu.ubiquity.net> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't think hop by hop is a problem. From the perspective of authentication server/stateless proxy, the ACK is either for an INVITE that has passed authentication or for an INVITE that has failed authentication. Any stateful entities that ACK non-2xx final responses would have no difficulty duplicating the same Authorization header, if any, from INVITE. I agree it is subject to replay attack. But isn't it better than blindly proxy each and every ACK that is received at stateless server ? Regards, Shan Lu >-----Original Message----- >From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf >Of James Undery >Sent: Thursday, July 25, 2002 3:39 AM >To: seshashayi@hss.hns.com; Jiri Kuthan >Cc: Shan Lu; IETF SIP Mailing List >Subject: RE: [Sip] Authentication and ACK > > >You also have to remember that ACKs for non-2xx final >responses are generated hop by hop and so can't contain any >"useful" authentication. (Unless everyone in the network can >authenticate you ;-) > >James > >> -----Original Message----- >> From: seshashayi@hss.hns.com [mailto:seshashayi@hss.hns.com] >> Sent: 25 July 2002 07:17 >> To: Jiri Kuthan >> Cc: Shan Lu; IETF SIP Mailing List >> Subject: Re: [Sip] Authentication and ACK >> >> >> >> >> Hi, >> If the Authorization header is duplicated from INVITE to ACK, >> is it that servers are not supposed to treat such requests >> as replay attacks even though a previous request arrived with >> the exact same nonce-count ? This is fine >> in case of stateful proxies, but are stateless proxies also >> expected to maintain such state information to determine whether >> the ACK credentials are valid ? >> >> Rgds >> Seshu >> >> >> >> >> Jiri Kuthan on 07/25/2002 11:52:00 AM >> >> To: "Shan Lu" , "IETF SIP Mailing List" >> >> cc: (bcc: Seshashayi T/HSSBLR) >> >> Subject: Re: [Sip] Authentication and ACK >> >> >> >> >> Actually, there is no security in ACK unless you use secure >transport. >> Resending INVITE credentials in ACK can be easily attacked >by a replay >> attack. Whichever requirement strength you'ld like to put on sending >> credentials in ACK, don't expect security to improve. >> >> -Jiri >> >> At 12:14 AM 7/25/2002, Shan Lu wrote: >> >Hi, >> > >> >RFC3261 says server must not challenge ACK. It also says that UACs >> >_will_ duplicate Authorization header of INVITE in ACK. I >> believe this >> >"will" strength is too weak. Think of a stateless proxy >that performs >> >authentication. If it receives an ACK with no credentials, >> it knows it >> >should not challenge the ACK. But what does it do? It has >two options >> >and it will have a hard time figuring out when to do what: >> > >> >1. Drop it. But an ACK may be legitimately without >> credentials (like ACK >> >for 200) and should be sent along. >> > >> >2. Proxy it. But the INVITE may have been challenged (ACK >> for 407) and >> >the UAS will receive ACK out of the blue. Not detrimental >> but certainly >> >not nice. >> > >> >So I think the "will" requirement on UAC to include same >> Authorization >> >header as INVITE in ACK needs to be strengthened to "MUST" level. >> > >> >Regards, >> > >> >Shan Lu >> > >> >sentitO Networks >> > >> > >> >_______________________________________________ >> >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >This list is for NEW development of the core SIP Protocol >> >Use sip-implementors@cs.columbia.edu for questions on current sip >> >Use sipping@ietf.org for new developments on the application of sip >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 10:20:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05490 for ; Thu, 25 Jul 2002 10:20:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01493 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 10:21:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28763; Thu, 25 Jul 2002 09:41:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28732 for ; Thu, 25 Jul 2002 09:41:38 -0400 (EDT) Received: from pub.isofttechindia.com ([203.199.202.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03665 for ; Thu, 25 Jul 2002 09:40:33 -0400 (EDT) Received: from isoft ([192.168.0.235]) by pub.isofttechindia.com (8.11.0/8.11.0) with SMTP id g6PDccV03010 for ; Thu, 25 Jul 2002 19:08:38 +0530 From: "Sp.Raja" To: "Sip-IETF" Date: Thu, 25 Jul 2002 19:16:30 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Sec 28.1 clarification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sec 28.1 of RFC 3261 has a bullet which reads o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 allowed the UAS not to send a response to INVITE when a BYE was received. That is disallowed here. The original INVITE needs a response. But I suppose it should be o Similarly, *INVITE* and BYE transactions were intermingled; RFC 2543 allowed the UAS not to send a response to INVITE when a BYE was received. That is disallowed here. The original INVITE needs a response. Correct me if I'm wrong. -Sp.Raja _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 12:19:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10654 for ; Thu, 25 Jul 2002 12:19:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09590 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 12:20:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06822; Thu, 25 Jul 2002 11:43:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06792 for ; Thu, 25 Jul 2002 11:42:52 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09104 for ; Thu, 25 Jul 2002 11:41:47 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g6PFgoW27754; Thu, 25 Jul 2002 17:42:50 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g6PFgnD05655; Thu, 25 Jul 2002 17:42:49 +0200 (MEST) Received: from cs.columbia.edu (mhpa6v8c [139.23.202.84]) by mail-y.mchp.siemens.de with ESMTP id g6PFgfcH002903; Thu, 25 Jul 2002 17:42:42 +0200 (MET DST) Message-ID: <3D401C41.4020204@cs.columbia.edu> Date: Thu, 25 Jul 2002 11:41:53 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shingo Fujimoto CC: SIP-WG Subject: Re: [Sip] language info in SIP headers References: <3D3CE1C9.4080505@jp.fujitsu.com> <3D3D0C1A.7020307@cs.columbia.edu> <3D3D22C6.2080208@jp.fujitsu.com> <3D3D268B.8030803@cs.columbia.edu> <3D3F4EA8.6090501@jp.fujitsu.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The chairs will probably be helpful to provide guidance; I would imagine the formal approach would be a separate requirements document. Another pragmatic approach might be a document that presents and motivates the problem to be solved and then presents some solutions and why they may or may not work. Shingo Fujimoto wrote: > Henning Schulzrinne wrote: > Yes, I will. > > > I just wonder if I should write it as a requirement doc, or just a > specification proposal doc. > > Because I think the requirements are some kind of simple, e.g. UTF-8 > friendly and multiple language in same field. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jul 25 14:32:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16219 for ; Thu, 25 Jul 2002 14:32:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18625 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 14:33:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15785; Thu, 25 Jul 2002 13:53:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15754 for ; Thu, 25 Jul 2002 13:53:44 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14629 for ; Thu, 25 Jul 2002 13:52:38 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21864; Thu, 25 Jul 2002 13:53:12 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA16886; Thu, 25 Jul 2002 13:53:12 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99CA8W>; Thu, 25 Jul 2002 13:53:12 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B56FE@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Shingo Fujimoto Cc: SIP-WG Subject: RE: [Sip] language info in SIP headers Date: Thu, 25 Jul 2002 13:53:12 -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@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree that it's requirements first. I think if requirements fit in less than a page, than one ID with requirements up front and possible solutions should be written up in an I-D and presented to SIPPING. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, July 25, 2002 11:42 AM > To: Shingo Fujimoto > Cc: SIP-WG > Subject: Re: [Sip] language info in SIP headers > > > The chairs will probably be helpful to provide guidance; I > would imagine > the formal approach would be a separate requirements > document. Another > pragmatic approach might be a document that presents and > motivates the > problem to be solved and then presents some solutions and why > they may > or may not work. > > Shingo Fujimoto wrote: > > Henning Schulzrinne wrote: > > > Yes, I will. > > > > > > I just wonder if I should write it as a requirement doc, or just a > > specification proposal doc. > > > > Because I think the requirements are some kind of simple, > e.g. UTF-8 > > friendly and multiple language in same field. > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jul 25 21:50:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26916 for ; Thu, 25 Jul 2002 21:50:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10546 for sip-archive@odin.ietf.org; Thu, 25 Jul 2002 21:51:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08681; Thu, 25 Jul 2002 21:04:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08650 for ; Thu, 25 Jul 2002 21:04:38 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25983 for ; Thu, 25 Jul 2002 21:03:34 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6Q14Ij08071; Thu, 25 Jul 2002 20:04:18 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 20:04:04 -0500 Message-ID: From: "Sriram Parameswar" To: "'BECKMANN MARK'" , "'sip@ietf.org'" Subject: RE: [Sip] Comments on draft-rosenberg-sip-reg-00 Date: Thu, 25 Jul 2002 20:04:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23440.54C652F0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C23440.54C652F0 Content-Type: text/plain; charset="iso-8859-1" Hi, I have a comment and a question. Comment: Mark - I think there is a fairly big difference between "expired" and "deactivated". When you simply do not re-register your device, your registration goes to state Terminated with a reason of "expired" and when an administrator specifically removes your binding, you go to state Terminated with a reason of "deactivated". Let us suppose I have several devices and have SUBSCRIBEd to their reg event, I would be very interested in finding the difference between a device whose Registration expired due my inactivity and one whose Registration expired due to a deliberate action on the part of the administrator. It does not matter that in both cases I am allowed to re-register. Question: Jonathan/Mark - lets use the example that I have several devices attached to an AoR of 'skp@example.com'. Their contacts are 'skp@pc.example.com', 'skp@sip_phone.example.com' and 'skp@wireless_dev.example.com'. Now I want to authorize somebody to be able to see my registration state on the 'PC' and 'SIP_phone' but not the 'Wireless_device' how do we achieve this? I think there are some privacy concerns here that we may have skipped over, the fact that some Contact address may be private and I do not want to share information about that, while others are public. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: BECKMANN MARK [mailto:mark.beckmann@sal.siemens.de] Sent: Thursday, July 25, 2002 7:43 AM To: 'sip@ietf.org' Subject: [Sip] Comments on draft-rosenberg-sip-reg-00 Importance: High Hi Jonathan, in your draft on the event package for registrations, you proposed the following FSM for the contacts registered with an adress of record: +------+ | | refreshed | | V | +------------+ +------------+ +------------+ | | | | | | | Init |----------->| Active |----------->| Terminated | | | | | | | +------------+ registered +------------+ expired +------------+ created deactivated probation unregistered rejected In section 3.1 it is described that in case an administrator wants a device to re-authenticate, the registration is terminated and the device is notified, e.g. by setting the event parameter to "deactivated". First of all, I can't see a big difference between the two events "expired" and "deactivated". "Deactivated" seems to be part of the "expired" event. In both cases the contact may be re-registered. It doesn't seem very important whether the registration is moved to the terminated state because it has expired or because it has been deactivated. Secondly, I think in case an administrator wants a device to re-authenticate, the registration of the corresponding contact should not move to the terminated state. Instead, another event (for example "re-authenticate") similar to the "refresh" event should be introduced. When this event occurs, the device is notified and the duration for which the contact remains registered is reduced and if the device fails to re-register, the registration is moved to the terminated state e.g. via the "expired" event. Thus, the FSM would look like: +------+ | | refreshed | | re-authenticate V | +------------+ +------------+ +------------+ | | | | | | | Init |----------->| Active |----------->| Terminated | | | | | | | +------------+ registered +------------+ +------------+ created expired probation unregistered rejected Best regards, Mark Mark Beckmann Siemens AG ICM MP P PS 4S2 P.O.Box 100702 phone: +49 (5341) 906 1814 D-38228 Salzgitter fax: +49 (5341) 906 2010 mailto: Mark.Beckmann@siemens.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C23440.54C652F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Comments on draft-rosenberg-sip-reg-00

Hi,

I have a comment and a question.

Comment: Mark - I think there is a fairly big = difference between "expired" and "deactivated". = When you simply do not re-register your device, your registration goes = to state Terminated with a reason of "expired" and when an = administrator specifically removes your binding, you go to state = Terminated with a reason of "deactivated". Let us suppose I = have several devices and have SUBSCRIBEd to their reg event, I would be = very interested in finding the difference between a device whose = Registration expired due my inactivity and one whose Registration = expired due to a deliberate action on the part of the administrator. It = does not matter that in both cases I am allowed to = re-register.

Question: Jonathan/Mark - lets use the example that I = have several devices attached to an AoR of 'skp@example.com'.  = Their contacts are 'skp@pc.example.com', 'skp@sip_phone.example.com' = and 'skp@wireless_dev.example.com'. Now I want to authorize somebody to = be able to see my registration state on the 'PC' and 'SIP_phone' but = not the 'Wireless_device' how do we achieve this? I think there are = some privacy concerns here that we may have skipped over, the fact that = some Contact address may be private and I do not want to share = information about that, while others are public.

Thanks,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: BECKMANN MARK [mailto:mark.beckmann@sal.si= emens.de]
Sent: Thursday, July 25, 2002 7:43 AM
To: 'sip@ietf.org'
Subject: [Sip] Comments on = draft-rosenberg-sip-reg-00
Importance: High


Hi Jonathan,

in your draft on the event package for registrations, = you proposed the
following FSM for the contacts registered with an = adress of record:
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  
          &nb= sp;           &nb= sp;          = +------+          &nbs= p;           &nbs= p;         
          &nb= sp;           &nb= sp;          = |      | = refreshed          &nb= sp;            =
          &nb= sp;           &nb= sp;          = |      = |            = ;            = ;        
          &nb= sp;           &nb= sp;          = V      = |            = ;            = ;        
    = +------------+         &nbs= p;  = +------------+         &nbs= p;  +------------+   
    = |            = |            = |            = |            = |            = |   
    |    = Init    |----------->|   Active   = |----------->| Terminated |   
    = |            = |            = |            = |            = |            = |   
    +------------+ registered = +------------+ expired    = +------------+   
          &nb= sp;        = created           = ;        = deactivated          &= nbsp;      
          &nb= sp;           &nb= sp;           &nb= sp;          = probation          &nb= sp;        
          &nb= sp;           &nb= sp;           &nb= sp;          = unregistered          =       
          &nb= sp;           &nb= sp;           &nb= sp;          = rejected          &nbs= p;         
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  

In section 3.1 it is described that in case an = administrator wants a device
to re-authenticate, the registration is terminated = and the device is
notified, e.g. by setting the event parameter to = "deactivated".

First of all, I can't see a big difference between = the two events "expired"
and "deactivated". "Deactivated" = seems to be part of the "expired" event. In
both cases the contact may be re-registered. It = doesn't seem very important
whether the registration is moved to the terminated = state because it has
expired or because it has been deactivated.

Secondly, I think in case an administrator wants a = device to
re-authenticate, the registration of the = corresponding contact should not
move to the terminated state. Instead, another event = (for example
"re-authenticate") similar to the = "refresh" event should be introduced. When
this event occurs, the device is notified and the = duration for which the
contact remains registered is reduced and if the = device fails to
re-register, the registration is moved to the = terminated state e.g. via the
"expired" event.

Thus, the FSM would look like:
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  
          &nb= sp;           &nb= sp;          = +------+          &nbs= p;           &nbs= p;         
          &nb= sp;           &nb= sp;          = |      | = refreshed          &nb= sp;            =
          &nb= sp;           &nb= sp;          = |      | re-authenticate

          &nb= sp;           &nb= sp;          = V      = |            = ;            = ;        
    = +------------+         &nbs= p;  = +------------+         &nbs= p;  +------------+   
    = |            = |            = |            = |            = |            = |   
    |    = Init    |----------->|   Active   = |----------->| Terminated |   
    = |            = |            = |            = |            = |            = |   
    +------------+ registered = +------------+         &nbs= p;  +------------+   
          &nb= sp;        = created           = ;        = expired           = ;   
          &nb= sp;           &nb= sp;           &nb= sp;          = probation          &nb= sp;
          &nb= sp;           &nb= sp;           &nb= sp;          = unregistered          =
          &nb= sp;           &nb= sp;           &nb= sp;          = rejected          &nbs= p;   

Best regards,


Mark


Mark Beckmann   =         =         Siemens AG

ICM MP P PS 4S2
P.O.Box 100702  =         =         phone: +49 (5341) 906 = 1814
D-38228 Salzgitter      =         fax:   +49 (5341) = 906 2010

mailto: Mark.Beckmann@siemens.com



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

------_=_NextPart_001_01C23440.54C652F0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 05:52:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12842 for ; Fri, 26 Jul 2002 05:52:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10744 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 05:53:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09266; Fri, 26 Jul 2002 05:18:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09230 for ; Fri, 26 Jul 2002 05:18:06 -0400 (EDT) Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12415 for ; Fri, 26 Jul 2002 05:17:00 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-2.free.fr (Postfix) with ESMTP id 4037D5F8E2 for ; Fri, 26 Jul 2002 11:18:04 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 0401DFCFC; Fri, 26 Jul 2002 11:18:06 +0200 (MEST) To: sip@ietf.org Message-ID: <1027675086.3d4113cea3e8f@imp.free.fr> Date: Fri, 26 Jul 2002 11:18:06 +0200 (MEST) From: patrick.mourot@online.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 213.223.66.160 Content-Transfer-Encoding: 8bit Subject: [Sip] refer-06 question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Sir, In 2.4.5 § of refer-06 draft It is stated that a "A minimal, but complete, implementation can respond with a single NOTIFY containing either ...the body: SIP/2.0 200 OK if the reference was successful". It seems to be in contradiction with § 3.10 saying that "Alternatively, the subscription might only result in two NOTIFY requests, the immediate NOTIFY and the NOTIFY carrying the final result of the reference". Do we need 1 or 2 NOTIFY in a minimal implementation? Best Regards, Patrick _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 08:04:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15435 for ; Fri, 26 Jul 2002 08:04:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16918 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 08:06:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14464; Fri, 26 Jul 2002 07:07:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14431 for ; Fri, 26 Jul 2002 07:07:46 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14235 for ; Fri, 26 Jul 2002 07:06:26 -0400 (EDT) Received: from m2vwall5.wipro.com ([10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g6QB6xj18764 for ; Fri, 26 Jul 2002 16:37:00 +0530 (IST) Received: from blr-m1-bh1.wipro.com ([10.115.50.91]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GZUS7701.GDH; Fri, 26 Jul 2002 16:36:44 +0530 Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Jul 2002 16:36:43 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] refer-06 question X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 26 Jul 2002 16:36:43 +0530 Message-ID: <60614B15188EBB4FA59F85310C2AC7D620AE88@blr-m1-msg.wipro.com> Thread-Topic: [Sip] refer-06 question Thread-Index: AcI0iXMT1W/qrPACSHCYQ2YePs0uOQACqpPQ From: "Vijay S Kamath" To: , X-OriginalArrivalTime: 26 Jul 2002 11:06:43.0722 (UTC) FILETIME=[86908EA0:01C23494] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA14432 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit It can be either 1 or more, but at least 1. Qouting Section 2.4.7: "Each NOTIFY must contain a Subscription-State header field as defined in [2]. The final NOTIFY sent in response to a REFER MUST indicate the subscription has been "terminated" with a reason of "noresource"." The final NOTIFY can also be the first NOTIFY. Regards... Vijay -----Original Message----- From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] Sent: Friday, July 26, 2002 2:48 PM To: sip@ietf.org Subject: [Sip] refer-06 question Sir, In 2.4.5 § of refer-06 draft It is stated that a "A minimal, but complete, implementation can respond with a single NOTIFY containing either ...the body: SIP/2.0 200 OK if the reference was successful". It seems to be in contradiction with § 3.10 saying that "Alternatively, the subscription might only result in two NOTIFY requests, the immediate NOTIFY and the NOTIFY carrying the final result of the reference". Do we need 1 or 2 NOTIFY in a minimal implementation? Best Regards, Patrick _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 08:41:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16978 for ; Fri, 26 Jul 2002 08:41:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA19127 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 08:42:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16147; Fri, 26 Jul 2002 07:53:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16116 for ; Fri, 26 Jul 2002 07:53:52 -0400 (EDT) Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15225 for ; Fri, 26 Jul 2002 07:52:45 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-1.free.fr (Postfix) with ESMTP id A9623333; Fri, 26 Jul 2002 13:53:50 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id 77516873CF; Fri, 26 Jul 2002 13:53:50 +0200 (MEST) To: Vijay S Kamath Subject: RE: [Sip] refer-06 question Message-ID: <1027684430.3d41384e6a93d@imp.free.fr> Date: Fri, 26 Jul 2002 13:53:50 +0200 (MEST) From: patrick.mourot@online.fr Cc: sip@ietf.org References: <60614B15188EBB4FA59F85310C2AC7D620AE88@blr-m1-msg.wipro.com> In-Reply-To: <60614B15188EBB4FA59F85310C2AC7D620AE88@blr-m1-msg.wipro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 213.223.66.160 Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit vsk, Thanks for the answer. I understand both cases; but this does not light my way. Let me put it in other words. can i delay the notification until the referenced request completes? leading to send only 1 notification???? (assuming timers are OK). Or am i oblige to send a 1rst notification, wait for completion of the referenced request and send a final notification ? What is mandatory? Patrick Quoting Vijay S Kamath : > It can be either 1 or more, but at least 1. > Qouting Section 2.4.7: "Each NOTIFY must contain a Subscription-State > header field as defined > in [2]. The final NOTIFY sent in response to a REFER MUST indicate > the subscription has been "terminated" with a reason of > "noresource"." > > The final NOTIFY can also be the first NOTIFY. > > Regards... Vijay > > -----Original Message----- > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > Sent: Friday, July 26, 2002 2:48 PM > To: sip@ietf.org > Subject: [Sip] refer-06 question > > > Sir, > > > In 2.4.5 § of refer-06 draft It is stated that a "A minimal, but > complete, > implementation can respond with a single NOTIFY containing either ...the > body: > SIP/2.0 200 OK if the reference was successful". > > It seems to be in contradiction with § 3.10 saying that "Alternatively, > the > subscription might only result in two NOTIFY requests, the immediate > NOTIFY and > the NOTIFY carrying the final result of the reference". > > Do we need 1 or 2 NOTIFY in a minimal implementation? > > Best Regards, > > Patrick > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 09:00:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17954 for ; Fri, 26 Jul 2002 09:00:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA20488 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 09:01:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17421; Fri, 26 Jul 2002 08:12:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17389 for ; Fri, 26 Jul 2002 08:11:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16056; Fri, 26 Jul 2002 08:10:50 -0400 (EDT) Message-Id: <200207261210.IAA16056@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 26 Jul 2002 08:10:50 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-message-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : Session Initiation Protocol Extension for Instant Messaging Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-sip-message-06.txt Pages : 22 Date : 25-Jul-02 Instant Messageing (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. The MESSAGE method is an extension to the Session Initation Protocol (SIP) that allows the transfer of Instant Messages. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. Since the MESSAGE request is an extension to SIP it inherits all the request routing and security features of that protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-message-06.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-message-06.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: <20020725151406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020725151406.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 09:01:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18011 for ; Fri, 26 Jul 2002 09:01:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA20669 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 09:02:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17899; Fri, 26 Jul 2002 08:25:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17860 for ; Fri, 26 Jul 2002 08:25:35 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16421 for ; Fri, 26 Jul 2002 08:24:23 -0400 (EDT) Received: from m2vwall5.wipro.com ([10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g6QCOuj04963 for ; Fri, 26 Jul 2002 17:54:57 +0530 (IST) Received: from blr-m1-bh1.wipro.com ([10.115.50.91]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GZUVT601.HD2; Fri, 26 Jul 2002 17:54:42 +0530 Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Jul 2002 17:54:41 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] refer-06 question X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 26 Jul 2002 17:54:41 +0530 Message-ID: <60614B15188EBB4FA59F85310C2AC7D620AECC@blr-m1-msg.wipro.com> Thread-Topic: [Sip] refer-06 question Thread-Index: AcI0myVTajCt+2/iRVSUXBLTc0GjGQAA3+NA From: "Vijay S Kamath" To: Cc: X-OriginalArrivalTime: 26 Jul 2002 12:24:41.0999 (UTC) FILETIME=[6B08F9F0:01C2349F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA17861 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Patrick, You cannot delay the notification until the referenced request completes. Quoting Sec 2.4.4: "The creation of a subscription as defined by [1] always results in an immediate NOTIFY. " So I suggest you follow your second suggestion. Vijay -----Original Message----- From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] Sent: Friday, July 26, 2002 5:24 PM To: Vijay Kamath Cc: sip@ietf.org Subject: RE: [Sip] refer-06 question vsk, Thanks for the answer. I understand both cases; but this does not light my way. Let me put it in other words. can i delay the notification until the referenced request completes? leading to send only 1 notification???? (assuming timers are OK). Or am i oblige to send a 1rst notification, wait for completion of the referenced request and send a final notification ? What is mandatory? Patrick Quoting Vijay S Kamath : > It can be either 1 or more, but at least 1. > Qouting Section 2.4.7: "Each NOTIFY must contain a Subscription-State > header field as defined > in [2]. The final NOTIFY sent in response to a REFER MUST indicate > the subscription has been "terminated" with a reason of > "noresource"." > > The final NOTIFY can also be the first NOTIFY. > > Regards... Vijay > > -----Original Message----- > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > Sent: Friday, July 26, 2002 2:48 PM > To: sip@ietf.org > Subject: [Sip] refer-06 question > > > Sir, > > > In 2.4.5 § of refer-06 draft It is stated that a "A minimal, but > complete, implementation can respond with a single NOTIFY containing > either ...the > body: > SIP/2.0 200 OK if the reference was successful". > > It seems to be in contradiction with § 3.10 saying that > "Alternatively, the subscription might only result in two NOTIFY > requests, the immediate NOTIFY and > the NOTIFY carrying the final result of the reference". > > Do we need 1 or 2 NOTIFY in a minimal implementation? > > Best Regards, > > Patrick > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 09:21:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18869 for ; Fri, 26 Jul 2002 09:21:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21703 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 09:22:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19270; Fri, 26 Jul 2002 08:44:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19172 for ; Fri, 26 Jul 2002 08:44:33 -0400 (EDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17077 for ; Fri, 26 Jul 2002 08:43:25 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g6QCiUJ15164; Fri, 26 Jul 2002 14:44:30 +0200 (MEST) Received: from hvrz00da.hvr.siemens.de (hvrz00da.hvr.siemens.de [129.103.192.197]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g6QCiT510233; Fri, 26 Jul 2002 14:44:29 +0200 (MEST) Received: by hvrz00da.hvr.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 14:44:27 +0200 Message-ID: From: BECKMANN MARK To: "'Sriram Parameswar'" , "'sip@ietf.org'" Subject: RE: [Sip] Comments on draft-rosenberg-sip-reg-00 Date: Fri, 26 Jul 2002 14:44:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C234A2.2D0D7C40" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C234A2.2D0D7C40 Content-Type: text/plain; charset="iso-8859-1" Hi Sriram, please see my comments inline. Best regards, Mark Mark Beckmann Siemens AG ICM MP P PS 4S2 P.O.Box 100702 phone: +49 (5341) 906 1814 D-38228 Salzgitter fax: +49 (5341) 906 2010 mailto: Mark.Beckmann@siemens.com -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Friday, July 26, 2002 3:04 AM To: BECKMANN MARK; 'sip@ietf.org' Subject: RE: [Sip] Comments on draft-rosenberg-sip-reg-00 Hi, I have a comment and a question. Comment: Mark - I think there is a fairly big difference between "expired" and "deactivated". When you simply do not re-register your device, your registration goes to state Terminated with a reason of "expired" and when an administrator specifically removes your binding, you go to state Terminated with a reason of "deactivated". Let us suppose I have several devices and have SUBSCRIBEd to their reg event, I would be very interested in finding the difference between a device whose Registration expired due my inactivity and one whose Registration expired due to a deliberate action on the part of the administrator. It does not matter that in both cases I am allowed to re-register. [MB] Agreed. My initial thought was that "deactivated" could be seen as an "expired" with the only difference that the administrator has reduced the duration for which the registration is valid without explicitely telling the device. Question: Jonathan/Mark - lets use the example that I have several devices attached to an AoR of 'skp@example.com'. Their contacts are 'skp@pc.example.com', 'skp@sip_phone.example.com' and 'skp@wireless_dev.example.com'. Now I want to authorize somebody to be able to see my registration state on the 'PC' and 'SIP_phone' but not the 'Wireless_device' how do we achieve this? I think there are some privacy concerns here that we may have skipped over, the fact that some Contact address may be private and I do not want to share information about that, while others are public. [MB] I agree that there is a privacy issue here, which is probably very similar to the one for presence. Therefore it should be stated that a subscription may be authenticated and authorized, whereby the mechanism for authorization is outside the scope of the reg-event draft. The watcher info package may be used for the reg event to inform the "owner" of the registration about subscriptions. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: BECKMANN MARK [ mailto:mark.beckmann@sal.siemens.de ] Sent: Thursday, July 25, 2002 7:43 AM To: 'sip@ietf.org' Subject: [Sip] Comments on draft-rosenberg-sip-reg-00 Importance: High Hi Jonathan, in your draft on the event package for registrations, you proposed the following FSM for the contacts registered with an adress of record: +------+ | | refreshed | | V | +------------+ +------------+ +------------+ | | | | | | | Init |----------->| Active |----------->| Terminated | | | | | | | +------------+ registered +------------+ expired +------------+ created deactivated probation unregistered rejected In section 3.1 it is described that in case an administrator wants a device to re-authenticate, the registration is terminated and the device is notified, e.g. by setting the event parameter to "deactivated". First of all, I can't see a big difference between the two events "expired" and "deactivated". "Deactivated" seems to be part of the "expired" event. In both cases the contact may be re-registered. It doesn't seem very important whether the registration is moved to the terminated state because it has expired or because it has been deactivated. Secondly, I think in case an administrator wants a device to re-authenticate, the registration of the corresponding contact should not move to the terminated state. Instead, another event (for example "re-authenticate") similar to the "refresh" event should be introduced. When this event occurs, the device is notified and the duration for which the contact remains registered is reduced and if the device fails to re-register, the registration is moved to the terminated state e.g. via the "expired" event. Thus, the FSM would look like: +------+ | | refreshed | | re-authenticate V | +------------+ +------------+ +------------+ | | | | | | | Init |----------->| Active |----------->| Terminated | | | | | | | +------------+ registered +------------+ +------------+ created expired probation unregistered rejected Best regards, Mark Mark Beckmann Siemens AG ICM MP P PS 4S2 P.O.Box 100702 phone: +49 (5341) 906 1814 D-38228 Salzgitter fax: +49 (5341) 906 2010 mailto: Mark.Beckmann@siemens.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C234A2.2D0D7C40 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Comments on draft-rosenberg-sip-reg-00
Hi Sriram,
 
please see my comments inline.
 
 
Best regards,
 
Mark
 

Mark Beckmann                   Siemens AG

ICM MP P PS 4S2
P.O.Box 100702                  phone: +49 (5341) 906 1814
D-38228 Salzgitter              fax:   +49 (5341) 906 2010

mailto: Mark.Beckmann@siemens.com

-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: Friday, July 26, 2002 3:04 AM
To: BECKMANN MARK; 'sip@ietf.org'
Subject: RE: [Sip] Comments on draft-rosenberg-sip-reg-00

Hi,

I have a comment and a question.

Comment: Mark - I think there is a fairly big difference between "expired" and "deactivated". When you simply do not re-register your device, your registration goes to state Terminated with a reason of "expired" and when an administrator specifically removes your binding, you go to state Terminated with a reason of "deactivated". Let us suppose I have several devices and have SUBSCRIBEd to their reg event, I would be very interested in finding the difference between a device whose Registration expired due my inactivity and one whose Registration expired due to a deliberate action on the part of the administrator. It does not matter that in both cases I am allowed to re-register.
 
[MB] Agreed. My  initial thought was that "deactivated" could be seen as an "expired" with the only difference that the administrator has reduced the duration for which the registration is valid without explicitely telling the device.

Question: Jonathan/Mark - lets use the example that I have several devices attached to an AoR of 'skp@example.com'.  Their contacts are 'skp@pc.example.com', 'skp@sip_phone.example.com' and 'skp@wireless_dev.example.com'. Now I want to authorize somebody to be able to see my registration state on the 'PC' and 'SIP_phone' but not the 'Wireless_device' how do we achieve this? I think there are some privacy concerns here that we may have skipped over, the fact that some Contact address may be private and I do not want to share information about that, while others are public.
 
[MB]  I agree that there is a privacy issue here, which is probably very similar to the one for presence. Therefore it should be stated that a subscription may be authenticated and authorized, whereby the mechanism for authorization is outside the scope of the reg-event draft. The watcher info package may be used for the reg event to inform the "owner" of the registration about subscriptions.

   Thanks,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: BECKMANN MARK [mailto:mark.beckmann@sal.siemens.de]
Sent: Thursday, July 25, 2002 7:43 AM
To: 'sip@ietf.org'
Subject: [Sip] Comments on draft-rosenberg-sip-reg-00
Importance: High


Hi Jonathan,

in your draft on the event package for registrations, you proposed the
following FSM for the contacts registered with an adress of record:
                                                                       
                                                                         
                                 +------+                                
                                 |      | refreshed                      
                                 |      |                                
                                 V      |                                
    +------------+            +------------+            +------------+   
    |            |            |            |            |            |   
    |    Init    |----------->|   Active   |----------->| Terminated |   
    |            |            |            |            |            |   
    +------------+ registered +------------+ expired    +------------+   
                   created                   deactivated                 
                                             probation                   
                                             unregistered                
                                             rejected                    
                                                                         

In section 3.1 it is described that in case an administrator wants a device
to re-authenticate, the registration is terminated and the device is
notified, e.g. by setting the event parameter to "deactivated".

First of all, I can't see a big difference between the two events "expired"
and "deactivated". "Deactivated" seems to be part of the "expired" event. In
both cases the contact may be re-registered. It doesn't seem very important
whether the registration is moved to the terminated state because it has
expired or because it has been deactivated.

Secondly, I think in case an administrator wants a device to
re-authenticate, the registration of the corresponding contact should not
move to the terminated state. Instead, another event (for example
"re-authenticate") similar to the "refresh" event should be introduced. When
this event occurs, the device is notified and the duration for which the
contact remains registered is reduced and if the device fails to
re-register, the registration is moved to the terminated state e.g. via the
"expired" event.

Thus, the FSM would look like:
                                                                         
                                 +------+                                
                                 |      | refreshed                      
                                 |      | re-authenticate

                                 V      |                                
    +------------+            +------------+            +------------+   
    |            |            |            |            |            |   
    |    Init    |----------->|   Active   |----------->| Terminated |   
    |            |            |            |            |            |   
    +------------+ registered +------------+            +------------+   
                   created                   expired              
                                             probation           
                                             unregistered          
                                             rejected              

Best regards,


Mark


Mark Beckmann                   Siemens AG

ICM MP P PS 4S2
P.O.Box 100702                  phone: +49 (5341) 906 1814
D-38228 Salzgitter              fax:   +49 (5341) 906 2010

mailto: Mark.Beckmann@siemens.com



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

------_=_NextPart_001_01C234A2.2D0D7C40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 11:34:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25550 for ; Fri, 26 Jul 2002 11:34:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01608 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 11:35:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29162; Fri, 26 Jul 2002 11:02:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29126 for ; Fri, 26 Jul 2002 11:02:03 -0400 (EDT) Received: from jupiter.securelogix.com ([207.193.132.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23550 for ; Fri, 26 Jul 2002 11:00:56 -0400 (EDT) Received: by jupiter with Internet Mail Service (5.5.2448.0) id <3M5YN3XZ>; Fri, 26 Jul 2002 10:01:30 -0500 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FE5E@jupiter> From: David Oliver To: "'Rosen, Brian'" , "'Eiji Tomimura'" , sip@ietf.org Subject: RE: [Sip] Question about ABNF for SIP Date: Fri, 26 Jul 2002 10:01:29 -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@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Eiji, Although an implementation MUST generate precisely correct (RFC3261) syntax, it SHOULD accept all syntax it can interpret (i.e. not object to technical errors where the meaning is still clear), according to the "robustness principle" defined in section 3.2 of RFC791 [4]: an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. This would allow (for example) your implementation to interwork with other implementations based erroneously on the bis-09 syntax, manually entered scripts, or with other minor bugs such as misunderstood printf formats. For example, a more robust acceptance syntax could be: rfc1123-date = wkday *SP "," *SP date1 1*SP time 1*SP "GMT" date1 = 1*2DIGIT 1*SP month 1*SP 4DIGIT time = 1*2DIGIT ":" *SP 1*2DIGIT ":" *SP 1*2DIGIT This would accept the following dates: Fri, 05 Jul 2002 09:40:01 GMT -- strict syntax. Fri, 5 Jul 2002 9:40: 1 GMT -- printf with leading zeros as space. Fri, 5 Jul 2002 9:40:1 GMT -- printf with missing leading zeros. Fri , 05 Jul 2002 09:40:01 GMT -- hand entered, with bad spacing -- due to variable sized font. The acceptance syntax is not significantly more difficult to implement except in the smallest embedded implementations, and does not cause ambiguity. Of course, if the extended syntax caused performance or other problems, it would be the first candidate for removal. Regards, David C. Oliver Principal Engineer SecureLogix Corp Email: doliver@securelogix.com Tel: 210.402.9669 Fax: 210.402.6996 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Wednesday, July 03, 2002 7:00 AM To: 'Eiji Tomimura'; sip@ietf.org Subject: RE: [Sip] Question about ABNF for SIP This problem has been reported before. We fixed it in the text of the forthcoming RFC. The SP is added. Brian > -----Original Message----- > From: Eiji Tomimura [mailto:tomimura@sei.co.jp] > Sent: Wednesday, July 03, 2002 5:10 AM > To: sip@ietf.org > Subject: [Sip] Question about ABNF for SIP > > > Dear all, > > I have a question regarding ABNF for SIP. > > In bis-09, it defines that : > rfc1123-date = wkday "," date1 SP time SP "GMT" > > Though, in RFC2616 "HTTP/1.1", it defines that: > rfc1123-date = wkday "," SP date1 SP time SP "GMT" > > Is it intentional? Or, is it a bug of either side? > > Becauses our SIP layer is based on RFC2616 format, it reject > Date header > follows the format of bis-09 as syntax error. So I'm > wondering which format > should we use. > > Thanks in advance. > > Regards, > - Eiji Tomimura > > -- > Eiji Tomimura > Senior Engineer > Communications Technology Dept., Information Technology R&D > Laboratories > Sumitomo Electric Industries, Ltd. > Phone: +81-6-6466-5643 Fax: +81-6-6466-5732 Email: > tomimura@sei.co.jp > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 11:45:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26112 for ; Fri, 26 Jul 2002 11:45:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02180 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 11:46:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00166; Fri, 26 Jul 2002 11:17:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00135 for ; Fri, 26 Jul 2002 11:17:17 -0400 (EDT) Received: from mirlo.dit.upm.es (mirlo.dit.upm.es [138.4.5.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24735 for ; Fri, 26 Jul 2002 11:16:10 -0400 (EDT) Received: from perdiz (perdiz [138.4.50.3]) by mirlo.dit.upm.es (8.8.5/8.7.3) with SMTP id PAA28713 for ; Fri, 26 Jul 2002 15:18:09 GMT From: =?iso-8859-1?Q?Manuel_Moreno_Mart=EDn?= To: Date: Fri, 26 Jul 2002 17:19:10 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit mmoreno@cipres.upm.es _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 12:08:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27483 for ; Fri, 26 Jul 2002 12:08:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04704 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 12:09:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01649; Fri, 26 Jul 2002 11:35:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01618 for ; Fri, 26 Jul 2002 11:35:39 -0400 (EDT) Received: from mirlo.dit.upm.es (mirlo.dit.upm.es [138.4.5.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25579 for ; Fri, 26 Jul 2002 11:34:32 -0400 (EDT) Received: from perdiz (perdiz [138.4.50.3]) by mirlo.dit.upm.es (8.8.5/8.7.3) with SMTP id PAA28724 for ; Fri, 26 Jul 2002 15:36:31 GMT From: =?iso-8859-1?Q?Manuel_Moreno_Mart=EDn?= To: Date: Fri, 26 Jul 2002 17:37:32 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Message body for 200 response Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I want to know more over the body of SIP messages. In the book "UNDERSTANDING THE SESSION INITIATION PROTOCOL", of Alan B. Johnston (page 80), I have read : "For 200 OK responses to BYE, CANCEL, INFO, and PRACK, a message body is not permitted" But now, in the RFC 3261 (SIP), page 33, I read: "All responses MAY include a body" Please, I want to know more over this issue Thank you for your time Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 15:47:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06009 for ; Fri, 26 Jul 2002 15:47:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18612 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 15:48:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16848; Fri, 26 Jul 2002 15:16:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16814 for ; Fri, 26 Jul 2002 15:16:09 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04977 for ; Fri, 26 Jul 2002 15:15:04 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6QJ4GhI003919; Fri, 26 Jul 2002 12:04:16 -0700 (PDT) Received: from dhcp-171-71-66-153.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAO70328; Fri, 26 Jul 2002 12:03:09 -0700 (PDT) Date: Fri, 26 Jul 2002 12:04:16 -0700 Subject: Re: [Sip] Message body for 200 response Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: =?ISO-8859-1?Q?Manuel_Moreno_Mart=EDn?= From: Rohan Mahy In-Reply-To: Message-Id: <7B1E97C2-A0CA-11D6-A4AE-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA16815 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Friday, July 26, 2002, at 08:37 AM, Manuel Moreno Martín wrote: > I want to know more over the body of SIP messages. > > In the book "UNDERSTANDING THE SESSION INITIATION PROTOCOL", of Alan B. > Johnston (page 80), I have read : "For 200 OK responses to BYE, CANCEL, > INFO, and PRACK, a message body is not permitted" > > But now, in the RFC 3261 (SIP), page 33, I read: "All responses MAY > include > a body" RFC 3261 takes precedence until another WG document updates or obsoletes it. thx, - > Please, I want to know more over this issue > > Thank you for your time > > Manuel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jul 26 15:49:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06099 for ; Fri, 26 Jul 2002 15:49:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18717 for sip-archive@odin.ietf.org; Fri, 26 Jul 2002 15:51:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16409; Fri, 26 Jul 2002 15:05:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16378 for ; Fri, 26 Jul 2002 15:05:42 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04541 for ; Fri, 26 Jul 2002 15:04:37 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6QJ2SuL013399; Fri, 26 Jul 2002 12:02:28 -0700 (PDT) Received: from dhcp-171-71-66-153.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAO70294; Fri, 26 Jul 2002 12:01:21 -0700 (PDT) Date: Fri, 26 Jul 2002 12:02:29 -0700 Subject: Re: [Sip] refer-06 question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Vijay S Kamath , sip@ietf.org To: patrick.mourot@online.fr From: Rohan Mahy In-Reply-To: <1027684430.3d41384e6a93d@imp.free.fr> Message-Id: <3B58ABF1-A0CA-11D6-A4AE-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA16379 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Friday, July 26, 2002, at 04:53 AM, patrick.mourot@online.fr wrote: > vsk, > > Thanks for the answer. > I understand both cases; but this does not light my way. > Let me put it in other words. > > can i delay the notification until the referenced request completes? > leading to send only 1 notification???? (assuming timers are OK). hi, not really. its almost impossible to be sure that you can make sure the timers are OK. > Or am i oblige to send a 1rst notification, wait for completion of the > referenced request and send a final notification ? the later. so a minimal implementation would send first an immediate NOTIFY with the following body SIP/2.0 100 Trying and then upon success/failure a 200, 501, etc.. as described in the draft now. thanks, -rohan > What is mandatory? > > Patrick > > > Quoting Vijay S Kamath : > >> It can be either 1 or more, but at least 1. >> Qouting Section 2.4.7: "Each NOTIFY must contain a Subscription-State >> header field as defined >> in [2]. The final NOTIFY sent in response to a REFER MUST indicate >> the subscription has been "terminated" with a reason of >> "noresource"." >> >> The final NOTIFY can also be the first NOTIFY. >> >> Regards... Vijay >> >> -----Original Message----- >> From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] >> Sent: Friday, July 26, 2002 2:48 PM >> To: sip@ietf.org >> Subject: [Sip] refer-06 question >> >> >> Sir, >> >> >> In 2.4.5 § of refer-06 draft It is stated that a "A minimal, but >> complete, >> implementation can respond with a single NOTIFY containing either >> ...the >> body: >> SIP/2.0 200 OK if the reference was successful". >> >> It seems to be in contradiction with § 3.10 saying that "Alternatively, >> the >> subscription might only result in two NOTIFY requests, the immediate >> NOTIFY and >> the NOTIFY carrying the final result of the reference". >> >> Do we need 1 or 2 NOTIFY in a minimal implementation? >> >> Best Regards, >> >> Patrick >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jul 27 12:40:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04531 for ; Sat, 27 Jul 2002 12:40:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13822 for sip-archive@odin.ietf.org; Sat, 27 Jul 2002 12:41:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12618; Sat, 27 Jul 2002 12:05:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12590 for ; Sat, 27 Jul 2002 12:05:24 -0400 (EDT) Received: from smtp.inet.fi (smtp.inet.fi [192.89.123.192]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04003 for ; Sat, 27 Jul 2002 12:04:18 -0400 (EDT) Received: from [213.28.243.226] ([213.28.243.226]:33372 "EHLO agni.research.nokia.com") by smtp.inet.fi with ESMTP id ; Sat, 27 Jul 2002 19:04:59 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.6/8.11.2) id g6RG6pI14020; Sat, 27 Jul 2002 19:06:51 +0300 To: sip@ietf.org Cc: Subject: Re: [Sip] refer-06 question References: <60614B15188EBB4FA59F85310C2AC7D620AE88@blr-m1-msg.wipro.com> <1027684430.3d41384e6a93d@imp.free.fr> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <1027684430.3d41384e6a93d@imp.free.fr> Date: 27 Jul 2002 19:06:50 +0300 Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org "patrick.mourot@online.fr" writes: >can i delay the notification until the referenced request completes? >leading to send only 1 notification???? (assuming timers are OK). No. You have to send the initial notification request. The initial NOTIFY request is needed in order to establish the dialog. Also, if the party sending does not care about the eventual result, it can respond with an error message to the initial NOTIFY and get the notification dialog terminated. >Or am i oblige to send a 1rst notification, wait for completion of the >referenced request and send a final notification ? That is the current interpretation, I think. Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 29 05:10:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21524 for ; Mon, 29 Jul 2002 05:10:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23243 for sip-archive@odin.ietf.org; Mon, 29 Jul 2002 05:11:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21680; Mon, 29 Jul 2002 04:36:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21648 for ; Mon, 29 Jul 2002 04:36:00 -0400 (EDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20976 for ; Mon, 29 Jul 2002 04:34:50 -0400 (EDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm573d4502f6; Mon, 29 Jul 2002 08:35:52 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm13a3d40255a; Thu, 25 Jul 2002 14:35:35 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA11595 for ietf-123-outbound.01@ietf.org; Thu, 25 Jul 2002 08:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA11171 for ; Thu, 25 Jul 2002 08:07:32 -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 IAA29798; Thu, 25 Jul 2002 08:06:28 -0400 (EDT) Message-Id: <200207251206.IAA29798@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 25 Jul 2002 08:06:28 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-congestsafe-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation protocol to Assure Congestion Safety Author(s) : D. Willis, B. Campbell Filename : draft-willis-sip-congestsafe-00.txt Pages : 11 Date : 24-Jul-02 The Session Initiation Protocol allows the use of UDP for transport of SIP messages. The use of UDP inherently risks network congestion problems, as UDP itself does not define congestion prevention, avoidance, detection, or correction mechanisms. This problem is aggravated by large SIP messages which fragment at the UDP level. Transport protocols in SIP are also negotiated on a per-hop basis, at the SIP level, so SIP proxies may convert from TCP to UDP and so forth. This document defines what it means for SIP nodes to be congestion safe and specifies an extension by which a SIP User Agent may require that its requests are treated in a congestion safe manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-congestsafe-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-willis-sip-congestsafe-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-willis-sip-congestsafe-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: <20020724142818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-congestsafe-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-congestsafe-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724142818.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 29 05:25:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21656 for ; Mon, 29 Jul 2002 05:25:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23612 for sip-archive@odin.ietf.org; Mon, 29 Jul 2002 05:26:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22387; Mon, 29 Jul 2002 04:58:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22356 for ; Mon, 29 Jul 2002 04:58:14 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21337 for ; Mon, 29 Jul 2002 04:57:07 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6T8uXd07735 for ; Mon, 29 Jul 2002 11:56:33 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Jul 2002 11:58:12 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Jul 2002 11:58:12 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Jul 2002 11:58:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] refer-06 question Date: Mon, 29 Jul 2002 11:58:11 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2041B@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] refer-06 question Thread-Index: AcI0myVTajCt+2/iRVSUXBLTc0GjGQAA3+NAAI9W4+A= To: , Cc: X-OriginalArrivalTime: 29 Jul 2002 08:58:12.0390 (UTC) FILETIME=[117DEC60:01C236DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA22357 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I guess it all depends on how you define "immediate" to mean. If its a matter of seconds, then I think its ok to send the one NOTIFY only. I quote RFC3165 "Until the first NOTIFY message arrives, the subscriber should consider the state of the subscribed resource to be in a neutral state. Documents which define new event packages MUST define this "neutral state" in such a way that makes sense for their application (see section 4.4.7.)." Regards, Hisham > -----Original Message----- > From: ext Vijay S Kamath [mailto:vijay.kamath@wipro.com] > Sent: Friday, July 26, 2002 3:25 PM > To: patrick.mourot@online.fr > Cc: sip@ietf.org > Subject: RE: [Sip] refer-06 question > > > Patrick, > > You cannot delay the notification until the referenced > request completes. > Quoting Sec 2.4.4: "The creation of a subscription as defined > by [1] always results in an > immediate NOTIFY. " > > So I suggest you follow your second suggestion. > > Vijay > > -----Original Message----- > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > Sent: Friday, July 26, 2002 5:24 PM > To: Vijay Kamath > Cc: sip@ietf.org > Subject: RE: [Sip] refer-06 question > > > vsk, > > Thanks for the answer. > I understand both cases; but this does not light my way. > Let me put it in other words. > > can i delay the notification until the referenced request > completes? leading to send only 1 notification???? (assuming > timers are OK). > > Or am i oblige to send a 1rst notification, wait for > completion of the > referenced request and send a final notification ? > > What is mandatory? > > Patrick > > > Quoting Vijay S Kamath : > > > It can be either 1 or more, but at least 1. > > Qouting Section 2.4.7: "Each NOTIFY must contain a > Subscription-State > > header field as defined > > in [2]. The final NOTIFY sent in response to a REFER > MUST indicate > > the subscription has been "terminated" with a reason of > > "noresource"." > > > > The final NOTIFY can also be the first NOTIFY. > > > > Regards... Vijay > > > > -----Original Message----- > > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > > Sent: Friday, July 26, 2002 2:48 PM > > To: sip@ietf.org > > Subject: [Sip] refer-06 question > > > > > > Sir, > > > > > > In 2.4.5 § of refer-06 draft It is stated that a "A minimal, but > > complete, implementation can respond with a single NOTIFY > containing > > either ...the > > body: > > SIP/2.0 200 OK if the reference was successful". > > > > It seems to be in contradiction with § 3.10 saying that > > "Alternatively, the subscription might only result in two NOTIFY > > requests, the immediate NOTIFY and > > the NOTIFY carrying the final result of the reference". > > > > Do we need 1 or 2 NOTIFY in a minimal implementation? > > > > Best Regards, > > > > Patrick > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 29 05:55:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22310 for ; Mon, 29 Jul 2002 05:55:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA24996 for sip-archive@odin.ietf.org; Mon, 29 Jul 2002 05:56:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24360; Mon, 29 Jul 2002 05:35:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24333 for ; Mon, 29 Jul 2002 05:35:10 -0400 (EDT) Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21795 for ; Mon, 29 Jul 2002 05:34:03 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-1.free.fr (Postfix) with ESMTP id D49AC67B; Mon, 29 Jul 2002 11:35:07 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id 890998C033; Mon, 29 Jul 2002 11:35:07 +0200 (MEST) To: hisham.khartabil@nokia.com Subject: RE: [Sip] refer-06 question Message-ID: <1027935307.3d450c4b68d6a@imp.free.fr> Date: Mon, 29 Jul 2002 11:35:07 +0200 (MEST) From: patrick.mourot@online.fr Cc: vijay.kamath@wipro.com, sip@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB7C2041B@esebe019.NOE.Nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7C2041B@esebe019.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 64.208.49.160 Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Assuming that you mean RFC3265, there are several contradictory answers. I would like to suggest that refer-06 should be clearer on the subject. It should describe what a minimal implementation is. Patrick Quoting hisham.khartabil@nokia.com: > I guess it all depends on how you define "immediate" to mean. If its a > matter of seconds, then I think its ok to send the one NOTIFY only. > > I quote RFC3165 > > "Until the first NOTIFY message arrives, the subscriber > should consider the state of the subscribed resource to be in a > neutral state. Documents which define new event packages MUST > define > this "neutral state" in such a way that makes sense for their > application (see section 4.4.7.)." > > Regards, > Hisham > > > -----Original Message----- > > From: ext Vijay S Kamath [mailto:vijay.kamath@wipro.com] > > Sent: Friday, July 26, 2002 3:25 PM > > To: patrick.mourot@online.fr > > Cc: sip@ietf.org > > Subject: RE: [Sip] refer-06 question > > > > > > Patrick, > > > > You cannot delay the notification until the referenced > > request completes. > > Quoting Sec 2.4.4: "The creation of a subscription as defined > > by [1] always results in an > > immediate NOTIFY. " > > > > So I suggest you follow your second suggestion. > > > > Vijay > > > > -----Original Message----- > > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > > Sent: Friday, July 26, 2002 5:24 PM > > To: Vijay Kamath > > Cc: sip@ietf.org > > Subject: RE: [Sip] refer-06 question > > > > > > vsk, > > > > Thanks for the answer. > > I understand both cases; but this does not light my way. > > Let me put it in other words. > > > > can i delay the notification until the referenced request > > completes? leading to send only 1 notification???? (assuming > > timers are OK). > > > > Or am i oblige to send a 1rst notification, wait for > > completion of the > > referenced request and send a final notification ? > > > > What is mandatory? > > > > Patrick > > > > > > Quoting Vijay S Kamath : > > > > > It can be either 1 or more, but at least 1. > > > Qouting Section 2.4.7: "Each NOTIFY must contain a > > Subscription-State > > > header field as defined > > > in [2]. The final NOTIFY sent in response to a REFER > > MUST indicate > > > the subscription has been "terminated" with a reason of > > > "noresource"." > > > > > > The final NOTIFY can also be the first NOTIFY. > > > > > > Regards... Vijay > > > > > > -----Original Message----- > > > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > > > Sent: Friday, July 26, 2002 2:48 PM > > > To: sip@ietf.org > > > Subject: [Sip] refer-06 question > > > > > > > > > Sir, > > > > > > > > > In 2.4.5 § of refer-06 draft It is stated that a "A minimal, but > > > complete, implementation can respond with a single NOTIFY > > containing > > > either ...the > > > body: > > > SIP/2.0 200 OK if the reference was successful". > > > > > > It seems to be in contradiction with § 3.10 saying that > > > "Alternatively, the subscription might only result in two NOTIFY > > > requests, the immediate NOTIFY and > > > the NOTIFY carrying the final result of the reference". > > > > > > Do we need 1 or 2 NOTIFY in a minimal implementation? > > > > > > Best Regards, > > > > > > Patrick > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 29 06:06:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22601 for ; Mon, 29 Jul 2002 06:06:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA25883 for sip-archive@odin.ietf.org; Mon, 29 Jul 2002 06:07:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24669; Mon, 29 Jul 2002 05:42:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24638 for ; Mon, 29 Jul 2002 05:42:20 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21878 for ; Mon, 29 Jul 2002 05:41:11 -0400 (EDT) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g6T9apm01039 for ; Mon, 29 Jul 2002 15:06:51 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C05.00353BF9 ; Mon, 29 Jul 2002 15:11:27 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256C05.00353A06.00@sampark.hss.hns.com> Date: Mon, 29 Jul 2002 15:11:22 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] draft-ietf-sip-sctp-03.txt: comment on unordered delivery Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, In section 4.1 Mapping of SIP Transactions into Streams, it says "..a SIP entity SHOULD send every SIP message (request or response) over stream zero with the unordered flag set..." Are there no SIP extensions which may require ordered delivery from SCTP(sip-isup mapping for instance)? or is the 'SHOULD' supposed to accommodate such exceptions? Later in the same section, it is said "..Some applications introduce an extra layer between the transport layer and SIP (e.g., compression and/or encryption). This extra layer sometimes requires ordered delivery of messages from the transport layer (e.g., TLS [6])." The section then recommends using same stream for maintaining sequence...but no mention is made about whether the unordered flag should be set or not. To maintain sequence, in addition to choosing the same stream, will it not be required that messages be also sent in sequence within a stream(by not setting the unordered flag)? regards Harsh Bhondwe Hughes Software Systems This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 29 08:24:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26315 for ; Mon, 29 Jul 2002 08:24:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01671 for sip-archive@odin.ietf.org; Mon, 29 Jul 2002 08:25:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01008; Mon, 29 Jul 2002 08:02:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00977 for ; Mon, 29 Jul 2002 08:02:49 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25323 for ; Mon, 29 Jul 2002 08:01:08 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6TCE0f12327 for ; Mon, 29 Jul 2002 15:14:00 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Jul 2002 15:02:09 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Jul 2002 15:02:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:recallmessage MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Jul 2002 15:02:08 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20423@esebe019.NOE.Nokia.com> Thread-Topic: [Sip-implementors] Changes from bis-09 to RFC 3261 Thread-Index: AcI298Np/pxZXkrGTPqIHHRoS7SB2A== Priority: Urgent Expiry-Date: Wed, 31 Jul 2002 15:02:06 +0300 To: , , X-OriginalArrivalTime: 29 Jul 2002 12:02:09.0230 (UTC) FILETIME=[C3F60EE0:01C236F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA00978 Subject: [Sip] Recall: [Sip-implementors] Changes from bis-09 to RFC 3261 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Khartabil Hisham (NMP/Helsinki) would like to recall the message, "[Sip-implementors] Changes from bis-09 to RFC 3261". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 29 08:29:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26521 for ; Mon, 29 Jul 2002 08:29:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02215 for sip-archive@odin.ietf.org; Mon, 29 Jul 2002 08:31:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00575; Mon, 29 Jul 2002 08:00:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00521 for ; Mon, 29 Jul 2002 08:00:26 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25230 for ; Mon, 29 Jul 2002 07:58:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6TCBbf10984 for ; Mon, 29 Jul 2002 15:11:37 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Jul 2002 14:59:51 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Jul 2002 14:59:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 29 Jul 2002 14:59:50 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20422@esebe019.NOE.Nokia.com> Thread-Topic: [Sip-implementors] Changes from bis-09 to RFC 3261 Thread-Index: AcIy28mdTu1OQ7GwQb6EDUodLQWF/gEGWdbQ To: , , X-OriginalArrivalTime: 29 Jul 2002 11:59:51.0117 (UTC) FILETIME=[71A3AFD0:01C236F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA00525 Subject: [Sip] RE: [Sip-implementors] Changes from bis-09 to RFC 3261 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I trimmed those for our needs. I'll send the raw changes as sent to the sip mailing list in another following mail. /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 24, 2002 8:52 AM > To: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Changes from bis-09 to RFC 3261 > > * It was reported that the processing of timer D in the transaction > layer was wrong. This is the timer that fires in the INVITE client > transaction after it has ceased waiting for retransmits of the final > response, in order to send an ACK. Bis-09 said to inform the TU of a > timeout. However, this is not a failure condition, so that makes no > sense. As such, Section 17.1.1.2, now reads: > > "If timer D fires while the client transaction is in the "Completed" > state, the client transaction MUST move to the terminated state." > > > * We clarified that, when moving to terminated state for client invite > transactions, you need to delete the transaction immediately. > > * The rules in Section 17.2.3, for matching a request to a > transaction when the branch ID had the cookie, were not quite > right. In particular, they were wrong for > CANCEL. The rules were updated: > > The > request matches a transaction if: > > 1. the branch parameter in the request > is equal to the one in the top Via header field of the > request that > created the transaction, and > > 2. the sent-by value in the top Via of the > request is equal to the one in the request that created the > transaction, and > > 3. the method of the request matches the one that created > the transaction, except for ACK, where the method of the > request that > created the transaction is INVITE. > > > * Section 18.1.1 led you to believe that if a request was too large > for UDP, and you resent it, it had to be with TCP. ACtually, it can be > with any congestion controlled transport (as defined by RFC 2914). We > also clarified that if you change transports, the Via transport value > needs to change. (its TCP in any case for our sip stack) > > * Rules for equality matching of From and To header fields were > absent, even though there were references elsewhere in the text to the > existence of such rules. They were added. See Sections 20.20 and > 20.39. > > > * The spec was inconsistent on the maximum value of the expires > Contact parameter and the Expires header field. They were made > consistent. The maximum value is (2**32)-1. > > > * Section 20.37, on the Unsupported header field, failed to mention > that a compact form was defined (the other headers with compact forms > explicitly mention it in their section 20's). A mention was added. > > * The transaction matching algorithm requires rules for equality of > Via header fields, but none was defined. A rule was added, see Section > 20.42. > > * Section 21.4.15 indicated that inclusion of the unsupported > extensions in a 420 response was a SHOULD. This is inconsistent with > other text that said it was a MUST. Its a MUST. Section 21.4.15 was > updated to reflect that. > > > * The BNF had this construct where there was a list of choices, and > one of the elements in the choice was optional: > > > foo = bar / baz / [boo] > > turns out, this is actually not right, since it allows for an empty > value for foo, which is not what is intended. Therefore, the text that > described this convention, and all usages of it in the BNF, were > removed. > > * The BNF for the user part of the SIP/SIPS URI allowed for an empty > username and an @ sign; that is "sip:@foo.com" was valid according to > the BNF. Its not. The BNF for the SIP-URI and SIPS-URI constructions > was updated to correct this. Here is the change that was made (^ > characters indicate where the change is): > > > OLD > SIP-URI = "sip:" [ userinfo "@" ] hostport > uri-parameters [ headers ] > SIPS-URI = "sips:" [ userinfo "@" ] hostport > uri-parameters [ headers ] > userinfo = [ user / telephone-subscriber [ ":" > password ]] > user = *( unreserved / escaped / user-unreserved ) > > NEW > SIP-URI = "sip:" [ userinfo ] hostport > ^^ delete "@" > uri-parameters [ headers ] > SIPS-URI = "sips:" [ userinfo ] hostport > ^^ delete "@" > uri-parameters [ headers ] > userinfo = ( user / telephone-subscriber ) [ ":" > password ] "@" > ^ ^ > ^^^^ > user = 1*( unreserved / escaped / user-unreserved ) > ^ > > * The Accept, Accept-Encoding, and Accept-Language and Allow > BNF were all > updated to allow for the header to have an empty value. > > > * The BNF for rfc1123-date was wrong. It was missing a space after the > comma. It was corrected thusly: > > OLD > rfc1123-date = wkday "," date1 SP time SP "GMT" > > NEW > rfc1123-date = wkday "," SP date1 SP time SP "GMT" > ^^ > > * The BNF for the Timestamp header was wrong. It was missing an > explicit LWS between the the send time and the delay. It was > added. The BNF was changed thusly: > > > OLD > Timestamp = "Timestamp" HCOLON 1*(DIGIT) > [ "." *(DIGIT) ] [ delay ] > > NEW > Timestamp = "Timestamp" HCOLON 1*(DIGIT) > [ "." *(DIGIT) ] [ LWS delay ] > ^^^ //lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 29 11:01:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02908 for ; Mon, 29 Jul 2002 11:01:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10742 for sip-archive@odin.ietf.org; Mon, 29 Jul 2002 11:02:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08971; Mon, 29 Jul 2002 10:31:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08940 for ; Mon, 29 Jul 2002 10:31:51 -0400 (EDT) Received: from dyn-tx-app-007.dfw.dynamicsoft.com ([63.110.3.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01342 for ; Mon, 29 Jul 2002 10:30:43 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6T8eV128855; Mon, 29 Jul 2002 03:40:37 -0500 Subject: RE: [Sip] refer-06 question From: Robert Sparks To: patrick.mourot@online.fr Cc: hisham.khartabil@nokia.com, vijay.kamath@wipro.com, sip@ietf.org In-Reply-To: <1027935307.3d450c4b68d6a@imp.free.fr> References: <2038BCC78B1AD641891A0D1AE133DBB7C2041B@esebe019.NOE.Nokia.com> <1027935307.3d450c4b68d6a@imp.free.fr> Content-Type: text/plain; charset=ISO-8859-15 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 29 Jul 2002 09:29:45 -0500 Message-Id: <1027952996.6720.9.camel@dhcp112.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA08941 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit rfc3265 is authoritative for matters involving sip-events. Refer only uses it. You cannot wait for the referenced request to complete. RFC3265 requires the NOTIFY to be sent as soon as the SUBSCRIBE is accepted (the language Hisham quotes deals with the period between requesting the subscription and receiving the first notify - that period needs to be short. Trying to use it to sneak in some processing time you hope to be short will introduce HERFP troubles later). An immediate NOTIFY must be sent. If you have the final results at hand, (through policy for example), that NOTIFY can contain the final result and be the only NOTIFY sent. Normally, you will have to actually make the referenced request, and at least two NOTIFYs will be sent. RjS On Mon, 2002-07-29 at 04:35, patrick.mourot@online.fr wrote: > > Assuming that you mean RFC3265, there are several contradictory answers. > I would like to suggest that refer-06 should be clearer on the subject. > It should describe what a minimal implementation is. > > Patrick > > Quoting hisham.khartabil@nokia.com: > > > I guess it all depends on how you define "immediate" to mean. If its a > > matter of seconds, then I think its ok to send the one NOTIFY only. > > > > I quote RFC3165 > > > > "Until the first NOTIFY message arrives, the subscriber > > should consider the state of the subscribed resource to be in a > > neutral state. Documents which define new event packages MUST > > define > > this "neutral state" in such a way that makes sense for their > > application (see section 4.4.7.)." > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Vijay S Kamath [mailto:vijay.kamath@wipro.com] > > > Sent: Friday, July 26, 2002 3:25 PM > > > To: patrick.mourot@online.fr > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] refer-06 question > > > > > > > > > Patrick, > > > > > > You cannot delay the notification until the referenced > > > request completes. > > > Quoting Sec 2.4.4: "The creation of a subscription as defined > > > by [1] always results in an > > > immediate NOTIFY. " > > > > > > So I suggest you follow your second suggestion. > > > > > > Vijay > > > > > > -----Original Message----- > > > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > > > Sent: Friday, July 26, 2002 5:24 PM > > > To: Vijay Kamath > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] refer-06 question > > > > > > > > > vsk, > > > > > > Thanks for the answer. > > > I understand both cases; but this does not light my way. > > > Let me put it in other words. > > > > > > can i delay the notification until the referenced request > > > completes? leading to send only 1 notification???? (assuming > > > timers are OK). > > > > > > Or am i oblige to send a 1rst notification, wait for > > > completion of the > > > referenced request and send a final notification ? > > > > > > What is mandatory? > > > > > > Patrick > > > > > > > > > Quoting Vijay S Kamath : > > > > > > > It can be either 1 or more, but at least 1. > > > > Qouting Section 2.4.7: "Each NOTIFY must contain a > > > Subscription-State > > > > header field as defined > > > > in [2]. The final NOTIFY sent in response to a REFER > > > MUST indicate > > > > the subscription has been "terminated" with a reason of > > > > "noresource"." > > > > > > > > The final NOTIFY can also be the first NOTIFY. > > > > > > > > Regards... Vijay > > > > > > > > -----Original Message----- > > > > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > > > > Sent: Friday, July 26, 2002 2:48 PM > > > > To: sip@ietf.org > > > > Subject: [Sip] refer-06 question > > > > > > > > > > > > Sir, > > > > > > > > > > > > In 2.4.5 § of refer-06 draft It is stated that a "A minimal, but > > > > complete, implementation can respond with a single NOTIFY > > > containing > > > > either ...the > > > > body: > > > > SIP/2.0 200 OK if the reference was successful". > > > > > > > > It seems to be in contradiction with § 3.10 saying that > > > > "Alternatively, the subscription might only result in two NOTIFY > > > > requests, the immediate NOTIFY and > > > > the NOTIFY carrying the final result of the reference". > > > > > > > > Do we need 1 or 2 NOTIFY in a minimal implementation? > > > > > > > > Best Regards, > > > > > > > > Patrick > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 29 16:40:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14251 for ; Mon, 29 Jul 2002 16:40:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28522 for sip-archive@odin.ietf.org; Mon, 29 Jul 2002 16:41:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26584; Mon, 29 Jul 2002 16:01:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26526 for ; Mon, 29 Jul 2002 16:01:11 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13122 for ; Mon, 29 Jul 2002 16:00:02 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6TK0X315213; Mon, 29 Jul 2002 15:00:33 -0500 From: "Dean Willis" To: "'BECKMANN MARK'" , , Subject: RE: [Sip] Comments on draft-rosenberg-sip-reg-00 Date: Mon, 29 Jul 2002 15:00:26 -0500 Message-ID: <001501c2373a$950d1a90$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark said: > Secondly, I think in case an administrator wants a device to > re-authenticate, the registration of the corresponding > contact should not move to the terminated state. Instead, > another event (for example > "re-authenticate") similar to the "refresh" event should be > introduced. When this event occurs, the device is notified > and the duration for which the contact remains registered is > reduced and if the device fails to re-register, the > registration is moved to the terminated state e.g. via the > "expired" event. As I understand it, we want a UA to still work "properly" for a while after it has been asked to reauthenticate. If the proxy actually terminates the registration, one might assume it deletes the associated contact from its storage. An incoming request (say, INVITE) that arrives at the proxy between this deletion and the reinsertion of the contact following a new registration from the UA would then be handled as if the UA was not registered (as in "turned off"). So, I believe Mark's concerns here are valid and we do need another state in the FSM. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jul 29 16:42:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14319 for ; Mon, 29 Jul 2002 16:42:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28599 for sip-archive@odin.ietf.org; Mon, 29 Jul 2002 16:43:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26559; Mon, 29 Jul 2002 16:01:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26509 for ; Mon, 29 Jul 2002 16:01:09 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13114 for ; Mon, 29 Jul 2002 16:00:00 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6TK0Y315216; Mon, 29 Jul 2002 15:00:34 -0500 From: "Dean Willis" To: "'Jonathan Rosenberg'" , , Subject: RE: [Sip] Changes from bis-09 to RFC 3261 Date: Mon, 29 Jul 2002 15:00:26 -0500 Message-ID: <001601c2373a$9562b4a0$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3D3E4091.8030200@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan wrote: > There were approximately 150 changes made to bis-09 for the > generation of RFC 3261. Coming up with this list was an > exercise in extremely detailed and painful review of the > document, something which took us a great deal of time. The > vast majority of these were typos, comma insertions, > indentation fixes, and so on. However, there were a few dozen > changes that reflect "bug fixes" which were reported between > bis-09 and RFC 3261. Here is a summary of those of any > significance whatsoever (you > will find most to be trivial): This seems to be pretty useful. I have posted it to the supplementary working group web site under the "References" section. See: http://www.softarmor.com/sipwg/references/changes-bis09-to-3261.html -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 30 00:05:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24914 for ; Tue, 30 Jul 2002 00:05:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA18272 for sip-archive@odin.ietf.org; Tue, 30 Jul 2002 00:06:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16909; Mon, 29 Jul 2002 23:36:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16878 for ; Mon, 29 Jul 2002 23:36:27 -0400 (EDT) Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24399 for ; Mon, 29 Jul 2002 23:35:19 -0400 (EDT) Received: from deewana (pool-138-88-40-49.res.east.verizon.net [138.88.40.49]) by repulse.cnchost.com id XAA17470; Mon, 29 Jul 2002 23:36:25 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <00e301c2377c$48a88030$0100000a@nextone.com> From: "Medhavi Bhatia" To: Date: Mon, 29 Jul 2002 23:50:44 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] B2B UA definition Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi all, Very many times I have seen a discussion on B2B UA's end merely in a definition of a B2BUA: "A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." However I believe this is quite incomplete. For example: 1) A B2BUA behaves similar to a proxy in that it must maintain "timer C" on outgoing transactions - which is unlike a UAC. 2) It SHOULD maintain max forwards on request in/requests out basis. Moreover it SHOULD have a defined relationship between incoming and outgoing requests. The way the definition goes, the outgoing request can have completely new headers, which eventually will cause a problem in loop detection/ policy and configuration at a remote destination. Clearly there may be reasons for new headers, but certain headers should be maintained for proper SIP network operation. 3) It has a notion similar to a response context of a proxy, and thus of forking requests etc etc... I believe that the SIP rfc describes a "server" role as a stateful/stateless proxy and completely specifies it. However a "server" can also be implemented as a B2BUA, so it should talk some more about it, or the requirements should be spelled out somewhere. A completely loose definition might just lead to deployment problems in future. -Medhavi. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 30 00:46:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25708 for ; Tue, 30 Jul 2002 00:46:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA19648 for sip-archive@odin.ietf.org; Tue, 30 Jul 2002 00:48:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18459; Tue, 30 Jul 2002 00:16:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18428 for ; Tue, 30 Jul 2002 00:16:43 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25028 for ; Tue, 30 Jul 2002 00:15:35 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6U4GZhZ071140; Mon, 29 Jul 2002 23:16:35 -0500 (CDT) Message-ID: <3D46130E.80901@dynamicsoft.com> Date: Mon, 29 Jul 2002 23:16:14 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Medhavi Bhatia CC: sip@ietf.org Subject: Re: [Sip] B2B UA definition References: <00e301c2377c$48a88030$0100000a@nextone.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Medhavi Bhatia wrote: > Hi all, > > Very many times I have seen a discussion on B2B UA's end merely in a > definition > of a B2BUA: > "A back-to-back user agent (B2BUA) is a > logical entity that receives a request and processes it as a > user agent server (UAS). In order to determine how the request > should be answered, it acts as a user agent client (UAC) and > generates requests. Unlike a proxy server, it maintains dialog > state and must participate in all requests sent on the dialogs > it has established. Since it is a concatenation of a UAC and > UAS, no explicit definitions are needed for its behavior." > > However I believe this is quite incomplete. For example: > > 1) A B2BUA behaves similar to a proxy in that it must maintain "timer C" on > outgoing transactions - which is unlike a UAC. > 2) It SHOULD maintain max forwards on request in/requests out basis. > Moreover > it SHOULD have a defined relationship between incoming and outgoing > requests. > The way the definition goes, the outgoing request can have completely new > headers, > which eventually will cause a problem in loop detection/ policy and > configuration > at a remote destination. Clearly there may be reasons for new headers, but > certain > headers should be maintained for proper SIP network operation. > 3) It has a notion similar to a response context of a proxy, and thus of > forking > requests > etc etc... I think these things greatly overconstrain a b2bua. If we follow this path to the logical conclusion, a b2bua is just another way to implement a proxy. For example, is it not permissible to create a b2bua that, when it receives one request, generates several? Or when it receives a FOO request, emits a BAR request? A b2bUA must act as a proper UAS on one side, and a proper UAC on the other. That should be enough. You describe some particular application(s) of a b2bua, where the inbound and outbound dialogs are linked in a way that is at least somewhat transparent to other devices. I think there are many b2bua applications where that is not the case at all. For example, can I not create a b2bua, where the downstream devices cannot tell that the upstream devices exist? > > I believe that the SIP rfc describes a "server" role as a stateful/stateless > proxy and > completely specifies it. However a "server" can also be implemented as a > B2BUA, > so it should talk some more about it, or the requirements should be spelled > out > somewhere. A completely loose definition might just lead to deployment > problems > in future. > > -Medhavi. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 30 00:51:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25832 for ; Tue, 30 Jul 2002 00:51:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA19791 for sip-archive@odin.ietf.org; Tue, 30 Jul 2002 00:52:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18977; Tue, 30 Jul 2002 00:30:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18930 for ; Tue, 30 Jul 2002 00:30:27 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25473 for ; Tue, 30 Jul 2002 00:29:19 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6U4Tk9V022015; Mon, 29 Jul 2002 21:29:46 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACG48611; Mon, 29 Jul 2002 21:25:22 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id VAA05832; Mon, 29 Jul 2002 21:29:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15686.5698.161756.629591@thomasm-u1.cisco.com> Date: Mon, 29 Jul 2002 21:29:54 -0700 (PDT) To: "Medhavi Bhatia" Cc: Subject: [Sip] B2B UA definition In-Reply-To: <00e301c2377c$48a88030$0100000a@nextone.com> References: <00e301c2377c$48a88030$0100000a@nextone.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Is there any reason at all to say what a B2BUA is and/or needs to do? *Anything* can be a B2BUA, and I don't see why its behavior should be defined any more than defining the nature of my procmail recipes wrt SMTP. It was a good thing to illustrate that a B2BUA could exist, but I just don't see that we should go overboard... Mike Medhavi Bhatia writes: > Hi all, > > Very many times I have seen a discussion on B2B UA's end merely in a > definition > of a B2BUA: > "A back-to-back user agent (B2BUA) is a > logical entity that receives a request and processes it as a > user agent server (UAS). In order to determine how the request > should be answered, it acts as a user agent client (UAC) and > generates requests. Unlike a proxy server, it maintains dialog > state and must participate in all requests sent on the dialogs > it has established. Since it is a concatenation of a UAC and > UAS, no explicit definitions are needed for its behavior." > > However I believe this is quite incomplete. For example: > > 1) A B2BUA behaves similar to a proxy in that it must maintain "timer C" on > outgoing transactions - which is unlike a UAC. > 2) It SHOULD maintain max forwards on request in/requests out basis. > Moreover > it SHOULD have a defined relationship between incoming and outgoing > requests. > The way the definition goes, the outgoing request can have completely new > headers, > which eventually will cause a problem in loop detection/ policy and > configuration > at a remote destination. Clearly there may be reasons for new headers, but > certain > headers should be maintained for proper SIP network operation. > 3) It has a notion similar to a response context of a proxy, and thus of > forking > requests > etc etc... > > I believe that the SIP rfc describes a "server" role as a stateful/stateless > proxy and > completely specifies it. However a "server" can also be implemented as a > B2BUA, > so it should talk some more about it, or the requirements should be spelled > out > somewhere. A completely loose definition might just lead to deployment > problems > in future. > > -Medhavi. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 30 02:47:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06600 for ; Tue, 30 Jul 2002 02:47:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA02720 for sip-archive@odin.ietf.org; Tue, 30 Jul 2002 02:48:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01435; Tue, 30 Jul 2002 02:25:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01399 for ; Tue, 30 Jul 2002 02:25:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06214 for ; Tue, 30 Jul 2002 02:24:07 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6U6OihI013184; Mon, 29 Jul 2002 23:24:44 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADO91294; Mon, 29 Jul 2002 23:24:57 -0700 (PDT) From: "Cullen Jennings" To: "Medhavi Bhatia" , Subject: RE: [Sip] B2B UA definition Date: Mon, 29 Jul 2002 23:25:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <00e301c2377c$48a88030$0100000a@nextone.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think that a B2BUA should meet the requirements of a UAC on one side and a UAS on the other. I am fine with it resetting max forwards and all the other stuff you mention. If you consider a call from a UA to gateway that go across the PSTN to another gateway to a UA, you realize the PSTN is one large B2BUA. I don't think B2BUAs would benefit much from further definition than it has today. However, you could get me going about what a "transparent" B2BUA is :-) Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Medhavi > Bhatia > Sent: Monday, July 29, 2002 8:51 PM > To: sip@ietf.org > Subject: [Sip] B2B UA definition > > > Hi all, > > Very many times I have seen a discussion on B2B UA's end merely in a > definition > of a B2BUA: > "A back-to-back user agent (B2BUA) is a > logical entity that receives a request and processes it as a > user agent server (UAS). In order to determine how the request > should be answered, it acts as a user agent client (UAC) and > generates requests. Unlike a proxy server, it maintains dialog > state and must participate in all requests sent on the dialogs > it has established. Since it is a concatenation of a UAC and > UAS, no explicit definitions are needed for its behavior." > > However I believe this is quite incomplete. For example: > > 1) A B2BUA behaves similar to a proxy in that it must maintain > "timer C" on > outgoing transactions - which is unlike a UAC. > 2) It SHOULD maintain max forwards on request in/requests out basis. > Moreover > it SHOULD have a defined relationship between incoming and outgoing > requests. > The way the definition goes, the outgoing request can have completely new > headers, > which eventually will cause a problem in loop detection/ policy and > configuration > at a remote destination. Clearly there may be reasons for new headers, but > certain > headers should be maintained for proper SIP network operation. > 3) It has a notion similar to a response context of a proxy, and thus of > forking > requests > etc etc... > > I believe that the SIP rfc describes a "server" role as a > stateful/stateless > proxy and > completely specifies it. However a "server" can also be implemented as a > B2BUA, > so it should talk some more about it, or the requirements should > be spelled > out > somewhere. A completely loose definition might just lead to deployment > problems > in future. > > -Medhavi. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 30 03:37:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07218 for ; Tue, 30 Jul 2002 03:37:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA05282 for sip-archive@odin.ietf.org; Tue, 30 Jul 2002 03:39:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03944; Tue, 30 Jul 2002 03:08:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03910 for ; Tue, 30 Jul 2002 03:08:30 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06831 for ; Tue, 30 Jul 2002 03:07:22 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6U78MRb013152; Tue, 30 Jul 2002 09:08:22 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g6U78La9020477; Tue, 30 Jul 2002 10:08:21 +0300 (EET DST) Message-ID: <3D463B64.D8037AF6@lmf.ericsson.se> Date: Tue, 30 Jul 2002 10:08:20 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hbhondwe@hss.hns.com CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-sctp-03.txt: comment on unordered delivery References: <65256C05.00353A06.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, By reading the paragraph you refer to, it is pretty clear that the unordered flag should not be set in the case you are talking about. Thanks, Gonzalo hbhondwe@hss.hns.com wrote: > > Hi, > > In section 4.1 Mapping of SIP Transactions into Streams, > it says > "..a SIP entity SHOULD send every SIP message > (request or response) over stream zero with the unordered flag set..." > > Are there no SIP extensions which may require ordered delivery from > SCTP(sip-isup mapping for instance)? > or is the 'SHOULD' supposed to accommodate such exceptions? > > Later in the same section, it is said "..Some applications introduce an > extra layer between the transport > layer and SIP (e.g., compression and/or encryption). This extra layer > sometimes requires ordered delivery of messages from the transport > layer (e.g., TLS [6])." > > The section then recommends using same stream for maintaining > sequence...but no mention is made about whether the unordered flag should > be set or not. To maintain sequence, in addition to choosing the same > stream, will it not be required that messages be also sent in sequence > within a stream(by not setting the unordered flag)? > > regards > Harsh Bhondwe > Hughes Software Systems > > This message is proprietary to Hughes Software Systems Limited (HSS) and is > intended solely for the use of the individual to whom it is addressed. It > may contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. If > you have received this message in error, please notify the originator > immediately. If you are not the intended recipient, you are notified that > you are strictly prohibited from using, copying, altering, or disclosing > the contents of this message. HSS accepts no responsibility for loss or > damage arising from the use of the information transmitted by this email > including damage from virus. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jul 30 10:56:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22191 for ; Tue, 30 Jul 2002 10:56:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01254 for sip-archive@odin.ietf.org; Tue, 30 Jul 2002 10:57:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29709; Tue, 30 Jul 2002 10:30:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29654 for ; Tue, 30 Jul 2002 10:30:48 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20381 for ; Tue, 30 Jul 2002 10:29:40 -0400 (EDT) Received: from OranLT.cisco.com ([161.44.238.36]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6UEUAhI009890; Tue, 30 Jul 2002 07:30:10 -0700 (PDT) Date: Tue, 30 Jul 2002 10:26:58 -0400 From: "David R. Oran" To: Cullen Jennings , Medhavi Bhatia , sip@ietf.org Subject: RE: [Sip] B2B UA definition Message-ID: <1253514368.1028024818@OranLT.cisco.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit --On Monday, July 29, 2002 11:25 PM -0700 Cullen Jennings wrote: > > I think that a B2BUA should meet the requirements of a UAC on one side > and a UAS on the other. I am fine with it resetting max forwards and all > the other stuff you mention. If you consider a call from a UA to gateway > that go across the PSTN to another gateway to a UA, you realize the PSTN > is one large B2BUA. I don't think B2BUAs would benefit much from further > definition than it has today. > > However, you could get me going about what a "transparent" B2BUA is :-) > That's easy. A transparent B2BUA is one whose index of refraction is close to zero. :-) Transparent is one of the most misused terms in our entire industry, right up there with "compatible", and "seamless". Banning this terminology would do everyone a big service. Oops, then there's most misused term in the telecom industry..."service". Avoiding these terms would go a long way to keeping me from getting confused. :-) :-) Dave. > Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 04:21:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18024 for ; Wed, 31 Jul 2002 04:21:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA21885 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 04:22:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20208; Wed, 31 Jul 2002 03:45:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20163 for ; Wed, 31 Jul 2002 03:45:17 -0400 (EDT) Received: from marfik.upv.es (marfik.cc.upv.es [158.42.2.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17482 for ; Wed, 31 Jul 2002 03:44:08 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by marfik.upv.es (8.11.6/8.11.6) with ESMTP id g6V7nIR25983 for ; Wed, 31 Jul 2002 09:49:18 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g6V7jGN27381 for ; Wed, 31 Jul 2002 09:45:16 +0200 (METDST) Received: from merak.cc.upv.es (merak.cc.upv.es [158.42.4.9]) by smtp2.upv.es (8.11.4/8.11.4) with ESMTP id g6V7jFm29822 for ; Wed, 31 Jul 2002 09:45:15 +0200 Received: (from www@localhost) by merak.cc.upv.es (8.11.0/8.11.0) id g6V7jFh27194 for sip@ietf.org; Wed, 31 Jul 2002 09:45:15 +0200 X-Authentication-Warning: merak.cc.upv.es: www set sender to salreyca@teleco.upv.es using -f To: sip@ietf.org Message-ID: <1028101515.3d47958b83af8@webmail.upv.es> Date: Wed, 31 Jul 2002 09:45:15 +0200 (CEST) From: Salvador Rey Calatayud MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 192.35.17.27 Content-Transfer-Encoding: 8bit Subject: [Sip] offer/answer exchange Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi everyone, I resubmit this question since it has got no answer yet, as for the transaction state diagrams, and section 14.1 of RFC 3261, a UAS that had received an INVITE(not blank) cannot send another one, and thus start a new offer/answer cycle, until it sends a 200ok, or receives the ACK for a 300-699 response. why is the rule different for 200ok than for other responses? section 14.1 RFC 3261 "2. If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE." I think UPDATE and this are not alligned since the UPDATE specification says that another offer cannot be sent until a previous 1xxrel containing a descriptor is acknowledged with a PRACK (playing the role of ACK to 200ok in basic SIP). I include section 5.1 of UPDATE-02 "and for the callee: o If the UPDATE is being sent before the completion of the INVITE transaction, and the initial INVITE contained an offer, the UPDATE cannot be sent unless the callee has generated an answer in a reliable provisional response, !!has received a PRACK for that reliable provisional response!!, has not received any requests (PRACK or UPDATE) with offers that it has not answered, and has not sent any UPDATE requests containing offers that have not been answered." comments? regards, Salva _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 05:27:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18866 for ; Wed, 31 Jul 2002 05:27:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA24918 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 05:28:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24037; Wed, 31 Jul 2002 05:02:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24006 for ; Wed, 31 Jul 2002 05:02:05 -0400 (EDT) Received: from relay01.cablecom.net (relay01.cablecom.net [62.2.33.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18509 for ; Wed, 31 Jul 2002 05:00:55 -0400 (EDT) Received: from smtp.swissonline.ch (mail-4.swissonline.ch [62.2.32.85]) by relay01.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id g6V91UN35225; Wed, 31 Jul 2002 11:01:30 +0200 (CEST) Received: from ksmax (dclient217-162-98-179.hispeed.ch [217.162.98.179]) by smtp.swissonline.ch (8.11.6/8.11.6/SMTPSOL/AWF/2002040101) with SMTP id g6V91UH05093; Wed, 31 Jul 2002 11:01:30 +0200 (MEST) Message-ID: <000a01c23870$dc88a330$b362a2d9@ksmax> From: "Matthias Konrad" To: , "Salvador Rey Calatayud" References: <1028101515.3d47958b83af8@webmail.upv.es> Subject: Re: [Sip] offer/answer exchange Date: Wed, 31 Jul 2002 11:01:30 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi "Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction." This is only about new INVITE transactions within an "existing" dialog. If the UAS has sent a 200 ok, a new INVITE transaction within a dialog is just a (re) INVITE. So your other question was, why the rule for other responses than 200ok are different. Are they? It is just, that the TU is responsible for the ACK handling and not the transaction layer itself. And that is, because positive final response are end to end acknowleged an negative ones hop by hop. ----- Original Message ----- From: "Salvador Rey Calatayud" To: Sent: Wednesday, July 31, 2002 9:45 AM Subject: [Sip] offer/answer exchange > Hi everyone, > > I resubmit this question since it has got no answer yet, > > as for the transaction state diagrams, and section 14.1 of RFC 3261, a UAS > that had received an INVITE(not blank) cannot send another one, and thus start > a new offer/answer cycle, until it sends a 200ok, or receives the ACK for a > 300-699 response. why is the rule different for 200ok than for other responses? > > section 14.1 RFC 3261 > "2. If there is an ongoing INVITE server transaction, the TU MUST wait > until the transaction reaches the confirmed or terminated state before initiating > the new INVITE." > > I think UPDATE and this are not alligned since the UPDATE specification > says that another offer cannot be sent until a previous 1xxrel containing a > descriptor is acknowledged with a PRACK (playing the role of ACK to 200ok > in basic SIP). > > I include section 5.1 of UPDATE-02 > "and for the callee: > o If the UPDATE is being sent before the completion of the > INVITE transaction, and the initial INVITE contained an offer, > the UPDATE cannot be sent unless the callee has generated an > answer in a reliable provisional response, !!has received a > PRACK for that reliable provisional response!!, has not received > any requests (PRACK or UPDATE) with offers that it has not > answered, and has not sent any UPDATE requests containing > offers that have not been answered." > > comments? > > regards, > Salva > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 08:14:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22858 for ; Wed, 31 Jul 2002 08:14:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03988 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 08:15:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02694; Wed, 31 Jul 2002 07:47:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17045 for ; Wed, 31 Jul 2002 02:58:56 -0400 (EDT) Received: from esuims01.esamsungumit.com (mail.esamsungumit.com [203.122.29.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16224 for ; Wed, 31 Jul 2002 02:57:40 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 31 Jul 2002 12:29:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <89CFEE6120A0224EA07781892EC0B48B965658@esuims01.esamsungumit.com> Thread-Topic: draft-ietf-sip-privacy-general-04 Thread-Index: AcI4X37UsMlUXCg7QeuArWxcskpDgAAADnAQ From: "ShavinderPal Singh" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA17046 Subject: [Sip] draft-ietf-sip-privacy-general-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Hi, > I am not able to find draft-ietf-sip-privacy-general-04 on ietf.org > > Can anyone help me find it on the net somewhere. I searched on the site. I could find only draft-ietf-sip-privacy-general-01. > > Thanks & Rgds > s > > Samsung SDS Infotech. P Ltd. > Ph.: 091-124-6383474 (e 254) > _________________________________ > "I am not suffering from insanity, > I am enjoying every single minute of it!". > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 08:15:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22908 for ; Wed, 31 Jul 2002 08:15:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA04018 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 08:16:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02709; Wed, 31 Jul 2002 07:47:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29419 for ; Wed, 31 Jul 2002 06:48:52 -0400 (EDT) Received: from esuims01.esamsungumit.com (mail.esamsungumit.com [203.122.29.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20562 for ; Wed, 31 Jul 2002 06:47:42 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 31 Jul 2002 16:19:20 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <89CFEE6120A0224EA07781892EC0B48B9656E3@esuims01.esamsungumit.com> Thread-Topic: Method name in Request Line and CSeq. Thread-Index: AcI4f+vRcXv30VGBRf+FvVJil3tHKg== From: "ShavinderPal Singh" To: "Sip-Implementors" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA29420 Subject: [Sip] Method name in Request Line and CSeq. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, I have a very trivial query. Why do we need to keep the METHOD name both in the Request Line and the CSeq. Header, when always it will be same, in case of a REQUEST. In case of a response - there is nothing as called as a 'request line', so in any ways we have to look into the CSeq Header to find out the METHOD make out the fact that for which request was this response sent. Please clarify my doubts. Thanks Rgds s Samsung SDS Infotech. P Ltd. Ph.: 091-124-6383474 (e 254) _________________________________ "I am not suffering from insanity, I am enjoying every single minute of it!". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 08:19:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23030 for ; Wed, 31 Jul 2002 08:19:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA04200 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 08:20:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02621; Wed, 31 Jul 2002 07:46:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02590 for ; Wed, 31 Jul 2002 07:46:55 -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 HAA22016; Wed, 31 Jul 2002 07:45:45 -0400 (EDT) Message-Id: <200207311145.HAA22016@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 31 Jul 2002 07:45:45 -0400 Subject: [Sip] I-D ACTION:draft-khartabil-sip-congestionsafe-ci-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Congestion safety and Content Indirection Author(s) : H. Khartabil Filename : draft-khartabil-sip-congestionsafe-ci-00.txt Pages : 15 Date : 25-Jul-02 The Session Initiation Protocol allows the use of UDP for transport of SIP messages. Baseline SIP does not allow congestion control for messages larger than MTU of a certain link nor does it allow end points to specify their maximum acceptable message size, regardless of the underlying transport protocol. This document combines two, namely congestion safely and Content- Indirection Mechanism into the one document and presents scenarios where the 2 could be combined. It also introduces extensions to SIP that allows end points to specify their maximum acceptable message size. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-khartabil-sip-congestionsafe-ci-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-khartabil-sip-congestionsafe-ci-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: <20020731075628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-khartabil-sip-congestionsafe-ci-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-khartabil-sip-congestionsafe-ci-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020731075628.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 09:39:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26513 for ; Wed, 31 Jul 2002 09:39:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09624 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 09:40:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07282; Wed, 31 Jul 2002 09:12:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07249 for ; Wed, 31 Jul 2002 09:12:40 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24993 for ; Wed, 31 Jul 2002 09:11:30 -0400 (EDT) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g6VD6tm13947 for ; Wed, 31 Jul 2002 18:36:55 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C07.00487ED7 ; Wed, 31 Jul 2002 18:41:50 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256C07.00487E54.00@sampark.hss.hns.com> Date: Wed, 31 Jul 2002 18:41:48 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] privacy service :draft-ietf-sip-privacy-general-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a comment on the privacy services and their support on proxy or other servers. If privacy services defined in terms of different levels can be supported/not supported by different proxy servers, then one can also assume that probably these may be activated/deactivated on existing servers in the network. If we accept this scenario, then the draft needs to address situations like the following: 1.A proxy server which is performing levels A out of a total levels A,B requested by the UA, now is ready to activate level B. What should it do to the session for which it is only performing level A?(case addition of a privacy level) 2.A proxy server which is performing levels A out of a total levels A,B requested by the UA, now wants to deactive level B. What should it do to the session for which it is only performing level A?(case addition of a privacy level) Should it reroute future messages through another server which supports both A,B. Or should it only stop removing the prev-value so that subsequent servers start to perform the privacy service A. Or should deactivation of a level on a server be allowed only when the level in question is not in use. IMHO such scenarios may be valid ones, and some guidelines or explanations should be provided in the draft to cover them. Comments? regards Harsh Bhondwe Hughes Software Systems This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 09:58:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27470 for ; Wed, 31 Jul 2002 09:58:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10304 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 09:59:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07598; Wed, 31 Jul 2002 09:20:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07568 for ; Wed, 31 Jul 2002 09:20:40 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25235 for ; Wed, 31 Jul 2002 09:19:30 -0400 (EDT) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g6VDEwm13980 for ; Wed, 31 Jul 2002 18:44:58 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C07.00493952 ; Wed, 31 Jul 2002 18:49:47 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256C07.00493890.00@sampark.hss.hns.com> Date: Wed, 31 Jul 2002 18:44:56 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] privacy service :draft-ietf-sip-privacy-general-01(pls ignore previous) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a comment on the privacy services and their support on proxy or other servers. If privacy services defined in terms of different levels can be supported/not supported by different proxy servers, then one can also assume that probably these may be activated/deactivated on existing servers in the network. If we accept this scenario, then the draft needs to address situations like the following: 1.A proxy server which is performing levels A out of a total levels A,B requested by the UA, now is ready to activate level B. What should it do to the session for which it is only performing level A?(case activation of a privacy level) 2.A proxy server which is performing levels A out of a total levels A,B requested by the UA, now wants to deactive level A. What should it do to the session for which it is only performing level A?(case deactivation of a privacy level) Should it reroute future messages through another server which supports both A,B. Or should it only stop removing the prev-value so that subsequent servers start to perform the privacy service A. Or should deactivation of a level on a server be allowed only when the level in question is not in use. IMHO such scenarios may be valid ones, and some guidelines or explanations should be provided in the draft to cover them. Comments? regards Harsh Bhondwe Hughes Software Systems This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 12:18:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05007 for ; Wed, 31 Jul 2002 12:18:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19338 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 12:20:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16318; Wed, 31 Jul 2002 11:32:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16287 for ; Wed, 31 Jul 2002 11:32:20 -0400 (EDT) Received: from hagrid.orange.co.uk (smtpout10.orange.co.uk [193.35.135.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02229 for ; Wed, 31 Jul 2002 11:31:10 -0400 (EDT) From: amish.chana@orange.co.uk Received: from bit.orange.co.uk (bit.orange.co.uk) by hagrid.orange.co.uk (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 31 Jul 2002 16:35:25 +0100 Received: from ruddick (notes-gw.orange.co.uk [172.16.133.18]) by bit.orange.co.uk with SMTP id g6VFWBH12850 for ; Wed, 31 Jul 2002 16:32:11 +0100 (BST) X-Lotus-FromDomain: HTLUK To: sip@ietf.org Message-ID: <80256C07.00559583.00@ruddick> Date: Wed, 31 Jul 2002 16:34:51 +0100 Mime-Version: 1.0 Content-type: text/plain; charset="us-ascii" Content-Disposition: inline Subject: [Sip] SIP Congestion Control Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Does SIP support congestion/flow control methods during application level processing overload? (e.g. something equivalent to ISUP's ACC) This is typically for scenarios where there could be a burst of calls (possibly due to some media stimulated event) and hence a burst of SIP messages. The target of these messages could either be a proxy server, voicemail server or some other media server. I am assuming there are sufficient resources in the IP network and no packets will be dropped. From going through RFC3261 SIP seems to rely on the congestion controls of the transport protocols. draft-willis-sip-congestsafe-00.txt also seems to address the case where a transport network protocols like TCP and SCTP provide feedback control. Thanks, Amish ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ******************************************************************************* _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 13:06:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07739 for ; Wed, 31 Jul 2002 13:06:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22712 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 13:07:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20036; Wed, 31 Jul 2002 12:28:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20005 for ; Wed, 31 Jul 2002 12:28:21 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05476 for ; Wed, 31 Jul 2002 12:27:13 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03147; Wed, 31 Jul 2002 12:27:49 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28786; Wed, 31 Jul 2002 12:27:50 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W992H2Q>; Wed, 31 Jul 2002 12:27:49 -0400 Message-ID: <39469E08BD83D411A3D900204840EC557632A1@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'amish.chana@orange.co.uk'" , sip@ietf.org Subject: RE: [Sip] SIP Congestion Control Date: Wed, 31 Jul 2002 12:27:49 -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@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Amish, -> I am assuming there are sufficient resources in the IP -> network and no packets will be dropped. Then where is the congestion in the network? -> From going through RFC3261 SIP seems to rely on the -> congestion controls of the -> transport protocols. -> draft-willis-sip-congestsafe-00.txt also seems to address -> the case where a -> transport network protocols like TCP and SCTP provide -> feedback control. I don't think congestion control, flow control methods are required in session/application level protocols when they depend on well tested, extensively reserached transport protocols (like TCP and respective extensions). Looks like every higher layer protocols are trying to solve their own congetion/flow control. Yes! I agree that there must be some corner cases where you can optimize/improve protocols (like SIP, BGP etc) when there is much stress. But the problems you are trying to solve are very corner cases when you implement congestion/flow control in SIP, BGP etc I feel that this is duplicate work unless SIP is going achieve good preformance improvement with it's own congestion/flow control mechanisms when compared to best TCP extension(s). -- Venkata. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 13:59:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10487 for ; Wed, 31 Jul 2002 13:59:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26522 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 14:00:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22749; Wed, 31 Jul 2002 13:07:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22723 for ; Wed, 31 Jul 2002 13:07:46 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07752 for ; Wed, 31 Jul 2002 13:06:38 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id NAA00245; Wed, 31 Jul 2002 13:05:17 -0400 (EDT) Subject: Re: [Sip] SIP Congestion Control To: amish.chana@orange.co.uk Cc: sip@ietf.org Date: Wed, 31 Jul 2002 13:05:15 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 07/31/2002 01:05:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Wouldn't this sort of load shedding or load balancing issue be best dealt with at the application and not the protocol layer. amish.chana@orange.co.uk@ietf.org on 07/31/2002 11:34:51 AM Sent by: sip-admin@ietf.org To: sip@ietf.org cc: Subject: [Sip] SIP Congestion Control Hi, Does SIP support congestion/flow control methods during application level processing overload? (e.g. something equivalent to ISUP's ACC) This is typically for scenarios where there could be a burst of calls (possibly due to some media stimulated event) and hence a burst of SIP messages. The target of these messages could either be a proxy server, voicemail server or some other media server. I am assuming there are sufficient resources in the IP network and no packets will be dropped. From going through RFC3261 SIP seems to rely on the congestion controls of the transport protocols. draft-willis-sip-congestsafe-00.txt also seems to address the case where a transport network protocols like TCP and SCTP provide feedback control. Thanks, Amish ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ******************************************************************************* _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jul 31 20:35:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22596 for ; Wed, 31 Jul 2002 20:35:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA20121 for sip-archive@odin.ietf.org; Wed, 31 Jul 2002 20:36:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19038; Wed, 31 Jul 2002 20:05:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19007 for ; Wed, 31 Jul 2002 20:05:22 -0400 (EDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22150 for ; Wed, 31 Jul 2002 20:04:14 -0400 (EDT) Received: from aslan ([12.224.107.17]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020801000452.JPOM24567.rwcrmhc51.attbi.com@aslan> for ; Thu, 1 Aug 2002 00:04:52 +0000 Reply-To: From: "Jack W. Lix" To: Date: Wed, 31 Jul 2002 17:27:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3D1BF373.3030806@dynamicsoft.com> Content-Transfer-Encoding: 7bit Subject: [Sip] caller preferences and RFC 2533 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I've been reviewing http://search.ietf.org/internet-drafts/draft-ietf-sip-message-06.txt and have a couple questions. First, in section 5.2 the following paragraph is found: > The proxy then takes each URI in the target set (the set of URI it is > going to proxy to), and obtains there capabilities as an RFC 2533 > formatted feature set. If target URI was obtained through a > registration, the proxy computes the feature set by taking all > Contact URI parameters except for the q and expires parameters, and > converting them to RFC 2533 syntax using the rules of Section 6.1. Should the word "there" in the 1st sentence be their or it's? Or, should the sentence read "and there obtains capabilities"? Second, the text makes many references to RFC 2533 and that is fine for describing the intended behaviour. However, it implies that you MUST translate the headers into RFC 2533 format. Doesn't that impose an implementation rather than define the protocol? Is there any reason that I really have to use RFC 2533? Thanks, Jack W. Lix Wind River Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip