From exim@www1.ietf.org Mon Feb 2 09:43:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15359 for ; Mon, 2 Feb 2004 09:43:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnfIA-0006zJ-FI for sip-archive@odin.ietf.org; Mon, 02 Feb 2004 09:43:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12EhEUT026800 for sip-archive@odin.ietf.org; Mon, 2 Feb 2004 09:43:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnfHx-0006xI-AF; Mon, 02 Feb 2004 09:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnfHW-0006wX-CS for sip@optimus.ietf.org; Mon, 02 Feb 2004 09:42:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15320 for ; Mon, 2 Feb 2004 09:42:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnfHU-0007iz-00 for sip@ietf.org; Mon, 02 Feb 2004 09:42:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnfGW-0007eV-00 for sip@ietf.org; Mon, 02 Feb 2004 09:41:32 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AnfFa-0007ZI-00 for sip@ietf.org; Mon, 02 Feb 2004 09:40:34 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i12Eawfi029774 for ; Mon, 2 Feb 2004 09:36:58 -0500 (EST) Received: from cof110avexu2.global.avaya.com (h135-9-6-17.avaya.com [135.9.6.17]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i12Eavfi029738 for ; Mon, 2 Feb 2004 09:36:57 -0500 (EST) Received: from nematode ([135.123.224.6]) by cof110avexu2.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 07:40:31 -0700 Message-ID: <003501c3e999$eb275f40$06e07b87@dr.avaya.com> From: "Joanne McMillen" To: Date: Mon, 2 Feb 2004 07:36:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C3E95F.3DAB3060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 02 Feb 2004 14:40:32.0218 (UTC) FILETIME=[829EB3A0:01C3E99A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] RFC 3261 and media Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C3E95F.3DAB3060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I seem to recall discussions a long time ago regarding SIP sessions without media. Currently, RFC 3261 is very vague on what these procedures would be. Given the offer/answer model, how would a UA receiving an INVITE without an offer know how to distinguish between a "delayed-media" case and a "no-media" case? Is there a specific session content type that should be used for this? I cannot find it documented anywhere. Please help. Regards, Joanne ------=_NextPart_000_0031_01C3E95F.3DAB3060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I seem to recall discussions a long time ago = regarding=20 SIP sessions without media.
Currently, RFC 3261 is very vague on what these = procedures=20 would be. Given the
offer/answer model, how would a UA receiving an = INVITE without=20 an offer know how to
distinguish between a "delayed-media" case and a = "no-media"=20 case? Is there a specific
session content type  that should be used = for this? I cannot find it documented
anywhere.
 
Please help.
 
Regards,
Joanne
 
------=_NextPart_000_0031_01C3E95F.3DAB3060-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 2 12:08:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22918 for ; Mon, 2 Feb 2004 12:08:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhYV-0000eK-Bn for sip-archive@odin.ietf.org; Mon, 02 Feb 2004 12:08:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12H8FAx002433 for sip-archive@odin.ietf.org; Mon, 2 Feb 2004 12:08:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhYK-0000Zc-0N; Mon, 02 Feb 2004 12:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhXz-0000Sl-HX for sip@optimus.ietf.org; Mon, 02 Feb 2004 12:07:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22868 for ; Mon, 2 Feb 2004 12:07:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnhXy-0000Om-00 for sip@ietf.org; Mon, 02 Feb 2004 12:07:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnhX2-0000Jh-00 for sip@ietf.org; Mon, 02 Feb 2004 12:06:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AnhWJ-00009d-00 for sip@ietf.org; Mon, 02 Feb 2004 12:05:59 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2004 09:06:09 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i12H5Msx015050; Mon, 2 Feb 2004 12:05:24 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFS94107; Mon, 2 Feb 2004 12:05:22 -0500 (EST) Message-ID: <401E8351.5040204@cisco.com> Date: Mon, 02 Feb 2004 12:05:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joanne McMillen CC: sip@ietf.org Subject: Re: [Sip] RFC 3261 and media References: <003501c3e999$eb275f40$06e07b87@dr.avaya.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joanne McMillen wrote: > I seem to recall discussions a long time ago regarding SIP sessions > without media. > Currently, RFC 3261 is very vague on what these procedures would be. > Given the > offer/answer model, how would a UA receiving an INVITE without an offer > know how to > distinguish between a "delayed-media" case and a "no-media" case? Is > there a specific > session content type that should be used for this? I cannot find it > documented > anywhere. If one of the messages that is permitted to carry an offer or answer contains a body of Content-Type application/sdp, and content-disposition of "session", then it is an offer or answer. To conform, the body then must actually contain content conforming to the syntax of sdp. If that sdp has no m-lines, (or only m-lines with a port of zero) then it is a media-less offer or answer. OTOH, a delayed-media invite contains no sdp at all. Individual endpoints have to make their own decisions about whether to accept no-media invites, and if so how long to keep them around. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 3 01:49:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11333 for ; Tue, 3 Feb 2004 01:49:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnuN1-0005Pp-GW for sip-archive@odin.ietf.org; Tue, 03 Feb 2004 01:49:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i136nFrx020811 for sip-archive@odin.ietf.org; Tue, 3 Feb 2004 01:49:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnuMn-0005OZ-LJ; Tue, 03 Feb 2004 01:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnuM0-0005LO-KT for sip@optimus.ietf.org; Tue, 03 Feb 2004 01:48:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11293 for ; Tue, 3 Feb 2004 01:48:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnuLx-0006Xt-00 for sip@ietf.org; Tue, 03 Feb 2004 01:48:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnuKy-0006SW-00 for sip@ietf.org; Tue, 03 Feb 2004 01:47:09 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AnuKI-0006Iv-00 for sip@ietf.org; Tue, 03 Feb 2004 01:46:26 -0500 Received: from dynamicsoft.com ([63.113.46.124]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i136k49W014324; Tue, 3 Feb 2004 01:46:05 -0500 (EST) Message-ID: <401F43A0.2040305@dynamicsoft.com> Date: Tue, 03 Feb 2004 01:45:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Helsinki)" CC: sip@ietf.org Subject: Re: [Sip] querying the current event state of a publication References: <4012E741.5000809@dynamicsoft.com> <4017C622.2050507@nokia.com> In-Reply-To: <4017C622.2050507@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Firstly, I'm inclined to back away from my prior suggesting of using URIs instead of etags, primarily because I think we are just too far along here and "if it aint broke, don't fix it". We can probably get the missing piece of functionality - finding out who else is publishing - in ways that dont change what we have documented. Your suggestion below is reasonable towards that end, but makes me nervous that it introduces a behavior that is *like* registration, but isnt the same (no contacts in the publish request, for example). Another possible idea is to create a new event package which is the "esc" event package. When you subscribe to a URI for that package, you get notified of all published documents made against that URI. The current state of the resource for that package is a list of the currently active documents for that URI. By doing this as an event package, we can leave PUBLISH alone, and add this functionality in the future, as a separate item. -Jonathan R. Niemi Aki (Nokia-M/Helsinki) wrote: > Hi, > > Inline. > > ext Jonathan Rosenberg wrote: > >> In draft-ietf-sip-publish-02, section 5.7 proposes a way to query a >> specific published event state. It recommends subscribing to the AOR >> to learn it. However, it gives this caveat: >> >> Note that a subscription to the event package will likely deliver >> results of the event composition process of the state agent, which >> may be a subset or a superset of the current published event >> state. >> >> which is another way of saying, that subscribing to the aor doesnt >> really allow you to query for a specific published event state. >> >> If we want this functionality, I have an idea for an alternative >> approach that works much better, triggered by some conversations I had >> with Ben C. recently. >> >> In the response to a PUBLISH request, the ESC returns a URI that >> identifies that particular event state publication (effectively, a URI >> that is bound to the AOR+event+etag of a publication). This URI is >> basically a GRUU. If a user wishes to learn the state of this >> particular event state, they merely subscribe to that URI. Indeed, a >> particularly interestinig way to do this is to define sIP etags as >> URIs, rather than reusing the definition from http. I think that >> having an etag as a URI is far more elegant, as it would allow for >> things like this function in a natural way. The alternative would be >> to possibly use the Contact header field, as the meaning is the same >> as in a 2xx to INVITE - identifying the specific *instance* to which >> you were connected when you contacted the AOR. This makes sense if you >> think of the event state publication URI as a GRUU. > > > But a PUA has to know the state it just published, simply because it was > the source of that state in the first place. What it can't learn is the > state of the other active PUAs. > > And this is actually something currently missing from PUBLISH. A given > PUA can't find out about publications other than thiose it itself has > made. As a consequence, it can't for example, override the publications > of a zombie PUA (a use case we have discussed in the past at length). > > In order to enable a PUA to find out about the *other* publications to a > given resource, the ESC would have to return not only a pointer to this > PUAs publication, but to all active publications for that AoR. This is > very similar to a registrar returning all active address bindings of an > AoR. > >> Indeed, one might even then PUBLISH to that URI, and it would have the >> exact result you would expect - that particular event state is >> updated. In such a case the server woould NOT return an etag or >> another URI in the response. > > > When you add the feature I describe above, etags would still be needed > since it would allow two PUAs to publish to the same instance of state. > Etags would be needed for versioning in that case. > > > >> This would mean we wouldnt need the SIP-If-match. >> >> Another alternative is to say that we are simply too far along in >> PUBLISH, and the time has passed for major changes as this would be. > > > I do think we are quite far along in PUBLISH for adding this sort of > functionality. However, I see some low-hanging fruit here, and to be > honest, it has always bothered me a bit that there is no way for a PUA > to know about the state other PUAs are publishing. > > There is a requirement that calls for basically exactly this in > draft-ietf-simple-publish-reqs-00 and it states: > > 14. PUAs must have a capability that allows them to query for the > identifiers of all of the segments of presence information that > have currently been published for a presentity (provided that > the PUA is authorized to receive this information). > > Using the register-like behavior for returning the set of active state > in the 2xx response to PUBLISH + having this set be a set of GRUUs would > fulfill the above. The PUA would be able to query the state (using > SUBSCRIBE), but also override it (using PUBLISH). This is also a > requireemnt in the reqs draft: > > 15. It must be possible for the publication of presence information > for a particular segment to overwrite existing information for > that segment, even if the existing information had been > published by a different PUA. ... > > So I would be willing to add this functionality simply because it would > make the solution more complete. As far as adding complexity, sure, but > an ESC whose policy doesn't allow cross PUA state could always just > refuse to send the publication contacts in the PUBLISH response. > > Does this sound reasonable? > > Cheers, > Aki > > P.S. I added an example message flow to illustrate the above ramblings... > > --- > > PUA publishes its (initial) state: > > PUBLISH sip:presentity@example.com SIP/2.0 > To: > From: ;tag=54321mm > Expires: 3600 > Event: presence > ... > > ESC returns with an etag for that state, plus all active publications in > the form of URIs: > > SIP/2.0 200 OK > To: ;tag=effe22aa > From: ;tag=54321mm > SIP-ETag: qwi982ks > Expires: 3600 > Contact: sip:kaskjsdh@pa.example.com;etag=qwi982ks;expires=3600 > Contact: sip:jhsk23jj@pa.example.com;etag=hh3j4kll;expires=3229 > Contact: sip:hhfkjhjk@pa.example.com;etag=3ihy4hhk;expires=1200 > > >> Thoughts? >> >> -Jonathan R. >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 3 01:58:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11735 for ; Tue, 3 Feb 2004 01:58:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnuVb-0006U6-5D for sip-archive@odin.ietf.org; Tue, 03 Feb 2004 01:58:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i136w7BO024927 for sip-archive@odin.ietf.org; Tue, 3 Feb 2004 01:58:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnuVV-0006T1-TT; Tue, 03 Feb 2004 01:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnuUp-0006Hn-CD for sip@optimus.ietf.org; Tue, 03 Feb 2004 01:57:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11662 for ; Tue, 3 Feb 2004 01:57:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnuUm-0007Rw-00 for sip@ietf.org; Tue, 03 Feb 2004 01:57:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnuTv-0007LS-00 for sip@ietf.org; Tue, 03 Feb 2004 01:56:23 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AnuTK-0007Cv-00 for sip@ietf.org; Tue, 03 Feb 2004 01:55:46 -0500 Received: from dynamicsoft.com ([63.113.46.124]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i136sN9W014331; Tue, 3 Feb 2004 01:54:24 -0500 (EST) Message-ID: <401F4591.2040500@dynamicsoft.com> Date: Tue, 03 Feb 2004 01:54:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Jansson CC: Paul Kyzivat , Jussi.Turunen@nokia.com, nataraju.alilaghatta@wipro.com, sanjsinh@cisco.com, sip@ietf.org Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christian Jansson wrote: > Perhaps a little late, and hopefully not off topic. Comments inline. Not too late, not off topic. > > >>Jonathan R. wrote >>This, however, leads me into thinking a bit on the lifecycle >>management for GRUUs. Currently, GRUU is bound to a single >>registration, where the registration is defined by the Contact URI. If > > >>the UA should "move", in the sense that it acquires a new IP address, >>this will be a new Contact URI, and therefore, a new GRUU. It would be >>nice if, instead, the GRUU were truly bound to the UA instance, and >>that even if the UA instance changed IP addresses, the GRUU could >>remain unchanged. In such a case, if the UA moves, there is actually >>no need to issue any target refresh requests. The UA would simply >>re-register, update the binding of its GRUU to its new IP >>address, and >>existing calls would be correctly routed. > > > But if the ip actually changes, it would be necessary to send an updated > SDP with the new ip in the c= line. Yes, that is true. If media relays are used (i.e., TURN), it might be possible to avoid even this, but lets leave that aside for now. > So your idea won't save you from > having to send a SIP request to the other end every time the ip changes > in an INVITE session. Right. However, it does solve the problem that, previously, if both endpoints moved at the same time, the call would fail - neither side could signal the other. > For a non-INVITE session though the idea would > save a lot of request from being sent if the session only contains > signaling. Right, in particular, a long lived presence subscription, for example. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 3 02:13:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24321 for ; Tue, 3 Feb 2004 02:13:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anuk8-0003jI-KO for sip-archive@odin.ietf.org; Tue, 03 Feb 2004 02:13:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i137D8B4014326 for sip-archive@odin.ietf.org; Tue, 3 Feb 2004 02:13:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anuk2-0003gj-GL; Tue, 03 Feb 2004 02:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnujH-0003QN-8d for sip@optimus.ietf.org; Tue, 03 Feb 2004 02:12:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24179 for ; Tue, 3 Feb 2004 02:12:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnujD-00017b-00 for sip@ietf.org; Tue, 03 Feb 2004 02:12:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnuiO-00012O-00 for sip@ietf.org; Tue, 03 Feb 2004 02:11:21 -0500 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1AnuhQ-0000qo-00 for sip@ietf.org; Tue, 03 Feb 2004 02:10:20 -0500 Received: from huawei.com (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HSH002Y0YG32E@mta2.huawei.com> for sip@ietf.org; Tue, 03 Feb 2004 15:07:16 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HSH008THYG243@mta2.huawei.com> for sip@ietf.org; Tue, 03 Feb 2004 15:07:15 +0800 (CST) Received: from nkannanCL1068 ([10.18.4.245]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HSHYL600.Q0L; Tue, 03 Feb 2004 15:10:18 +0800 Date: Tue, 03 Feb 2004 12:37:10 +0530 From: Natesan Kannan Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request To: Jonathan Rosenberg , Christian Jansson Cc: Paul Kyzivat , Jussi.Turunen@nokia.com, nataraju.alilaghatta@wipro.com, sanjsinh@cisco.com, sip@ietf.org Reply-to: Natesan Kannan Message-id: <004901c3ea24$576c1850$f504120a@in.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <401F4591.2040500@dynamicsoft.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I will attempt a wild swing too... Though we are talking of terminal mobility, it seems to me that this mobility is restricted because of the fixed routeset in the dialog. I can see that GRUU mapping to instance id, and the fact that GRUU can be globally routed, paves a way for an un-restricted terminal mobility, just in case nobody record-routed. Was wondering if this could be of any use... -Kannan ----- Original Message ----- From: "Jonathan Rosenberg" To: "Christian Jansson" Cc: "Paul Kyzivat" ; ; ; ; Sent: Tuesday, February 03, 2004 12:24 PM Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request > > > Christian Jansson wrote: > > > Perhaps a little late, and hopefully not off topic. Comments inline. > > Not too late, not off topic. > > > > > > >>Jonathan R. wrote > >>This, however, leads me into thinking a bit on the lifecycle > >>management for GRUUs. Currently, GRUU is bound to a single > >>registration, where the registration is defined by the Contact URI. If > > > > > >>the UA should "move", in the sense that it acquires a new IP address, > >>this will be a new Contact URI, and therefore, a new GRUU. It would be > >>nice if, instead, the GRUU were truly bound to the UA instance, and > >>that even if the UA instance changed IP addresses, the GRUU could > >>remain unchanged. In such a case, if the UA moves, there is actually > >>no need to issue any target refresh requests. The UA would simply > >>re-register, update the binding of its GRUU to its new IP > >>address, and > >>existing calls would be correctly routed. > > > > > > But if the ip actually changes, it would be necessary to send an updated > > SDP with the new ip in the c= line. > > Yes, that is true. If media relays are used (i.e., TURN), it might be > possible to avoid even this, but lets leave that aside for now. > > > So your idea won't save you from > > having to send a SIP request to the other end every time the ip changes > > in an INVITE session. > > Right. However, it does solve the problem that, previously, if both > endpoints moved at the same time, the call would fail - neither side > could signal the other. > > > > For a non-INVITE session though the idea would > > save a lot of request from being sent if the session only contains > > signaling. > > Right, in particular, a long lived presence subscription, for example. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 3 03:56:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28649 for ; Tue, 3 Feb 2004 03:56:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnwLt-0000oX-89 for sip-archive@odin.ietf.org; Tue, 03 Feb 2004 03:56:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i138uDhI003127 for sip-archive@odin.ietf.org; Tue, 3 Feb 2004 03:56:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnwLk-0000j6-Ev; Tue, 03 Feb 2004 03:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnwL3-0000eG-3e for sip@optimus.ietf.org; Tue, 03 Feb 2004 03:55:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28537 for ; Tue, 3 Feb 2004 03:55:19 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnwL0-0003VY-00 for sip@ietf.org; Tue, 03 Feb 2004 03:55:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnwK3-0003OB-00 for sip@ietf.org; Tue, 03 Feb 2004 03:54:20 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AnwJ4-0003I4-00 for sip@ietf.org; Tue, 03 Feb 2004 03:53:18 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i138rI200649 for ; Tue, 3 Feb 2004 10:53:18 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 10:51:49 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 10:51:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt Date: Tue, 3 Feb 2004 10:51:47 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9359@esebe013.ntc.nokia.com> Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt Thread-Index: AcPizoKTqL7+575US4eTc5jjEZYm3gEVsgPw To: Cc: X-OriginalArrivalTime: 03 Feb 2004 08:51:48.0928 (UTC) FILETIME=[F5C7C400:01C3EA32] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jonathan, Thanks a lot for the excellent comments. Most of them I will directly = fold into -03. Few clarifications below. Cheers, Aki Jonathan Rosenberg wrote: > * section 3, paragraph 3: >=20 > > That is, the steady-state of > > this event package in the absence of, or in addition=20 > to, soft state > > provided through the PUBLISH mechanism >=20 > this makes it sound like steady state is a function of the event=20 > packae only. the hard state is a function of the resource uRI and=20 > event package. Indeed, one may think of an event package as merely=20 > sub-resource within the full resource. I wonder if it wouldn't be=20 > useful to come up with a term for this - for example, "scoped=20 > resource" is a combination of a URI and event package, and=20 > identifies=20 > a particular piece of event state. I don't quite follow, but I agree the quoted text is rather vague. To = me the hard state, or "preconfigured" state is just another source of = event state to the composer. The mechanism to set that state might be = other than PUBLISH.=20 > * section 5.1: >=20 > > As with any other SIP message, the PUBLISH mechanism MAY use the > > content indirection mechanism defined in [10]. >=20 > this statement makes [10] a normative reference, I believe. It is=20 > listed as informative in the references section. I'm not sure I agree. I've understood the RFC editor's policy so that an = informative reference is not required for implementing the RFC. It's an = interesting question as to how this relates to RFC 2119 terminology. But = I think a MAY makes the feature optional so that it fits the informative = reference definition. > * section 5.3 is out of place. Section 5 is about generating=20 > requests.=20 > the subsections for the most part deal with the specific 4 sub-cases=20 > you identified in 5.1. However, 5.3 talks about setting expirations,=20 > which is something that is actually done for the cases in 5.2, 5.4,=20 > 5.5 and 5.6. I would suggest that eaech of those four=20 > sections rather=20 > describe how the Expires header field is constructed for each case.=20 > That is consistent with having a column in table 1 on=20 > expires. Indeed,=20 > each section should also talk about bodies and etag. Along those=20 > lines, section 5.2 does not actually say that a body has to be=20 > present; it shouold be stated given the importance of this fact from=20 > table 1. I think the reason for this is that I envisioned a PUBLISH carrying = state in some other place than the body. However, I don't know if such a = case would ever exist, and other people have also commented on this. I = think it is safe to assume that the state is always carried in the body, = as opposed to "typically". I'll change the text in 5.2 accordingly. =20 > * section 5.7 is out of place, since it has nothing to do with=20 > constructing publish at all. indeed, since the note basically says=20 > that this doesnt work, i would suggest removing the section entirely. I think I agree with you. The separate email thread about querying the = state of a particular publication ought to resolve this issue.=20 > It occurs to me that its a huge shame that etags are not=20 > URIs. If they=20 > weree, we would have a rerally neat way to find out the=20 > specific state=20 > of a particular publication - you woould subscribe to that etag. The=20 > next best thing might be to define a header field in the PUBLISH=20 > response that identifies this particular published instance. Hmm,=20 > Contact might even be a sensible choice there... worth discussing.=20 > I'll send a separate email on the topic. I responded to this separately.=20 =20 =20 > * section 6: >=20 > > PUBLISH requests MUST be processed in the order that they are > > received.=20 >=20 > isnt this only true for requuests with the same r-uri? Correct. I will add some text to this effect. =20 > * the steps in section 6 omit handling for the case where=20 > there was no=20 > SIP-If-Match header field. step 6 says to check for it, and all the=20 > following steps assume it was there. I would suggest adding a bullet=20 > to step 6 which says, if there was no SIP-If-Match header field, the=20 > ESC creates a new etag, and associates it with as-yet empty event=20 > state. Processing continues in the steps below. This way, you always=20 > exit step 6 with an etag. The attempt was to make etag generation part of step 9. This way, an = entity-tag is generated for each successful publication and returned in = 2xx, irrespective of whether the publication was an initial publication, = a refresh, or a modification. Indeed, a 2xx to a removal could be = treated the same, although such an entity-tag is useless at that point. So I think it is ok to exit step 6 without an entity tag, as long as = step 9 is clear that entity-tags are generated for all successful = publications. >=20 > * step 8 of section 6: >=20 > > The ESC processes the published event state, typically contained > > in the body of the PUBLISH request. If the request=20 > contains no > > body (when it should contain one),=20 >=20 > i think we need to list the conditions for when it should=20 > contain one.=20 > Indeed, since you are always allowed to publish without a body in=20 > order to refresh or delete, under what conditions is it illegal for=20 > the body to not be there? I don't think there are any. I will reword and remove that part. > * step 9: >=20 > > The response MUST also contain a SIP-ETag header field for > > which the ESC MUST generate and store a locally=20 > unique entity-tag > > for identifying the publication. >=20 > You should clarify that it generates a new one in each response, and=20 > does so for both initial and refreshes. Also, clarify that this etag=20 > replaces the previous, such that the previous etag is no=20 > longer valid=20 > for identifying the publication. Good point. =20 > * sectiton 11.1: >=20 > > Authentication issues are discussed in SIP [2]. The exact=20 > methods for > > creation and manipulation of the ESC authorization policies are > > outside the scope of this document. >=20 > you will get dinged on this by Bellovin, guaranteed. He wants to see=20 > statements about baseline mandtory to implement mechahnisms.=20 > Its fine=20 > to say that this mechanism is digest, as mandated by rfc3261. >=20 > > To prevent replay attacks, implementations SHOULD require > > authentication with anti-replay protection.=20 > Authentication issues are > > discussed in SIP [2]. >=20 > as above.... does this mean digest with next-nonce or are=20 > you talking=20 > sips? >=20 > and section 11.4: >=20 > > To prevent such attacks, implementations SHOULD, at a minimum, > > provide integrity protection across the To, From, Event, > > SIP-If-Match, Route, and Expires headers and the bodies=20 > of PUBLISH > > requests. >=20 > as above, he will ask for a mechanism. This requiurement makes the=20 > choice sips. >=20 > Same in 11.5. =20 I see what you are saying. But is it really so that each new method that = gets added to SIP needs to explicitly mandate certain security = mechanisms? At least going beyond the security considerations in RFC = 3261 seems unnecessary, since the properties of PUBLISH are very similar = to, say, REGISTER.=20 I was hoping we could get by with discussing PUBLISH specific threats, = and merely referencing relevant parts of RFC3261 when it comes to = mitigating those threats. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 3 06:26:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03526 for ; Tue, 3 Feb 2004 06:26:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anyh2-0001eA-8e for sip-archive@odin.ietf.org; Tue, 03 Feb 2004 06:26:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13BQCbK006269 for sip-archive@odin.ietf.org; Tue, 3 Feb 2004 06:26:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anygs-0001aw-Pr; Tue, 03 Feb 2004 06:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnygG-0001Vy-78 for sip@optimus.ietf.org; Tue, 03 Feb 2004 06:25:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03487 for ; Tue, 3 Feb 2004 06:25:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnygC-0002hR-00 for sip@ietf.org; Tue, 03 Feb 2004 06:25:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnyfH-0002cA-00 for sip@ietf.org; Tue, 03 Feb 2004 06:24:23 -0500 Received: from liszt-11.ednet.co.uk ([212.20.226.53] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AnyeZ-0002WY-00 for sip@ietf.org; Tue, 03 Feb 2004 06:23:39 -0500 Received: from liszt-11.ednet.co.uk (mail.ednet.co.uk [212.20.226.52]) by liszt-11.ednet.co.uk (Postfix) with ESMTP id 40621255BA6; Tue, 3 Feb 2004 11:23:35 +0000 (GMT) Received: from gilbert.ednet.co.uk (gilbert.ednet.co.uk [212.20.231.234]) by liszt-11.ednet.co.uk (postfixfilterd/14247) id YAGRPUJOMP; Tue, 03 Feb 2004 11:23:35 +0000 (GMT) Received: from Azopardi (azopardi.ednet.co.uk [212.20.231.227]) by gilbert.ednet.co.uk (Postfix) with ESMTP id C72E216400B; Tue, 3 Feb 2004 11:23:34 +0000 (GMT) Reply-To: From: "Suha Cubukcuoglu" To: Date: Tue, 3 Feb 2004 11:20:19 -0000 Organization: edNET Message-ID: <001f01c3ea47$b5317200$e3e714d4@Azopardi> 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.2800.1106 X-Comment: Virus scanned by edNET X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=EXCUSE_16,OFFERS_ETC autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Music On Hold Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, During an attended call transfer attempt, the transferred party (A-Party) is put on 'hold' by the transferor (B-Party) - i.e. no media stream flows from B to A and vice versa. While the A-Party is on hold, the B-Party can INVITE a third party to play 'Music on Hold' tune to the A-Party until the transfer attempt succeeds. We think that there are complications in this approach. Firstly, the SIP Proxy must now where to route the new INVITE generated by the B-Party. If the destination URI is 'moh@someserver.com', the SIP Proxy must either do a DNS query or use its IP dial-plans to know where to route the call. Secondly, the B-Party might eventually end-up receiving the music tune whereas it was initially intended for the A-Party - we've had problems in the past because of this. This is all dependent on how the third party MOH server handles/established/terminates requests. We think that third party invitation is a bad idea, and it would rather be more suitable to have a dedicated server (IVR unit perhaps) which the SIP Proxy Server can transfer calls to/from upon request for a MOH service. Could you tell us your opinions about this please? Thanks. Regards, Suha Cubukcuoglu nplusone t: +44 131 514 2000 d: +44 131 514 4037 -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of edNET or lightershade ltd. Finally, the recipient should check this email and any attachments for the presence of viruses. edNET and lightershade ltd accepts no liability for any damage caused by any virus transmitted by this email. -- -- Virus scanned by edNET. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 3 08:47:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08527 for ; Tue, 3 Feb 2004 08:47:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0ss-0005Yg-3B for sip-archive@odin.ietf.org; Tue, 03 Feb 2004 08:46:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13DkYqF021360 for sip-archive@odin.ietf.org; Tue, 3 Feb 2004 08:46:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0sM-0005X0-W8; Tue, 03 Feb 2004 08:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0ri-0005Qb-17 for sip@optimus.ietf.org; Tue, 03 Feb 2004 08:45:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08450 for ; Tue, 3 Feb 2004 08:45:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0rg-0002Eh-00 for sip@ietf.org; Tue, 03 Feb 2004 08:45:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao0qi-00028o-00 for sip@ietf.org; Tue, 03 Feb 2004 08:44:20 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao0pi-0001z0-00 for sip@ietf.org; Tue, 03 Feb 2004 08:43:18 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i13DghJ18688 for ; Tue, 3 Feb 2004 07:42:43 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 13:27:29 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EFC3@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Cc: "'aki.niemi@nokia.com'" , "'jdrosen@dynamicsoft.com'" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt Date: Tue, 3 Feb 2004 13:27:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think you are confusing two different concepts. If it is not normative it is informative. If it is optional it is not mandatory. The two concepts are orthogonal. By capitalizing the "MAY" you are emphasizing that this is a requirement, and therefore normative, even though it is an optional requirement. Keith > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: 03 February 2004 08:52 > To: jdrosen@dynamicsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt > > > Hi Jonathan, > > Thanks a lot for the excellent comments. Most of them I will > directly fold into -03. Few clarifications below. > > Cheers, > Aki > > Jonathan Rosenberg wrote: > > > > > * section 5.1: > > > > > As with any other SIP message, the PUBLISH mechanism MAY use the > > > content indirection mechanism defined in [10]. > > > > this statement makes [10] a normative reference, I believe. It is > > listed as informative in the references section. > > I'm not sure I agree. I've understood the RFC editor's policy > so that an informative reference is not required for > implementing the RFC. It's an interesting question as to how > this relates to RFC 2119 terminology. But I think a MAY makes > the feature optional so that it fits the informative > reference definition. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 3 10:09:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12051 for ; Tue, 3 Feb 2004 10:09:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2As-0004pU-RR for sip-archive@odin.ietf.org; Tue, 03 Feb 2004 10:09:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13F9EQU018498 for sip-archive@odin.ietf.org; Tue, 3 Feb 2004 10:09:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2Ae-0004k2-R1; Tue, 03 Feb 2004 10:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ane8W-0007cg-3l for sip@optimus.ietf.org; Mon, 02 Feb 2004 08:29:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10967 for ; Mon, 2 Feb 2004 08:29:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ane8U-0007TA-00 for sip@ietf.org; Mon, 02 Feb 2004 08:29:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ane6Y-0006zM-00 for sip@ietf.org; Mon, 02 Feb 2004 08:27:11 -0500 Received: from zdemail03.zdem.compaq.com ([161.114.112.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ane4c-0006Rr-00 for sip@ietf.org; Mon, 02 Feb 2004 08:25:10 -0500 Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.86.63]) by zdemail03.zdem.compaq.com (Postfix) with ESMTP id BC5121390 for ; Mon, 2 Feb 2004 14:24:33 +0100 (CET) Received: from rtoexc02.emea.cpqcorp.net ([16.41.86.56]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 2 Feb 2004 14:24:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Feb 2004 14:24:33 +0100 Message-ID: <67EBB9787FE159418BA12D0D8D44511141EE42@rtoexc02.emea.cpqcorp.net> Thread-Topic: REL cause code after interwork timer in RFC3398 Thread-Index: AcORlns2GQmpTogXTe6HoLMdHL8bYRX+Qphw From: "El Moussawi, Ali" To: X-OriginalArrivalTime: 02 Feb 2004 13:24:33.0597 (UTC) FILETIME=[E57856D0:01C3E98F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] REL cause code after interwork timer in RFC3398 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello all, In RFC 3398, page 16, what do you think the cause code should be in the REL sent to the PSTN network after interwork tinmer expires ? Thanks a lot for your help Ali _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 3 18:01:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11063 for ; Tue, 3 Feb 2004 18:01:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9Xr-0002OT-Nc for sip-archive@odin.ietf.org; Tue, 03 Feb 2004 18:01:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13N1R5p009195 for sip-archive@odin.ietf.org; Tue, 3 Feb 2004 18:01:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9XS-00027o-FX; Tue, 03 Feb 2004 18:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9XD-0001yH-T1 for sip@optimus.ietf.org; Tue, 03 Feb 2004 18:00:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11025 for ; Tue, 3 Feb 2004 18:00:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9XB-0004lD-00 for sip@ietf.org; Tue, 03 Feb 2004 18:00:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9WJ-0004fc-00 for sip@ietf.org; Tue, 03 Feb 2004 17:59:52 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9VK-0004UM-00 for sip@ietf.org; Tue, 03 Feb 2004 17:58:50 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 14:58:21 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Feb 2004 14:58:20 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 14:58:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Feb 2004 14:58:25 -0800 Message-ID: Thread-Topic: draft-ietf-sip-gruu-00 Thread-Index: AcPqIyNuTRgstfIzT8CTfbZQIwhbWAAgzoMg From: "Orit Levin" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 03 Feb 2004 22:58:20.0183 (UTC) FILETIME=[37BA3A70:01C3EAA9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] draft-ietf-sip-gruu-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I have the following remarks regarding the GRUU draft: 1. The draft states that one of the GRUU properties is =20 " o It MUST NOT be possible, based on inspection of the URI, to determine the associated Contact URI or Address of Record." It MUST be possible to achieve such a property for a GRUU (if the Registrar wants to enforce such a policy for its domain), but it is not part of the requirements for the GRUU concept to always enforce such a policy. 2. It is expressed throughout the draft that=20 "This extension allows a UA to obtain a GRUU, and to use a GRUU. These two mechanisms are separate, in that a UA can obtain a GRUU in any way it likes, and use the mechanisms in this specification to use them. Similarly, a UA can obtain a GRUU but never use it." For consistency, I suggest in section "6.2 Using the GRUU" change the first sentence from "A UA first obtains a GRUU using the procedures of Section 6.1." to=20 "A UA first obtains a GRUU using the procedures of Section 6.1 or by other means". Thanks, Orit. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Monday, February 02, 2004 10:54 PM To: Christian Jansson Cc: Paul Kyzivat; Jussi.Turunen@nokia.com; nataraju.alilaghatta@wipro.com; sanjsinh@cisco.com; sip@ietf.org Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request Christian Jansson wrote: > Perhaps a little late, and hopefully not off topic. Comments inline. Not too late, not off topic. >=20 >=20 >>Jonathan R. wrote >>This, however, leads me into thinking a bit on the lifecycle >>management for GRUUs. Currently, GRUU is bound to a single=20 >>registration, where the registration is defined by the Contact URI. If >=20 >=20 >>the UA should "move", in the sense that it acquires a new IP address,=20 >>this will be a new Contact URI, and therefore, a new GRUU. It would be >>nice if, instead, the GRUU were truly bound to the UA instance, and=20 >>that even if the UA instance changed IP addresses, the GRUU could=20 >>remain unchanged. In such a case, if the UA moves, there is actually=20 >>no need to issue any target refresh requests. The UA would simply=20 >>re-register, update the binding of its GRUU to its new IP=20 >>address, and=20 >>existing calls would be correctly routed. >=20 >=20 > But if the ip actually changes, it would be necessary to send an updated > SDP with the new ip in the c=3D line. Yes, that is true. If media relays are used (i.e., TURN), it might be=20 possible to avoid even this, but lets leave that aside for now. > So your idea won't save you from > having to send a SIP request to the other end every time the ip changes > in an INVITE session.=20 Right. However, it does solve the problem that, previously, if both=20 endpoints moved at the same time, the call would fail - neither side=20 could signal the other. > For a non-INVITE session though the idea would > save a lot of request from being sent if the session only contains > signaling. Right, in particular, a long lived presence subscription, for example. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 3 19:03:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13909 for ; Tue, 3 Feb 2004 19:03:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAVL-0003GS-6I for sip-archive@odin.ietf.org; Tue, 03 Feb 2004 19:02:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1402ttx012542 for sip-archive@odin.ietf.org; Tue, 3 Feb 2004 19:02:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAUy-0003BY-NK; Tue, 03 Feb 2004 19:02:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAUB-0003AU-Cv for sip@optimus.ietf.org; Tue, 03 Feb 2004 19:01:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13870 for ; Tue, 3 Feb 2004 19:01:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoAU8-0002is-00 for sip@ietf.org; Tue, 03 Feb 2004 19:01:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoATC-0002cd-00 for sip@ietf.org; Tue, 03 Feb 2004 19:00:43 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AoASR-0002Sb-00 for sip@ietf.org; Tue, 03 Feb 2004 18:59:56 -0500 Received: from softarmor.com ([209.101.48.11]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1400Csb008571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2004 18:00:13 -0600 Message-ID: <402035B7.5030206@softarmor.com> Date: Tue, 03 Feb 2004 17:58:47 -0600 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-gruu-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Orit Levin wrote: > I have the following remarks regarding the GRUU draft: > > 1. The draft states that one of the GRUU properties is > " o It MUST NOT be possible, based on inspection of the URI, to > determine the associated Contact URI or Address of Record." > > It MUST be possible to achieve such a property for a GRUU (if the > Registrar wants to enforce such a policy for its domain), but it is not > part of the requirements for the GRUU concept to always enforce such a > policy. I have to admit I concur with this position. There might be very useful situations where the anonymity aspect of the GRUU would be undesirable. I can even envision models where the GRUU is cryptographically validatable as representing an instance associated with a specific AOR, including variations where the validation can or cannot be done without prior knowledge of the associated AOR. As far as I can tell, reversibility does not impact the given rationale for the requirements, that: With these rules, it is possible, though not required, to construct a GRUU without requiring the maintenance of any additional state. To do that, the URI would be constructed in the following fashion: So I believe I would support making this a SHOULD strength requirement. Conceivably some discussion of the security implications of NOT meeting this requirement would be 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 exim@www1.ietf.org Wed Feb 4 00:59:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23895 for ; Wed, 4 Feb 2004 00:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoG3z-0007d0-T8 for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 00:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i145x3FX029260 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 00:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoG2z-0007SP-MA; Wed, 04 Feb 2004 00:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoG21-0007Qq-Tc for sip@optimus.ietf.org; Wed, 04 Feb 2004 00:57:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23862 for ; Wed, 4 Feb 2004 00:56:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoG1z-0005yg-00 for sip@ietf.org; Wed, 04 Feb 2004 00:56:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoG12-0005tL-00 for sip@ietf.org; Wed, 04 Feb 2004 00:56:01 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AoG0D-0005ib-00 for sip@ietf.org; Wed, 04 Feb 2004 00:55:09 -0500 Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i145sm9W015068; Wed, 4 Feb 2004 00:54:48 -0500 (EST) Message-ID: <40208910.7070200@dynamicsoft.com> Date: Wed, 04 Feb 2004 00:54:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9359@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9359@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > Hi Jonathan, > > Thanks a lot for the excellent comments. Most of them I will directly > fold into -03. Few clarifications below. > > Cheers, Aki > > Jonathan Rosenberg wrote: > > > >> * section 3, paragraph 3: >> >>> That is, the steady-state of this event package in the absence >>> of, or in addition >> to, soft state >>> provided through the PUBLISH mechanism >> >> this makes it sound like steady state is a function of the event >> packae only. the hard state is a function of the resource uRI and >> event package. Indeed, one may think of an event package as merely >> sub-resource within the full resource. I wonder if it wouldn't be >> useful to come up with a term for this - for example, "scoped >> resource" is a combination of a URI and event package, and >> identifies a particular piece of event state. > > I don't quite follow, but I agree the quoted text is rather vague. > To me the hard state, or "preconfigured" state is just another source > of event state to the composer. The mechanism to set that state might > be other than PUBLISH. Right. I agree with that. Let me try again. Requoting the paragraph: PUBLISH requests create soft state in the ESC. This state has a defined lifetime and will expire after a negotiated amount of time, requiring the publication to be refreshed by subsequent PUBLISH requests. Local policy at the compositor may in turn define hard state for a particular event package. That is, the steady-state of this event package in the absence of, or in addition to, soft state provided through the PUBLISH mechanism. Setting this hard state or configuring the composer policy is out of the scope of this specification. The words "hard state for a particular event package" read to me like it meant that hard state was defined on a package by package basis. But, its not. There would be hard state generally for a particular URI/package basis. So, I'd suggest: There may also be hard state provisioned for each resource for a particular event package. This hard state represents the resource state that is present at all times, and does not expire. My other comment was that the concept of "for each resource for each package" is a common concept, for which I was looking for a term to define. > > > >> * section 5.1: >> >>> As with any other SIP message, the PUBLISH mechanism MAY use the >>> content indirection mechanism defined in [10]. >> >> this statement makes [10] a normative reference, I believe. It is >> listed as informative in the references section. > > I'm not sure I agree. I've understood the RFC editor's policy so that > an informative reference is not required for implementing the RFC. > It's an interesting question as to how this relates to RFC 2119 > terminology. But I think a MAY makes the feature optional so that it > fits the informative reference definition. No - Keith is right in his note. Think of it this way - would the feature interop if, one day, the referenced I-D evaporated and people implemented it differently? In this case, no. If they chose to implement the content indirection, and there was no spec, they would do it differently and there would be no interop. I would just drop the text to avoid the dependency. > > > >> * section 5.3 is out of place. Section 5 is about generating >> requests. the subsections for the most part deal with the specific >> 4 sub-cases you identified in 5.1. However, 5.3 talks about setting >> expirations, which is something that is actually done for the cases >> in 5.2, 5.4, 5.5 and 5.6. I would suggest that eaech of those four >> sections rather describe how the Expires header field is >> constructed for each case. That is consistent with having a column >> in table 1 on expires. Indeed, each section should also talk about >> bodies and etag. Along those lines, section 5.2 does not actually >> say that a body has to be present; it shouold be stated given the >> importance of this fact from table 1. > > I think the reason for this is that I envisioned a PUBLISH carrying > state in some other place than the body. However, I don't know if > such a case would ever exist, and other people have also commented on > this. I think it is safe to assume that the state is always carried > in the body, as opposed to "typically". Yes. >> * the steps in section 6 omit handling for the case where there was >> no SIP-If-Match header field. step 6 says to check for it, and all >> the following steps assume it was there. I would suggest adding a >> bullet to step 6 which says, if there was no SIP-If-Match header >> field, the ESC creates a new etag, and associates it with as-yet >> empty event state. Processing continues in the steps below. This >> way, you always exit step 6 with an etag. > > The attempt was to make etag generation part of step 9. This way, an > entity-tag is generated for each successful publication and returned > in 2xx, irrespective of whether the publication was an initial > publication, a refresh, or a modification. Indeed, a 2xx to a removal > could be treated the same, although such an entity-tag is useless at > that point. > > So I think it is ok to exit step 6 without an entity tag, as long as > step 9 is clear that entity-tags are generated for all successful > publications. > Step 8 requires an entity tag to be defined, however. >> * sectiton 11.1: >> >>> Authentication issues are discussed in SIP [2]. The exact >> methods for >>> creation and manipulation of the ESC authorization policies are >>> outside the scope of this document. >> >> you will get dinged on this by Bellovin, guaranteed. He wants to >> see statements about baseline mandtory to implement mechahnisms. >> Its fine to say that this mechanism is digest, as mandated by >> rfc3261. >> >>> To prevent replay attacks, implementations SHOULD require >>> authentication with anti-replay protection. >> Authentication issues are >>> discussed in SIP [2]. >> >> as above.... does this mean digest with next-nonce or are you >> talking sips? >> >> and section 11.4: >> >>> To prevent such attacks, implementations SHOULD, at a minimum, >>> provide integrity protection across the To, From, Event, >>> SIP-If-Match, Route, and Expires headers and the bodies >> of PUBLISH >>> requests. >> >> as above, he will ask for a mechanism. This requiurement makes the >> choice sips. >> >> Same in 11.5. > > I see what you are saying. But is it really so that each new method > that gets added to SIP needs to explicitly mandate certain security > mechanisms? At least going beyond the security considerations in RFC > 3261 seems unnecessary, since the properties of PUBLISH are very > similar to, say, REGISTER. I have made this same comment in past discussions of specs going through iesg. However, the security ADs believe strongly in reptition of security requirements in specifications. Trust me, you WILL get dinged on this. It is much easier to just add text stating the same normative requiremetns as in rfc3261, then to get a discuss during iesg evaluation. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 01:07:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24172 for ; Wed, 4 Feb 2004 01:07:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoGBV-0008I2-FM for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 01:06:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1466n0X031804 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 01:06:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoGAl-00084Y-Tt; Wed, 04 Feb 2004 01:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoGAh-00083v-RJ for sip@optimus.ietf.org; Wed, 04 Feb 2004 01:06:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24140 for ; Wed, 4 Feb 2004 01:05:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoGAf-0006oP-00 for sip@ietf.org; Wed, 04 Feb 2004 01:05:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoG9e-0006jJ-00 for sip@ietf.org; Wed, 04 Feb 2004 01:04:55 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AoG8p-0006Zy-00 for sip@ietf.org; Wed, 04 Feb 2004 01:04:03 -0500 Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1463f9W015078; Wed, 4 Feb 2004 01:03:41 -0500 (EST) Message-ID: <40208B24.5020004@dynamicsoft.com> Date: Wed, 04 Feb 2004 01:03:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: Orit Levin , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-gruu-00 References: <402035B7.5030206@softarmor.com> In-Reply-To: <402035B7.5030206@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Dean Willis wrote: > Orit Levin wrote: > >> I have the following remarks regarding the GRUU draft: >> >> 1. The draft states that one of the GRUU properties is " o It MUST >> NOT be possible, based on inspection of the URI, to >> determine the associated Contact URI or Address of Record." >> >> It MUST be possible to achieve such a property for a GRUU (if the >> Registrar wants to enforce such a policy for its domain), but it is not >> part of the requirements for the GRUU concept to always enforce such a >> policy. > > > I have to admit I concur with this position. There might be very useful > situations where the anonymity aspect of the GRUU would be undesirable. > > I can even envision models where the GRUU is cryptographically > validatable as representing an instance associated with a specific AOR, > including variations where the validation can or cannot be done without > prior knowledge of the associated AOR. > > As far as I can tell, reversibility does not impact the given rationale > for the requirements, that: > > With these rules, it is possible, though not required, to construct a > GRUU without requiring the maintenance of any additional state. To do > that, the URI would be constructed in the following fashion: > > So I believe I would support making this a SHOULD strength requirement. > Conceivably some discussion of the security implications of NOT meeting > this requirement would be appropriate. I am ok to lessen the requirement. The question becomes, do we want a way to allow the client to signal that a randomized gruu is desired, or is it up to the server? I would much prefer to leave it up to the server, in which case the only thing that we need to change is the requirement, above. I changed the text to read: In many cases, it will be desirable to construct the GRUU in such a way that it will not be possible, based on inspection of the URI, to determine the associated Contact URI or Address of Record. Whether or not a GRUU should be constructed with this property is a local policy decision of the administrator. Orit writes: > 2. It is expressed throughout the draft that > "This extension allows a UA to obtain a GRUU, and to use a GRUU. These > two mechanisms are separate, in that a UA can obtain a GRUU in any way > it likes, and use the mechanisms in this specification to use them. > Similarly, a UA can obtain a GRUU but never use it." > > For consistency, I suggest in section "6.2 Using the GRUU" change the > first sentence from > > "A UA first obtains a GRUU using the procedures of Section 6.1." > to > "A UA first obtains a GRUU using the procedures of Section 6.1 or by > other means". OK, with the addition of "outside the scope of this specification.". -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 05:12:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28703 for ; Wed, 4 Feb 2004 05:12:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoK0L-00006U-EX for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 05:11:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14ABXOm000391 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 05:11:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoK01-0008W4-Lb; Wed, 04 Feb 2004 05:11:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJyt-0008Pa-Qn for sip@optimus.ietf.org; Wed, 04 Feb 2004 05:10:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28666 for ; Wed, 4 Feb 2004 05:10:00 -0500 (EST) From: Matthew.Gardiner@aculab.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJyq-0007FG-00 for sip@ietf.org; Wed, 04 Feb 2004 05:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJxu-0007Af-00 for sip@ietf.org; Wed, 04 Feb 2004 05:09:03 -0500 Received: from [213.249.233.131] (helo=mx0.aculab.com) by ietf-mx with esmtp (Exim 4.12) id 1AoJxE-00075t-00 for sip@ietf.org; Wed, 04 Feb 2004 05:08:20 -0500 Received: from localhost (io.aculab.com [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id E95CB410B for ; Wed, 4 Feb 2004 10:15:30 +0000 (GMT) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (io.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14821-09 for ; Wed, 4 Feb 2004 10:15:27 +0000 (GMT) Received: from saturn.aculab.com (unknown [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 529E8404C for ; Wed, 4 Feb 2004 10:15:27 +0000 (GMT) Received: by saturn.aculab.com with Internet Mail Service (5.5.2655.55) id ; Wed, 4 Feb 2004 10:04:53 -0000 Message-ID: <8C9A566C643ED6119E8900A0C9DE297A01F86427@saturn.aculab.com> To: sip@ietf.org Date: Wed, 4 Feb 2004 10:04:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB06.531F57C0" X-Aculab-Com-Scanned: by amavisd-new-20030616-p5 (Debian) at aculab.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,CLICK_BELOW,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] Call transfer using SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C3EB06.531F57C0 Content-Type: text/plain; charset="iso-8859-1" Could somebody please confirm that if I am writing a call control application offering call hold and transfer then the definitive document to follow is draft-ietf-sipping-service-examples-05.txt? Matthew Gardiner Software Engineer Aculab Tel: +44 (0) 1908 273 911 Fax: +44 (0) 1908 273 801 Email: mailto:matthew.gardiner@aculab.com Website: For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm. ------_=_NextPart_001_01C3EB06.531F57C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Call transfer using SIP

Could somebody please confirm that if = I am writing a call control application offering call hold and transfer = then the definitive document to follow is = draft-ietf-sipping-service-examples-05.txt?

Matthew Gardiner
Software Engineer
Aculab
Tel: +44 (0) 1908 273 = 911
Fax: +44 (0) 1908 273 801
Email: mailto:matthew.gardiner@acul= ab.com
Website: <http://www.aculab.com>




For Aculab's privacy policy and = E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm. =


------_=_NextPart_001_01C3EB06.531F57C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 10:10:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09366 for ; Wed, 4 Feb 2004 10:10:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOfe-0006hh-2f for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 10:10:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14FATZ5025709 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 10:10:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOfD-0006SQ-5G; Wed, 04 Feb 2004 10:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOeR-0006IG-14 for sip@optimus.ietf.org; Wed, 04 Feb 2004 10:09:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09212 for ; Wed, 4 Feb 2004 10:09:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoOeO-0006Al-00 for sip@ietf.org; Wed, 04 Feb 2004 10:09:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoOdV-00065l-00 for sip@ietf.org; Wed, 04 Feb 2004 10:08:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AoOd8-0005ze-00 for sip@ietf.org; Wed, 04 Feb 2004 10:07:54 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 04 Feb 2004 07:07:29 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i14F7Flt025260; Wed, 4 Feb 2004 10:07:15 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFU56013; Wed, 4 Feb 2004 10:07:14 -0500 (EST) Message-ID: <40210AA2.6050009@cisco.com> Date: Wed, 04 Feb 2004 10:07:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew.Gardiner@aculab.com CC: sip@ietf.org Subject: Re: [Sip] Call transfer using SIP References: <8C9A566C643ED6119E8900A0C9DE297A01F86427@saturn.aculab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Matthew.Gardiner@aculab.com wrote: > Could somebody please confirm that if I am writing a call control > application offering call hold and transfer then the definitive document > to follow is draft-ietf-sipping-service-examples-05.txt? No. The *definitive* document is RFC3261 and related documents. The details of call control are derivative from that in somewhat the same way the much of physics is derivative from F=MA. Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an *example*. It is not normative. However, that draft is certainly helpful and educational. You would do well to understand what is in there before completing your task. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 11:13:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12615 for ; Wed, 4 Feb 2004 11:13:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPeK-0006OQ-D3 for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 11:13:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14GDCBK024512 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 11:13:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPe8-0006M9-5q; Wed, 04 Feb 2004 11:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPdQ-0006L4-TY for sip@optimus.ietf.org; Wed, 04 Feb 2004 11:12:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12558 for ; Wed, 4 Feb 2004 11:12:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPdP-0004v9-00 for sip@ietf.org; Wed, 04 Feb 2004 11:12:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPcV-0004qA-00 for sip@ietf.org; Wed, 04 Feb 2004 11:11:20 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AoPbn-0004gY-00 for sip@ietf.org; Wed, 04 Feb 2004 11:10:35 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 16:09:57 -0000 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZGD3H3XC; Wed, 4 Feb 2004 16:09:53 -0000 From: "Conroy, Lawrence (SMTP)" To: Paul Kyzivat Cc: Matthew.Gardiner@aculab.com, sip@ietf.org In-Reply-To: <40210AA2.6050009@cisco.com> References: <8C9A566C643ED6119E8900A0C9DE297A01F86427@saturn.aculab.com> <40210AA2.6050009@cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <90776494-572C-11D8-80DF-00039355516C@roke.co.uk> Content-Transfer-Encoding: 7bit Subject: Re: [Sip] Call transfer using SIP Date: Wed, 4 Feb 2004 16:09:52 +0000 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi folks, It's an interesting point. Paul's comment seems to be "there are many different ways of skinning a cat, and the only normative definition is of the knife". The IETF defines the details of knife behaviour, and it's up to everyone else to sort out how to use it for their purpose. My understanding is that the IETF (and the SIP WG in particular) will not produce normative definitions of these (or any other) teleservices, only definitions of protocol elements that might be used for these (or other) purposes. SIPPING will consider such services and decide on the protocol elements they think are needed (that don't exist already) and then SIP grinds through the details. Thus the only teleservice examples are in the service-examples document (collected together as a convenience), these are non-normative, and there will never BE normative teleservice definitions produced by these groups. Is this correct? all the best, Lawrence On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote: > > > Matthew.Gardiner@aculab.com wrote: >> Could somebody please confirm that if I am writing a call control >> application offering call hold and transfer then the definitive >> document to follow is draft-ietf-sipping-service-examples-05.txt? > > No. The *definitive* document is RFC3261 and related documents. The > details of call control are derivative from that in somewhat the same > way the much of physics is derivative from F=MA. > > Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an > *example*. It is not normative. > > However, that draft is certainly helpful and educational. You would do > well to understand what is in there before completing your task. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 11:30:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13311 for ; Wed, 4 Feb 2004 11:30:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPuu-0007sJ-FQ for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 11:30:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14GUKmf030267 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 11:30:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPuf-0007op-F0; Wed, 04 Feb 2004 11:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPu7-0007gF-H3 for sip@optimus.ietf.org; Wed, 04 Feb 2004 11:29:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13188 for ; Wed, 4 Feb 2004 11:29:29 -0500 (EST) From: Matthew.Gardiner@aculab.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPu6-0006qt-00 for sip@ietf.org; Wed, 04 Feb 2004 11:29:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPtF-0006jj-00 for sip@ietf.org; Wed, 04 Feb 2004 11:28:38 -0500 Received: from [213.249.233.131] (helo=mx0.aculab.com) by ietf-mx with esmtp (Exim 4.12) id 1AoPsJ-0006ch-00 for sip@ietf.org; Wed, 04 Feb 2004 11:27:39 -0500 Received: from localhost (io.aculab.com [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id 26239408C; Wed, 4 Feb 2004 16:34:54 +0000 (GMT) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (io.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22772-07; Wed, 4 Feb 2004 16:34:49 +0000 (GMT) Received: from saturn.aculab.com (unknown [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id E984B40F4; Wed, 4 Feb 2004 16:34:48 +0000 (GMT) Received: by saturn.aculab.com with Internet Mail Service (5.5.2655.55) id ; Wed, 4 Feb 2004 16:24:13 -0000 Message-ID: <8C9A566C643ED6119E8900A0C9DE297A01F86431@saturn.aculab.com> To: lwc@roke.co.uk, pkyzivat@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] Call transfer using SIP Date: Wed, 4 Feb 2004 16:24:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB3B.4C9F6C20" X-Aculab-Com-Scanned: by amavisd-new-20030616-p5 (Debian) at aculab.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,CLICK_BELOW,HTML_20_30, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EB3B.4C9F6C20 Content-Type: text/plain; charset="iso-8859-1" This vagueness makes it very difficult to engineer a telephony solution which interoperates with other vendors equipment. In the telephony arena getting call transfer right is of fundamental importance. A simple document titled "Call transfer in SIP" would suffice in de-mystifying this area. -----Original Message----- From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] Sent: 04 February 2004 16:10 To: Paul Kyzivat Cc: Matthew.Gardiner@aculab.com; sip@ietf.org Subject: Re: [Sip] Call transfer using SIP Hi folks, It's an interesting point. Paul's comment seems to be "there are many different ways of skinning a cat, and the only normative definition is of the knife". The IETF defines the details of knife behaviour, and it's up to everyone else to sort out how to use it for their purpose. My understanding is that the IETF (and the SIP WG in particular) will not produce normative definitions of these (or any other) teleservices, only definitions of protocol elements that might be used for these (or other) purposes. SIPPING will consider such services and decide on the protocol elements they think are needed (that don't exist already) and then SIP grinds through the details. Thus the only teleservice examples are in the service-examples document (collected together as a convenience), these are non-normative, and there will never BE normative teleservice definitions produced by these groups. Is this correct? all the best, Lawrence On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote: > > > Matthew.Gardiner@aculab.com wrote: >> Could somebody please confirm that if I am writing a call control >> application offering call hold and transfer then the definitive >> document to follow is draft-ietf-sipping-service-examples-05.txt? > > No. The *definitive* document is RFC3261 and related documents. The > details of call control are derivative from that in somewhat the same > way the much of physics is derivative from F=MA. > > Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an > *example*. It is not normative. > > However, that draft is certainly helpful and educational. You would do > well to understand what is in there before completing your task. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm. ------_=_NextPart_001_01C3EB3B.4C9F6C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Call transfer using SIP

This vagueness makes it very difficult to engineer a = telephony solution which interoperates with other vendors equipment. In = the telephony arena getting call transfer right is of fundamental = importance. A simple document titled "Call transfer in SIP" = would suffice in de-mystifying this area.

-----Original Message-----
From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk]
Sent: 04 February 2004 16:10
To: Paul Kyzivat
Cc: Matthew.Gardiner@aculab.com; sip@ietf.org
Subject: Re: [Sip] Call transfer using SIP


Hi folks,
   It's an interesting point.
Paul's comment seems to be "there are many = different ways of skinning a
cat, and the
only normative definition is of the = knife".
The IETF defines the details of knife behaviour, and = it's up to
everyone else to sort
out how to use it for their purpose.

My understanding is that the IETF (and the SIP WG in = particular) will
not produce normative
definitions of these (or any other) teleservices, = only definitions of
protocol elements that
might be used for these (or other) purposes.
SIPPING will consider such services and decide on = the protocol elements
they think are needed
(that don't exist already) and then SIP grinds = through the details.

Thus the only teleservice examples are in the = service-examples document
(collected together
as a convenience), these are non-normative, and = there will never BE
normative teleservice
definitions produced by these groups. Is this = correct?

all the best,
   Lawrence

On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote:

>
>
> Matthew.Gardiner@aculab.com wrote:
>> Could somebody please confirm that if I am = writing a call control
>> application offering call hold and transfer = then the definitive
>> document to follow is = draft-ietf-sipping-service-examples-05.txt?
>
> No. The *definitive* document is RFC3261 and = related documents. The
> details of call control are derivative from = that in somewhat the same
> way the much of physics is derivative from = F=3DMA.
>
> Draft-ietf-sipping-service-examples-05.txt is = (not surprisingly) an
> *example*. It is not normative.
>
> However, that draft is certainly helpful and = educational. You would do
> well to understand what is in there before = completing your task.
>
>       Paul
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

--
Registered Office: Roke Manor Research Ltd, Siemens = House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any = attachments is confidential to
Roke Manor Research Ltd and must not be passed to = any third party without
permission. This communication is for information = only and shall not create or
change any contractual relationship.


For Aculab's privacy policy and E-Mail disclaimer, = Click Here : http://www.aculab.com/company/legal_notice.htm. =


------_=_NextPart_001_01C3EB3B.4C9F6C20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 11:38:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13759 for ; Wed, 4 Feb 2004 11:38:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQ2R-0000PK-68 for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 11:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Gc6hq001533 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 11:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQ2M-0000NN-7V; Wed, 04 Feb 2004 11:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQ1i-0000D7-7C for sip@optimus.ietf.org; Wed, 04 Feb 2004 11:37:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13717 for ; Wed, 4 Feb 2004 11:37:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQ1h-00001u-00 for sip@ietf.org; Wed, 04 Feb 2004 11:37:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQ0o-0007jp-00 for sip@ietf.org; Wed, 04 Feb 2004 11:36:27 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly09a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AoQ0H-0007cx-00 for sip@ietf.org; Wed, 04 Feb 2004 11:35:53 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly09a.srv.mailcontrol.com (MailControl) with SMTP id i14GZ0Ow020961; Wed, 4 Feb 2004 16:35:00 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Wed, 4 Feb 2004 16:34:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Call transfer using SIP Date: Wed, 4 Feb 2004 16:35:00 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B186@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] Call transfer using SIP Thread-Index: AcPrOdki+frcAaBMRfijBWmIVUb+IAAAnDww From: "Chris Boulton" To: "Conroy, Lawrence (SMTP)" , "Paul Kyzivat" Cc: , X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Lawrence - remember that SIP is a transport protocol which allows an objective to be reached in many differing ways. There is no correct behavior in many scenarios as long as they fall between the guidelines set out. It would be wrong to define normative behavior for such scenarios and so a push in the right direction towards preferred methods is the best approach. Chris. >-----Original Message----- >From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] >Sent: 04 February 2004 16:10 >To: Paul Kyzivat >Cc: Matthew.Gardiner@aculab.com; sip@ietf.org >Subject: Re: [Sip] Call transfer using SIP > >Hi folks, > It's an interesting point. >Paul's comment seems to be "there are many different ways of skinning a >cat, and the >only normative definition is of the knife". >The IETF defines the details of knife behaviour, and it's up to >everyone else to sort >out how to use it for their purpose. > >My understanding is that the IETF (and the SIP WG in particular) will >not produce normative >definitions of these (or any other) teleservices, only definitions of >protocol elements that >might be used for these (or other) purposes. >SIPPING will consider such services and decide on the protocol elements >they think are needed >(that don't exist already) and then SIP grinds through the details. > >Thus the only teleservice examples are in the service-examples document >(collected together >as a convenience), these are non-normative, and there will never BE >normative teleservice >definitions produced by these groups. Is this correct? > >all the best, > Lawrence > >On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote: > >> >> >> Matthew.Gardiner@aculab.com wrote: >>> Could somebody please confirm that if I am writing a call control >>> application offering call hold and transfer then the definitive >>> document to follow is draft-ietf-sipping-service-examples-05.txt? >> >> No. The *definitive* document is RFC3261 and related documents. The >> details of call control are derivative from that in somewhat the same >> way the much of physics is derivative from F=3DMA. >> >> Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an >> *example*. It is not normative. >> >> However, that draft is certainly helpful and educational. You would do >> well to understand what is in there before completing your task. >> >> Paul >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 12:26:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15669 for ; Wed, 4 Feb 2004 12:26:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQmw-0004Pj-VM for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 12:26:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14HQA9T016966 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 12:26:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQmo-0004OK-Cb; Wed, 04 Feb 2004 12:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQm7-0004Iz-2W for sip@optimus.ietf.org; Wed, 04 Feb 2004 12:25:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15583 for ; Wed, 4 Feb 2004 12:25:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQm5-0004rW-00 for sip@ietf.org; Wed, 04 Feb 2004 12:25:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQlB-0004lV-00 for sip@ietf.org; Wed, 04 Feb 2004 12:24:22 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AoQkR-0004aq-00 for sip@ietf.org; Wed, 04 Feb 2004 12:23:35 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 17:22:59 -0000 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZGD3H360; Wed, 4 Feb 2004 17:22:54 -0000 From: "Conroy, Lawrence (SMTP)" To: Chris Boulton Cc: Paul Kyzivat , Matthew.Gardiner@aculab.com, sip@ietf.org In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B186@gbnewp0758m.eu.ubiquity.net> References: <45730E094814E44488F789C1CDED27AE0219B186@gbnewp0758m.eu.ubiquity.net> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Sip] Call transfer using SIP Date: Wed, 4 Feb 2004 17:22:54 +0000 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Chris, folks, That's what I said - the SIP/SIPPING groups will not produce normative teleservice definitions - we're in TSV and a teleservice is in/above APPs. I do sympathise with those folks who want a definition so they can interwork with other vendor's kit in implementing those teleservices. Short answer is - yup - it would be a good idea, but not by the IETF. I note in passing that Alan Johnston works for a fine Telecom Service Provider that might be expected to have an interest in the way teleservices are implemented by different vendors. all the best, Lawrence On 4 Feb 2004, at 4:35 pm, Chris Boulton wrote: > Lawrence - remember that SIP is a transport protocol which allows an > objective to be reached in many differing ways. There is no correct > behavior in many scenarios as long as they fall between the guidelines > set out. It would be wrong to define normative behavior for such > scenarios and so a push in the right direction towards preferred > methods > is the best approach. > > Chris. > > >> -----Original Message----- >> From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] >> Sent: 04 February 2004 16:10 >> To: Paul Kyzivat >> Cc: Matthew.Gardiner@aculab.com; sip@ietf.org >> Subject: Re: [Sip] Call transfer using SIP >> >> Hi folks, >> It's an interesting point. >> Paul's comment seems to be "there are many different ways of skinning >> a >> cat, and the >> only normative definition is of the knife". >> The IETF defines the details of knife behaviour, and it's up to >> everyone else to sort >> out how to use it for their purpose. >> >> My understanding is that the IETF (and the SIP WG in particular) will >> not produce normative >> definitions of these (or any other) teleservices, only definitions of >> protocol elements that >> might be used for these (or other) purposes. >> SIPPING will consider such services and decide on the protocol >> elements >> they think are needed >> (that don't exist already) and then SIP grinds through the details. >> >> Thus the only teleservice examples are in the service-examples >> document >> (collected together >> as a convenience), these are non-normative, and there will never BE >> normative teleservice >> definitions produced by these groups. Is this correct? >> >> all the best, >> Lawrence >> >> On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote: >> >>> >>> >>> Matthew.Gardiner@aculab.com wrote: >>>> Could somebody please confirm that if I am writing a call control >>>> application offering call hold and transfer then the definitive >>>> document to follow is draft-ietf-sipping-service-examples-05.txt? >>> >>> No. The *definitive* document is RFC3261 and related documents. The >>> details of call control are derivative from that in somewhat the same >>> way the much of physics is derivative from F=MA. >>> >>> Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an >>> *example*. It is not normative. >>> >>> However, that draft is certainly helpful and educational. You would > do >>> well to understand what is in there before completing your task. >>> >>> Paul >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > This message has been scanned for viruses by MailControl - > www.mailcontrol.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 12:54:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17701 for ; Wed, 4 Feb 2004 12:54:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRDz-00078X-Sy for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 12:54:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Hs7cg027432 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 12:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRDt-00077W-DV; Wed, 04 Feb 2004 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRDG-00072Z-7o for sip@optimus.ietf.org; Wed, 04 Feb 2004 12:53:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17629 for ; Wed, 4 Feb 2004 12:53:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoRDE-0000jl-00 for sip@ietf.org; Wed, 04 Feb 2004 12:53:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoRCJ-0000du-00 for sip@ietf.org; Wed, 04 Feb 2004 12:52:24 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AoRBT-0000SL-00 for sip@ietf.org; Wed, 04 Feb 2004 12:51:31 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Feb 2004 09:50:58 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Feb 2004 09:51:01 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Feb 2004 09:51:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-gruu-00 Date: Wed, 4 Feb 2004 09:51:08 -0800 Message-ID: Thread-Topic: [Sip] draft-ietf-sip-gruu-00 Thread-Index: AcPq5KM+wSeiEdDQSo+0FYPzkOQTtQAYqXTQ From: "Orit Levin" To: "Jonathan Rosenberg" , "Dean Willis" Cc: X-OriginalArrivalTime: 04 Feb 2004 17:51:09.0573 (UTC) FILETIME=[78A41350:01C3EB47] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sounds perfect to me. Thanks, Orit. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Tuesday, February 03, 2004 10:03 PM To: Dean Willis Cc: Orit Levin; sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-gruu-00 inline. Dean Willis wrote: > Orit Levin wrote: >=20 >> I have the following remarks regarding the GRUU draft: >> >> 1. The draft states that one of the GRUU properties is " o It MUST >> NOT be possible, based on inspection of the URI, to >> determine the associated Contact URI or Address of Record." >> >> It MUST be possible to achieve such a property for a GRUU (if the >> Registrar wants to enforce such a policy for its domain), but it is not >> part of the requirements for the GRUU concept to always enforce such a >> policy. >=20 >=20 > I have to admit I concur with this position. There might be very useful=20 > situations where the anonymity aspect of the GRUU would be undesirable. >=20 > I can even envision models where the GRUU is cryptographically=20 > validatable as representing an instance associated with a specific AOR,=20 > including variations where the validation can or cannot be done without=20 > prior knowledge of the associated AOR. >=20 > As far as I can tell, reversibility does not impact the given rationale=20 > for the requirements, that: >=20 > With these rules, it is possible, though not required, to construct a > GRUU without requiring the maintenance of any additional state. To do > that, the URI would be constructed in the following fashion: >=20 > So I believe I would support making this a SHOULD strength requirement.=20 > Conceivably some discussion of the security implications of NOT meeting=20 > this requirement would be appropriate. I am ok to lessen the requirement. The question becomes, do we want a way to allow the client to signal=20 that a randomized gruu is desired, or is it up to the server? I would=20 much prefer to leave it up to the server, in which case the only thing=20 that we need to change is the requirement, above. I changed the text to=20 read: In many cases, it will be desirable to construct the GRUU in such a way that it will not be possible, based on inspection of the URI, to determine the associated Contact URI or Address of Record. Whether or not a GRUU should be constructed with this property is a local policy decision of the administrator. Orit writes: > 2. It is expressed throughout the draft that=20 > "This extension allows a UA to obtain a GRUU, and to use a GRUU. These > two mechanisms are separate, in that a UA can obtain a GRUU in any way > it likes, and use the mechanisms in this specification to use them. > Similarly, a UA can obtain a GRUU but never use it." >=20 > For consistency, I suggest in section "6.2 Using the GRUU" change the > first sentence from >=20 > "A UA first obtains a GRUU using the procedures of Section 6.1." > to=20 > "A UA first obtains a GRUU using the procedures of Section 6.1 or by > other means". OK, with the addition of "outside the scope of this specification.". -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 14:28:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21469 for ; Wed, 4 Feb 2004 14:28:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSh1-000527-1A for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 14:28:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14JSAND019285 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 14:28:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSgr-0004zv-T1; Wed, 04 Feb 2004 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSgK-0004yf-E9 for sip@optimus.ietf.org; Wed, 04 Feb 2004 14:27:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21445 for ; Wed, 4 Feb 2004 14:27:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoSgH-0002a9-00 for sip@ietf.org; Wed, 04 Feb 2004 14:27:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoSfV-0002V5-00 for sip@ietf.org; Wed, 04 Feb 2004 14:26:38 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AoSf5-0002OF-00 for sip@ietf.org; Wed, 04 Feb 2004 14:26:11 -0500 Received: from softarmor.com ([209.101.48.11]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i14JQVsb013367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2004 13:26:33 -0600 Message-ID: <4021470D.7050104@softarmor.com> Date: Wed, 04 Feb 2004 13:25:01 -0600 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Orit Levin , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-gruu-00 References: <402035B7.5030206@softarmor.com> <40208B24.5020004@dynamicsoft.com> In-Reply-To: <40208B24.5020004@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > In many cases, it will be desirable to construct the GRUU in such a > way that it will not be possible, based on inspection of the URI, to > determine the associated Contact URI or Address of Record. Whether or > not a GRUU should be constructed with this property is a local policy > decision of the administrator. > This works for me. You might even strike " of the administrator" from the end. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 14:32:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21597 for ; Wed, 4 Feb 2004 14:32:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSko-0005bQ-HD for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 14:32:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14JW6vk021494 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 14:32:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSkk-0005Vy-Si; Wed, 04 Feb 2004 14:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSk8-0005Sp-47 for sip@optimus.ietf.org; Wed, 04 Feb 2004 14:31:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21574 for ; Wed, 4 Feb 2004 14:31:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoSk5-0002vg-00 for sip@ietf.org; Wed, 04 Feb 2004 14:31:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoSjB-0002qa-00 for sip@ietf.org; Wed, 04 Feb 2004 14:30:26 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AoSiG-0002g4-00 for sip@ietf.org; Wed, 04 Feb 2004 14:29:28 -0500 Received: from softarmor.com ([209.101.48.11]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i14JTisb013386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2004 13:29:46 -0600 Message-ID: <402147CD.20007@softarmor.com> Date: Wed, 04 Feb 2004 13:28:13 -0600 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Conroy, Lawrence (SMTP)" CC: Chris Boulton , Paul Kyzivat , Matthew.Gardiner@aculab.com, sip@ietf.org Subject: Re: [Sip] Call transfer using SIP References: <45730E094814E44488F789C1CDED27AE0219B186@gbnewp0758m.eu.ubiquity.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mathew asked: > Could somebody please confirm that if I am writing a call control > application offering call hold and transfer then the definitive > document to follow is draft-ietf-sipping-service-examples-05.txt? and Lawrence said: > Short answer is - yup - it would be a good idea, but not by the IETF. So, I might ask, would it be worth encouraging our friends at SIP Forum to publish some "best practices" 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 exim@www1.ietf.org Wed Feb 4 14:44:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22064 for ; Wed, 4 Feb 2004 14:44:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSw2-00076o-Jb for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 14:43:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14JhgI6027264 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 14:43:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSvN-0006s8-WE; Wed, 04 Feb 2004 14:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSuj-0006qm-TN for sip@optimus.ietf.org; Wed, 04 Feb 2004 14:42:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21986 for ; Wed, 4 Feb 2004 14:42:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoSug-0003uF-00 for sip@ietf.org; Wed, 04 Feb 2004 14:42:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoSti-0003oX-00 for sip@ietf.org; Wed, 04 Feb 2004 14:41:19 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1AoSsl-0003fA-00 for sip@ietf.org; Wed, 04 Feb 2004 14:40:19 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i14JdcDm021639; Wed, 4 Feb 2004 13:39:38 -0600 (CST) Message-ID: <40214A79.FABB16EE@alcatel.com> Date: Wed, 04 Feb 2004 13:39:37 -0600 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew.Gardiner@aculab.com CC: lwc@roke.co.uk, pkyzivat@cisco.com, sip@ietf.org Subject: Re: [Sip] Call transfer using SIP References: <8C9A566C643ED6119E8900A0C9DE297A01F86431@saturn.aculab.com> Content-Type: multipart/alternative; boundary="------------C81D543F8213B85A7F45CA0D" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,CLICK_BELOW,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --------------C81D543F8213B85A7F45CA0D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See also: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-03.txt The following, another pertinent draft, seems to have expired for some reason: http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-02.txt Alex. Matthew.Gardiner@aculab.com wrote: > > > This vagueness makes it very difficult to engineer a telephony > solution which interoperates with other vendors equipment. In the > telephony arena getting call transfer right is of fundamental > importance. A simple document titled "Call transfer in SIP" would > suffice in de-mystifying this area. > > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: 04 February 2004 16:10 > To: Paul Kyzivat > Cc: Matthew.Gardiner@aculab.com; sip@ietf.org > Subject: Re: [Sip] Call transfer using SIP > > Hi folks, > It's an interesting point. > Paul's comment seems to be "there are many different ways of skinning > a > cat, and the > only normative definition is of the knife". > The IETF defines the details of knife behaviour, and it's up to > everyone else to sort > out how to use it for their purpose. > > My understanding is that the IETF (and the SIP WG in particular) will > not produce normative > definitions of these (or any other) teleservices, only definitions of > protocol elements that > might be used for these (or other) purposes. > SIPPING will consider such services and decide on the protocol > elements > they think are needed > (that don't exist already) and then SIP grinds through the details. > > Thus the only teleservice examples are in the service-examples > document > (collected together > as a convenience), these are non-normative, and there will never BE > normative teleservice > definitions produced by these groups. Is this correct? > > all the best, > Lawrence > > On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote: > > > > > > > Matthew.Gardiner@aculab.com wrote: > >> Could somebody please confirm that if I am writing a call control > >> application offering call hold and transfer then the definitive > >> document to follow is draft-ietf-sipping-service-examples-05.txt? > > > > No. The *definitive* document is RFC3261 and related documents. The > > details of call control are derivative from that in somewhat the > same > > way the much of physics is derivative from F=MA. > > > > Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an > > *example*. It is not normative. > > > > However, that draft is certainly helpful and educational. You would > do > > well to understand what is in there before completing your task. > > > > Paul > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, > Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is > confidential to > Roke Manor Research Ltd and must not be passed to any third party > without > permission. This communication is for information only and shall not > create or > change any contractual relationship. > > For Aculab's privacy policy and E-Mail disclaimer, Click Here : > http://www.aculab.com/company/legal_notice.htm. > --------------C81D543F8213B85A7F45CA0D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit See also:

http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-03.txt

The following, another pertinent draft,  seems to have expired for some reason:
  http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-02.txt

Alex.
 
 

Matthew.Gardiner@aculab.com wrote:

 

This vagueness makes it very difficult to engineer a telephony solution which interoperates with other vendors equipment. In the telephony arena getting call transfer right is of fundamental importance. A simple document titled "Call transfer in SIP" would suffice in de-mystifying this area.

-----Original Message-----
From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk]
Sent: 04 February 2004 16:10
To: Paul Kyzivat
Cc: Matthew.Gardiner@aculab.com; sip@ietf.org
Subject: Re: [Sip] Call transfer using SIP

Hi folks,
   It's an interesting point.
Paul's comment seems to be "there are many different ways of skinning a
cat, and the
only normative definition is of the knife".
The IETF defines the details of knife behaviour, and it's up to
everyone else to sort
out how to use it for their purpose.

My understanding is that the IETF (and the SIP WG in particular) will
not produce normative
definitions of these (or any other) teleservices, only definitions of
protocol elements that
might be used for these (or other) purposes.
SIPPING will consider such services and decide on the protocol elements
they think are needed
(that don't exist already) and then SIP grinds through the details.

Thus the only teleservice examples are in the service-examples document
(collected together
as a convenience), these are non-normative, and there will never BE
normative teleservice
definitions produced by these groups. Is this correct?

all the best,
   Lawrence

On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote:

>
>
> Matthew.Gardiner@aculab.com wrote:
>> Could somebody please confirm that if I am writing a call control
>> application offering call hold and transfer then the definitive
>> document to follow is draft-ietf-sipping-service-examples-05.txt?
>
> No. The *definitive* document is RFC3261 and related documents. The
> details of call control are derivative from that in somewhat the same
> way the much of physics is derivative from F=MA.
>
> Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an
> *example*. It is not normative.
>
> However, that draft is certainly helpful and educational. You would do
> well to understand what is in there before completing your task.
>
>       Paul
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

--
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.

For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.
 

--------------C81D543F8213B85A7F45CA0D-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 4 17:15:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03933 for ; Wed, 4 Feb 2004 17:15:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVIm-0004Gf-I7 for sip-archive@odin.ietf.org; Wed, 04 Feb 2004 17:15:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14MFKBo016405 for sip-archive@odin.ietf.org; Wed, 4 Feb 2004 17:15:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVIW-0004Fb-Qd; Wed, 04 Feb 2004 17:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVI5-0004EE-Ir for sip@optimus.ietf.org; Wed, 04 Feb 2004 17:14:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03908 for ; Wed, 4 Feb 2004 17:14:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVI3-0007Kq-00 for sip@ietf.org; Wed, 04 Feb 2004 17:14:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVHK-0007F6-00 for sip@ietf.org; Wed, 04 Feb 2004 17:13:50 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AoVGp-00075J-00 for sip@ietf.org; Wed, 04 Feb 2004 17:13:19 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i14MCXr29536; Wed, 4 Feb 2004 14:12:33 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMVYT8T>; Wed, 4 Feb 2004 16:12:34 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF578FA0@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'PROUVOST Sébastien FTRD/DAC/ISS'" , "Jesske, R" Cc: sip@ietf.org Subject: RE: RE : [Sip] draft-ietf-sip-history-info-01.txt Date: Wed, 4 Feb 2004 16:12:30 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Sébastien and Roland, I apologize for the delay in responding. You are correct in that one privacy aspect currently addressed for History-Info is around the UA's ability to require privacy for elements of a message that can somehow divulge information about the end client's identity. In some ways, History-Info could be considered in the category of Record Route, Via, etc. However, HI is an optional header and per the recommendation in RFC 3323, the decision was made that if Header privacy was requested, then History-Info SHOULD not be included. In addition, if through local policy or some other local information available wrt the retargeted URIs, there is knowledge that there should be privacy applied to these URIs, then as discussed in RFC 3323, the intermediary processing that request can also add the Privacy header to ensure that History-Info is also not captured by subsequent intermediaries. This latter point perhaps is not so clearly or explicitly spelled out in the current document in the privacy sections, but there is discussion in the detailed proxy processing behaviour in 2.3.3 that the local policy can define whether the History-Info captured would leave a specific domain (this is of course for optionality, as well, which is another issue that I'll address in a separate email). It seems that what's being discussed in these emails is introducing a specific privacy tag against those entries that local policy defines should not be forwarded outside a specific domain, so that they can be removed (and don't need to be kept persistent by a privacy service). Right now, there's an asumption that these entries are somehow known by the proxy, but perhaps an explicit tag would be useful. OR are you talking about extending the current model in RFC 3323 to specifically address the use of a privacy service for History-Info headers? Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 -----Original Message----- From: PROUVOST Sébastien FTRD/DAC/ISS [mailto:sebastien.prouvost@francetelecom.com] Sent: Thursday, January 22, 2004 4:32 AM To: Jesske, R; sip@ietf.org; Barnes, Mary [NGC:B622:EXCH]; Watson, Mark [MOP:EP10:EXCH]; fluffy@cisco.com Subject: RE : [Sip] draft-ietf-sip-history-info-01.txt I fully support this proposal. The privacy regarding the history-info header relates to the privacy policy accorded to the target of the request (before it is retargeted). Therefore it shall not depend on the privacy policy accorded to the calling UA. The history-info header shall have its own privacy value. Moreover in case the request is retargeted more than once (particularly if the targets represent different users), it shall be possible to request privacy for a target independently of the others. Regards, Sébastien Prouvost France Télécom R&D/DAC/CAR -----Message d'origine----- De : Jesske, R [mailto:R.Jesske@t-com.net] Envoyé : vendredi 16 janvier 2004 10:29 À : sip@ietf.org Cc : Poetzl, Joachim; Alexeitsev, D Objet : [Sip] draft-ietf-sip-history-info-01.txt Dear all, in 1.3 Ensuring the Privacy of History_Info it is proposed to use a priv-value of Session or Header level privacy. I would like to propose a own privacy level for the history info, because the Information shows also information about the network. With regard to the provider operating a network some of the providers don't like to transmit information about call history. Or a redirecting party don't like to show the redirecting address. Therefore it should be possible to delete the history info at domain boundaries based on the privacy-value. I propose the priv-value = "history_info" for the whole History-Info header. In addition a option would be useful where only parts (e.g Indes1.1) of the history info are restricted. That could be done with a privacy statement within the History-Info . Best Regards Roland Deutsche Telekom AG T Com Zentrale Roland Jesske, T332-2 Section T33; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 email: r.jesske@t-com.net _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 5 00:42:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19783 for ; Thu, 5 Feb 2004 00:42:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AocHM-0000Aa-8j for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 00:42:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i155gK6X000648 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 00:42:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AocH4-00009V-Bm; Thu, 05 Feb 2004 00:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AocGn-000093-BD for sip@optimus.ietf.org; Thu, 05 Feb 2004 00:41:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19776 for ; Thu, 5 Feb 2004 00:41:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AocGk-0003Jx-00 for sip@ietf.org; Thu, 05 Feb 2004 00:41:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AocFp-0003FI-00 for sip@ietf.org; Thu, 05 Feb 2004 00:40:45 -0500 Received: from mail.sphere.ad.jp ([210.150.250.130]) by ietf-mx with esmtp (Exim 4.12) id 1AocFd-0003AQ-00 for sip@ietf.org; Thu, 05 Feb 2004 00:40:33 -0500 Received: from HATA-5020 (p6161.nttpc.co.jp [210.136.166.161]) by mail.sphere.ad.jp (Postfix) with ESMTP id 7526433380; Thu, 5 Feb 2004 14:40:28 +0900 (JST) To: jdrosen@dynamicsoft.com, vhegde@san.rr.com Cc: drage@lucent.com, pkyzivat@cisco.com, Brian.Rosen@marconi.com, sip@ietf.org Subject: Re: [Sip] Session timer question From: Hiroaki Hata References: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com> <001001c3b841$b5c99d60$2506c042@WXPvhegde> <3FD0E40A.7020008@dynamicsoft.com> In-Reply-To: <3FD0E40A.7020008@dynamicsoft.com> Message-Id: <200402051452.BCE64762.BBIU@sphere.ad.jp> X-Mailer: Winbiff without EditX [Version 2.42 PL6] X-Accept-Language: ja,en Date: Thu, 5 Feb 2004 14:52:16 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Even if UAC does not support timer and ignores sesssion expires header in a 2xx response, a session could be refreshed in case that UAC can response a 2xx to re-INVITE from UAS. If UAC is not able to recongize a difference between INVITE and re-INVITE and responds 4xx to the request of the refresh, a session would be terminated. It depends just upon the implementation of UAC, doesn't it? PS.The table 2 Jonathan mentioned below is the Figure 3 in draft-13 but it is still called table 3 in text page20. Hiro -- Hiroaki Hata NTTPC Communications,Inc. +81-3-5212-2101 > inline. > > Veda Hegde wrote: > > > Keith: Thanks for pointing this out and I will go with this in my > > implementation. > > > > I think, the 2nd paragraph in "Overview of operation" in the draft > > should be reworded. It says, > > ---------------------------------------------------------------------------- > > --------- This extension has the property that it works even when > > only one UA in a dialog supports it. The processing steps differ > > for handling each of the four cases (UAC supports it, or doesn't, > > and UAS supports it, or doesn't). > > ---------------------------------------------------------------------------- > > -------- > > > > Doesn't this mean even if UAC does not support timer, UAS could > > support it? > > Yes, and this mode is supported. In such a case, the INVITE from the > UAC would lack a Supported header field. Proxies insert > Session-Expires headers. The UAS receives it. Based on table 2 in the > session timer spec, since the UAS supports the extension, it sets the > refresher parameter to "uas", and generates a 2xx with the final > session timer in the session expires header. This header is ignored by > the UAC. The called party will generate refresh requests for the > remainder of the call. > > Note that there is no Require in the 2xx in this case. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 5 02:41:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05401 for ; Thu, 5 Feb 2004 02:41:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe8X-0006o2-3o for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 02:41:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i157fKkh025646 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 02:41:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe8F-0006dN-0m; Thu, 05 Feb 2004 02:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe7y-0006bp-Nc for sip@optimus.ietf.org; Thu, 05 Feb 2004 02:40:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05330 for ; Thu, 5 Feb 2004 02:40:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoe7u-0005gm-00 for sip@ietf.org; Thu, 05 Feb 2004 02:40:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoe6x-0005bQ-00 for sip@ietf.org; Thu, 05 Feb 2004 02:39:43 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoe6D-0005SD-00 for sip@ietf.org; Thu, 05 Feb 2004 02:38:57 -0500 Received: from dynamicsoft.com ([63.113.46.122]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i157ca9W015971; Thu, 5 Feb 2004 02:38:36 -0500 (EST) Message-ID: <4021F2F3.3010400@dynamicsoft.com> Date: Thu, 05 Feb 2004 02:38:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: Orit Levin , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-gruu-00 References: <402035B7.5030206@softarmor.com> <40208B24.5020004@dynamicsoft.com> <4021470D.7050104@softarmor.com> In-Reply-To: <4021470D.7050104@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean Willis wrote: > Jonathan Rosenberg wrote: > >> In many cases, it will be desirable to construct the GRUU in such a >> way that it will not be possible, based on inspection of the URI, to >> determine the associated Contact URI or Address of Record. Whether or >> not a GRUU should be constructed with this property is a local policy >> decision of the administrator. >> > > > This works for me. You might even strike " of the administrator" from > the end. Done. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 5 02:41:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05403 for ; Thu, 5 Feb 2004 02:41:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe8W-0006nz-Vg for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 02:41:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i157fJPd025648 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 02:41:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe8H-0006eV-Mz; Thu, 05 Feb 2004 02:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe84-0006cb-Uf for sip@optimus.ietf.org; Thu, 05 Feb 2004 02:40:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05348 for ; Thu, 5 Feb 2004 02:40:50 -0500 (EST) From: Matthew.Gardiner@aculab.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoe81-0005hZ-00 for sip@ietf.org; Thu, 05 Feb 2004 02:40:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoe78-0005cI-00 for sip@ietf.org; Thu, 05 Feb 2004 02:39:56 -0500 Received: from [213.249.233.131] (helo=mx0.aculab.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoe6k-0005X3-00 for sip@ietf.org; Thu, 05 Feb 2004 02:39:30 -0500 Received: from localhost (io.aculab.com [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id B90F34141; Thu, 5 Feb 2004 07:46:42 +0000 (GMT) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (io.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05549-03; Thu, 5 Feb 2004 07:46:37 +0000 (GMT) Received: from saturn.aculab.com (unknown [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id CE9024013; Thu, 5 Feb 2004 07:46:37 +0000 (GMT) Received: by saturn.aculab.com with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Feb 2004 07:35:58 -0000 Message-ID: <8C9A566C643ED6119E8900A0C9DE297A01F86432@saturn.aculab.com> To: lwc@roke.co.uk, cboulton@ubiquity.net Cc: pkyzivat@cisco.com, sip@ietf.org Subject: RE: [Sip] Call transfer using SIP Date: Thu, 5 Feb 2004 07:35:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EBBA.B165A960" X-Aculab-Com-Scanned: by amavisd-new-20030616-p5 (Debian) at aculab.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,CLICK_BELOW,HTML_20_30, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EBBA.B165A960 Content-Type: text/plain; charset="iso-8859-1" Maybe the author of "Draft-ietf-sipping-service-examples-05.txt" could confirm how definitive the message flows regarding call transfer are therein. (Or point out a preferred document of reference). -----Original Message----- From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] Sent: 04 February 2004 17:23 To: Chris Boulton Cc: Paul Kyzivat; Matthew.Gardiner@aculab.com; sip@ietf.org Subject: Re: [Sip] Call transfer using SIP Hi Chris, folks, That's what I said - the SIP/SIPPING groups will not produce normative teleservice definitions - we're in TSV and a teleservice is in/above APPs. I do sympathise with those folks who want a definition so they can interwork with other vendor's kit in implementing those teleservices. Short answer is - yup - it would be a good idea, but not by the IETF. I note in passing that Alan Johnston works for a fine Telecom Service Provider that might be expected to have an interest in the way teleservices are implemented by different vendors. all the best, Lawrence On 4 Feb 2004, at 4:35 pm, Chris Boulton wrote: > Lawrence - remember that SIP is a transport protocol which allows an > objective to be reached in many differing ways. There is no correct > behavior in many scenarios as long as they fall between the guidelines > set out. It would be wrong to define normative behavior for such > scenarios and so a push in the right direction towards preferred > methods > is the best approach. > > Chris. > > >> -----Original Message----- >> From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] >> Sent: 04 February 2004 16:10 >> To: Paul Kyzivat >> Cc: Matthew.Gardiner@aculab.com; sip@ietf.org >> Subject: Re: [Sip] Call transfer using SIP >> >> Hi folks, >> It's an interesting point. >> Paul's comment seems to be "there are many different ways of skinning >> a >> cat, and the >> only normative definition is of the knife". >> The IETF defines the details of knife behaviour, and it's up to >> everyone else to sort >> out how to use it for their purpose. >> >> My understanding is that the IETF (and the SIP WG in particular) will >> not produce normative >> definitions of these (or any other) teleservices, only definitions of >> protocol elements that >> might be used for these (or other) purposes. >> SIPPING will consider such services and decide on the protocol >> elements >> they think are needed >> (that don't exist already) and then SIP grinds through the details. >> >> Thus the only teleservice examples are in the service-examples >> document >> (collected together >> as a convenience), these are non-normative, and there will never BE >> normative teleservice >> definitions produced by these groups. Is this correct? >> >> all the best, >> Lawrence >> >> On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote: >> >>> >>> >>> Matthew.Gardiner@aculab.com wrote: >>>> Could somebody please confirm that if I am writing a call control >>>> application offering call hold and transfer then the definitive >>>> document to follow is draft-ietf-sipping-service-examples-05.txt? >>> >>> No. The *definitive* document is RFC3261 and related documents. The >>> details of call control are derivative from that in somewhat the same >>> way the much of physics is derivative from F=MA. >>> >>> Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an >>> *example*. It is not normative. >>> >>> However, that draft is certainly helpful and educational. You would > do >>> well to understand what is in there before completing your task. >>> >>> Paul >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > This message has been scanned for viruses by MailControl - > www.mailcontrol.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 > -- Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm. ------_=_NextPart_001_01C3EBBA.B165A960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Call transfer using SIP

Maybe the author of = "Draft-ietf-sipping-service-examples-05.txt" could confirm = how definitive the message flows regarding call transfer are therein. = (Or point out a preferred document of reference).

-----Original Message-----
From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk]
Sent: 04 February 2004 17:23
To: Chris Boulton
Cc: Paul Kyzivat; Matthew.Gardiner@aculab.com; = sip@ietf.org
Subject: Re: [Sip] Call transfer using SIP


Hi Chris, folks,
   That's what I said - the SIP/SIPPING = groups will not produce normative
teleservice definitions - we're in TSV and a = teleservice is in/above
APPs.

I do sympathise with those folks who want a = definition so they can
interwork
with other vendor's kit in implementing those = teleservices.

Short answer is - yup - it would be a good idea, but = not by the IETF.

I note in passing that Alan Johnston works for a fine = Telecom Service
Provider
that might be expected to have an interest in the = way teleservices are
implemented
by different vendors.

all the best,
   Lawrence

On 4 Feb 2004, at 4:35 pm, Chris Boulton = wrote:

> Lawrence - remember that SIP is a transport = protocol which allows an
> objective to be reached in many differing = ways.  There is no correct
> behavior in many scenarios as long as they fall = between the guidelines
> set out.  It would be wrong to define = normative behavior for such
> scenarios and so a push in the right direction = towards preferred
> methods
> is the best approach.
>
> Chris.
>
>
>> -----Original Message-----
>> From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk]
>> Sent: 04 February 2004 16:10
>> To: Paul Kyzivat
>> Cc: Matthew.Gardiner@aculab.com; = sip@ietf.org
>> Subject: Re: [Sip] Call transfer using = SIP
>>
>> Hi folks,
>>   It's an interesting = point.
>> Paul's comment seems to be "there are = many different ways of skinning
>> a
>> cat, and the
>> only normative definition is of the = knife".
>> The IETF defines the details of knife = behaviour, and it's up to
>> everyone else to sort
>> out how to use it for their purpose.
>>
>> My understanding is that the IETF (and the = SIP WG in particular) will
>> not produce normative
>> definitions of these (or any other) = teleservices, only definitions of
>> protocol elements that
>> might be used for these (or other) = purposes.
>> SIPPING will consider such services and = decide on the protocol
>> elements
>> they think are needed
>> (that don't exist already) and then SIP = grinds through the details.
>>
>> Thus the only teleservice examples are in = the service-examples
>> document
>> (collected together
>> as a convenience), these are non-normative, = and there will never BE
>> normative teleservice
>> definitions produced by these groups. Is = this correct?
>>
>> all the best,
>>   Lawrence
>>
>> On 4 Feb 2004, at 3:07 pm, Paul Kyzivat = wrote:
>>
>>>
>>>
>>> Matthew.Gardiner@aculab.com = wrote:
>>>> Could somebody please confirm that = if I am writing a call control
>>>> application offering call hold and = transfer then the definitive
>>>> document to follow is = draft-ietf-sipping-service-examples-05.txt?
>>>
>>> No. The *definitive* document is = RFC3261 and related documents. The
>>> details of call control are derivative = from that in somewhat the same
>>> way the much of physics is derivative = from F=3DMA.
>>>
>>> = Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) = an
>>> *example*. It is not normative.
>>>
>>> However, that draft is certainly = helpful and educational. You would
> do
>>> well to understand what is in there = before completing your task.
>>>
>>>     Paul
>>>
>>>
>>> = _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the = core SIP Protocol
>>> Use sip-implementors@cs.columbia.edu = for questions on current sip
>>> Use sipping@ietf.org for new = developments on the application of sip
>>>
>>
>> = _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the = core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for = questions on current sip
>> Use sipping@ietf.org for new developments = on the application of sip
>
>
> This message has been scanned for viruses by = MailControl -
> www.mailcontrol.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
>

--
Registered Office: Roke Manor Research Ltd, Siemens = House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any = attachments is confidential to
Roke Manor Research Ltd and must not be passed to = any third party without
permission. This communication is for information = only and shall not create or
change any contractual relationship.


For Aculab's privacy policy and E-Mail disclaimer, = Click Here : http://www.aculab.com/company/legal_notice.htm. =


------_=_NextPart_001_01C3EBBA.B165A960-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 5 02:51:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05838 for ; Thu, 5 Feb 2004 02:51:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeI3-0007ow-RR for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 02:51:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i157pBNj030041 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 02:51:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeHw-0007nI-L8; Thu, 05 Feb 2004 02:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeHn-0007mV-Hx for sip@optimus.ietf.org; Thu, 05 Feb 2004 02:50:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05806 for ; Thu, 5 Feb 2004 02:50:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoeHj-0006f4-00 for sip@ietf.org; Thu, 05 Feb 2004 02:50:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoeGj-0006Z7-00 for sip@ietf.org; Thu, 05 Feb 2004 02:49:49 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AoeG0-0006Om-00 for sip@ietf.org; Thu, 05 Feb 2004 02:49:04 -0500 Received: from dynamicsoft.com ([63.113.46.122]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i157mY9W015984; Thu, 5 Feb 2004 02:48:35 -0500 (EST) Message-ID: <4021F548.1070802@dynamicsoft.com> Date: Thu, 05 Feb 2004 02:48:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hiroaki Hata CC: vhegde@san.rr.com, drage@lucent.com, pkyzivat@cisco.com, Brian.Rosen@marconi.com, sip@ietf.org Subject: Re: [Sip] Session timer question References: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com> <001001c3b841$b5c99d60$2506c042@WXPvhegde> <3FD0E40A.7020008@dynamicsoft.com> <200402051452.BCE64762.BBIU@sphere.ad.jp> In-Reply-To: <200402051452.BCE64762.BBIU@sphere.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hiroaki Hata wrote: > Hi > Even if UAC does not support timer and ignores sesssion expires header > in a 2xx response, a session could be refreshed in case that UAC can response > a 2xx to re-INVITE from UAS. If UAC is not able to recongize a difference between > INVITE and re-INVITE and responds 4xx to the request of the refresh, a session > would be terminated. It depends just upon the implementation of UAC, doesn't it? Why would the caller reject the re-INVITE? > > PS.The table 2 Jonathan mentioned below is the Figure 3 in draft-13 but it is still > called table 3 in text page20. Thanks for pointing this out. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 5 03:07:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06184 for ; Thu, 5 Feb 2004 03:07:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeXX-0000L9-CE for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 03:07:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1587Arn001061 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 03:07:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeXO-0000Er-Bm; Thu, 05 Feb 2004 03:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeXE-0000Df-0E for sip@optimus.ietf.org; Thu, 05 Feb 2004 03:06:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06154 for ; Thu, 5 Feb 2004 03:06:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoeXA-0000Ds-00 for sip@ietf.org; Thu, 05 Feb 2004 03:06:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoeWE-00008M-00 for sip@ietf.org; Thu, 05 Feb 2004 03:05:51 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AoeVa-0007md-00 for sip@ietf.org; Thu, 05 Feb 2004 03:05:10 -0500 Received: from dynamicsoft.com ([63.113.46.122]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i157tI9W015990; Thu, 5 Feb 2004 02:55:23 -0500 (EST) Message-ID: <4021F6DD.9000607@dynamicsoft.com> Date: Thu, 05 Feb 2004 02:55:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Natesan Kannan CC: Christian Jansson , Paul Kyzivat , Jussi.Turunen@nokia.com, nataraju.alilaghatta@wipro.com, sanjsinh@cisco.com, sip@ietf.org Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request References: <401F4591.2040500@dynamicsoft.com> <004901c3ea24$576c1850$f504120a@in.huawei.com> In-Reply-To: <004901c3ea24$576c1850$f504120a@in.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Natesan Kannan wrote: > I will attempt a wild swing too... > Though we are talking of terminal mobility, it seems to me that this > mobility is restricted because of the fixed routeset in the dialog. > I can see that GRUU mapping to instance id, and the fact that GRUU can be > globally routed, paves a way for an un-restricted terminal mobility, just in > case nobody record-routed. > Was wondering if this could be of any use... It is true that the signaling path would be nailed down. This might be problematic for cases where a user roams into a totally different service provider, and that provider requires signaling to go through their signaling network in order for media to flow through their access network. In such a case, what makes sense is for the client to generate a totally new INVITE, and use Replaces to replace the dialog at the called party. The original dialog is then torn down. Lest people complain about billing implications, the replaces header would allow for sufficient correlation of the two dialogs to account for this as if it was still one single call. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 5 06:08:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11033 for ; Thu, 5 Feb 2004 06:08:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AohMs-0002le-F3 for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 06:08:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15B8MS0010637 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 06:08:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AohMX-0002jj-Rm; Thu, 05 Feb 2004 06:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AohMO-0002h0-Dt for sip@optimus.ietf.org; Thu, 05 Feb 2004 06:07:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11014 for ; Thu, 5 Feb 2004 06:07:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AohMK-0001Dw-00 for sip@ietf.org; Thu, 05 Feb 2004 06:07:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AohLO-00019B-00 for sip@ietf.org; Thu, 05 Feb 2004 06:06:50 -0500 Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 1AohKY-0000zv-00 for sip@ietf.org; Thu, 05 Feb 2004 06:05:58 -0500 Received: from mm-ismta4.bizmailsrvcs.net ([206.46.164.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040204220059.RXZH1593.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net> for ; Wed, 4 Feb 2004 16:00:59 -0600 Received: from khandewaler ([12.25.200.5]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040204220058.MZOC21479.mm-ismta4.bizmailsrvcs.net@khandewaler> for ; Wed, 4 Feb 2004 16:00:58 -0600 From: "Rajesh Khandewale" To: Date: Wed, 4 Feb 2004 14:00:59 -0800 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <40214A79.FABB16EE@alcatel.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Proxy behavior Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have a question about the proxy behavior under the following scenario, could someone please provide a clarification. 1. UAC sends an INVITE via proxy. 2. Proxy responds back with 100 trying message to UAC and forwards INVITE to UAS. 3. UAS sends 200 OK which is relayed by the proxy to UAC. 4. UAC sends an ACK which is being processed by the proxy to be forwarded to the UAS. ** Here ACK has sequence number 1 5. UAC sends another INVITE and incidentally this gets forwarded to the UAS before the ACK from previous INVITE by the proxy. ** Here INVITE has sequence number 2 6. Since UAS did not receive the ACK for previous INVITE (nor did it received CANCEL/BYE), but received another INVITE with same Call-ID etc. it throws a "500 Internal Server Error" error. According to RFC 3261, the UAS behavior to throw a "500 Internal Server Error" is correct. But I am not sure about the proxy behavior here, could not be clearly figured out of 3261. Is proxy supposed to correlate all the messages based on the sequence number and call-id and essentially send an ACK before sending out second INVITE. Or they are completely different transactions and this is a normal proxy behavior. Thanks, Rajesh. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 5 06:31:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11729 for ; Thu, 5 Feb 2004 06:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aohis-0003pk-Mk for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 06:31:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15BV6v5014677 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 06:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aohio-0003na-Hw; Thu, 05 Feb 2004 06:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aohho-0003kL-Fq for sip@optimus.ietf.org; Thu, 05 Feb 2004 06:30:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11669 for ; Thu, 5 Feb 2004 06:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aohhk-0003IY-00 for sip@ietf.org; Thu, 05 Feb 2004 06:29:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aohgx-0003Cg-00 for sip@ietf.org; Thu, 05 Feb 2004 06:29:08 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AohgP-00035h-00 for sip@ietf.org; Thu, 05 Feb 2004 06:28:33 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i15BS1322418 for ; Thu, 5 Feb 2004 05:28:02 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 5 Feb 2004 11:28:00 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EFD1@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" , "Conroy, Lawrence (SMTP)" Cc: Chris Boulton , Paul Kyzivat , Matthew.Gardiner@aculab.com, sip@ietf.org Subject: RE: [Sip] Call transfer using SIP Date: Thu, 5 Feb 2004 11:27:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Two points: - Standardisation of protocol by information flow is not a good idea. - The underlying IETF protocol standards (REFER etc) must be complied with, and with creation of a separate set of standards, this may well be bypassed. regards Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 04 February 2004 19:28 > To: Conroy, Lawrence (SMTP) > Cc: Chris Boulton; Paul Kyzivat; Matthew.Gardiner@aculab.com; > sip@ietf.org > Subject: Re: [Sip] Call transfer using SIP > > > Mathew asked: > > > Could somebody please confirm that if I am writing a call control > > application offering call hold and transfer then the definitive > > document to follow is draft-ietf-sipping-service-examples-05.txt? > > and Lawrence said: > > > Short answer is - yup - it would be a good idea, but not by > the IETF. > > So, I might ask, would it be worth encouraging our friends at > SIP Forum > to publish some "best practices" 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 exim@www1.ietf.org Thu Feb 5 09:44:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16780 for ; Thu, 5 Feb 2004 09:44:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokjM-00010t-6Q for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 09:43:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Ehmkx003896 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 09:43:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aokiy-0000uv-Ss; Thu, 05 Feb 2004 09:43:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aokhm-0000pi-P3 for sip@optimus.ietf.org; Thu, 05 Feb 2004 09:42:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16687 for ; Thu, 5 Feb 2004 09:41:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aokha-0005i3-00 for sip@ietf.org; Thu, 05 Feb 2004 09:41:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aokgn-0005bc-00 for sip@ietf.org; Thu, 05 Feb 2004 09:41:10 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1Aokfe-0005Pq-00 for sip@ietf.org; Thu, 05 Feb 2004 09:39:59 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15EdRv18856 for ; Thu, 5 Feb 2004 08:39:27 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMVY51S>; Thu, 5 Feb 2004 08:39:28 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF578FA4@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'sip@ietf.org'" Date: Thu, 5 Feb 2004 08:39:25 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] Optionality for History-Info Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I'm in the process of updating History Info (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-01.txt) based upon a few comments I've received and merging the requirements into the solution document. However, I really need more feedback from the working group to address the primary point raised during the discussion in Minneapolis on the optionality. Initial analysis way long ago resulted in the decision that Local Policy was the best approach to the optionality, since it didn't seem reasonable to use Require for an optional header and lack of the header should not prevent a basic request from being processed. However, a concern has been raised that Local Policy isn't sufficient as it requires coordination between clients and proxies (i.e. there's no aspect of the protocol that allows a client to define or discover that the Proxy will add the header). Supported, of course, is used to let the Proxy know that the information, if available, should be included in the responses. In taking a few steps back and re-evaluating all the possibilities for making the optionality more under the control of the protocol and I came up with the following list of possibilities. It may not be complete, nor are the list of pros and cons intended to be exhaustive, but I think it serves as a useful basis for discussion. 1) Use Require Pros: - Puts the use of the header explicitly under control of the client initiating the request. Cons: - Seems extremely restrictive and functionally limiting, although it would depend upon the application at the end client that wants to make use of the information as to how detrimental this might be. - Doesn't make sense since the applicability of History-Info isn't restricted to the initiator of the request. 2) Make use of the Request-Disposition header field as defined in the caller preferences draft to explicit request History-Info be included: history-directive Pros: - Consistent with the intent of that header in that it's a mechanism for a client to request how a server/proxy should handle a request Cons: - that field isn't extensible - doesn't really accomplish more than what can be implied by the Supported header (i.e. if the client wants the information in a response, then if a server is capable of adding the header, it SHOULD). 3) Make use of or define something similar to the Session specific policy, whereby the client "authorizes" a proxy to capture History-Info and that it's only captured in that case. Pros: - Explicit. Cons: - Seems like a lot of overhead, with little advantage. 4) Follow the approach of existing optional SIP headers added by intermediaries (e.g. Path and Reason), which is that it's purely a local policy decision and doesn't require any coordination with the UA as to whether it should or shouldn't be added. Pros: - It's fairly straightforward and consistent with the intent of optional headers. Cons: - Does require some guidelines to ensure that applications that might use the optional information are robust enough to handle the lack of information. Feedback on these proposals is appreciated and hopefully this discussion will allow us to reach a final, constructive conclusion. Obviously, my preference is the 4th option and perhaps one reason why we've gotten so stuck on this point is that the guidelines for applications on the usage of the header are perhaps not obvious. So, it might be useful to add an additional section to the document (or perhaps include additional information for each of the scenarios in the appendix) on application guidelines around the usage of the information and default behavior if the information is not available. Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 5 10:01:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17424 for ; Thu, 5 Feb 2004 10:01:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol0E-00039O-G6 for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 10:01:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15F1Eph012047 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 10:01:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol03-0002zq-ER; Thu, 05 Feb 2004 10:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aokz2-0002Qg-VK for sip@optimus.ietf.org; Thu, 05 Feb 2004 10:00:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17362 for ; Thu, 5 Feb 2004 09:59:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aokz0-0007WZ-00 for sip@ietf.org; Thu, 05 Feb 2004 09:59:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoky8-0007S4-00 for sip@ietf.org; Thu, 05 Feb 2004 09:59:05 -0500 Received: from eumail.aastra.com ([62.2.240.252] helo=solmail1.aastra.com) by ietf-mx with esmtp (Exim 4.12) id 1AokxM-0007HB-00 for sip@ietf.org; Thu, 05 Feb 2004 09:58:16 -0500 Received: from bilmail.aastra.com ([10.50.2.10]) by solmail1.aastra.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 15:52:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Feb 2004 09:52:26 -0500 Message-ID: Thread-Topic: [Sip] Optionality for History-Info Thread-Index: AcPr9dWPOopRQe/aTnWwYsuUIRbehwAAMNdw From: "Vijay Gaur" To: X-OriginalArrivalTime: 05 Feb 2004 14:52:28.0464 (UTC) FILETIME=[ACC66B00:01C3EBF7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Transport parameter in request URI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, My setup is like this: =20 UA1----->(TLS)----->Proxy------>(UDP)--->UA2 Here UA1 makes call and dialog gets established between UA1 and UA2. = Contact of UA2 contains transport parameter tls (Contact: = sip@ua1.com;transport=3Dtls). Now when UA2 generates BYE it doesn't put = any transport parameter in request URI (BYE sip:ua1.com SIP/2.0). = Because of no transport parameter BYE doesn't get 200OK. Now my question is which transport (TLS or UDP) UA2 should put in = request URI? RFC 3261 says that in request message agent should put transport = parameter in request URI with transport which it is using. If I put transport=3Dudp in request URI UA2 BYE doesn't get 200OK, but = in case of transport=3Dtls it works fine. I appreciate your help. Thanks, Vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 5 10:06:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17893 for ; Thu, 5 Feb 2004 10:06:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol4w-0005wu-6f for sip-archive@odin.ietf.org; Thu, 05 Feb 2004 10:06:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15F66YZ022833 for sip-archive@odin.ietf.org; Thu, 5 Feb 2004 10:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol4t-0005vA-J6; Thu, 05 Feb 2004 10:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol3v-0005f7-NP for sip@optimus.ietf.org; Thu, 05 Feb 2004 10:05:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17695 for ; Thu, 5 Feb 2004 10:05:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aol3t-0000B8-00 for sip@ietf.org; Thu, 05 Feb 2004 10:05:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aol2w-00005m-00 for sip@ietf.org; Thu, 05 Feb 2004 10:04:03 -0500 Received: from [216.94.98.67] (helo=conmail.aastra.com) by ietf-mx with esmtp (Exim 4.12) id 1Aol2e-00000F-00 for sip@ietf.org; Thu, 05 Feb 2004 10:03:44 -0500 Received: from bilmail.aastra.com ([10.50.2.10]) by conmail.aastra.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 09:58:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Transport parameter in request URI Date: Thu, 5 Feb 2004 09:58:03 -0500 Message-ID: Thread-Topic: [Sip] Optionality for History-Info Thread-Index: AcPr9dWPOopRQe/aTnWwYsuUIRbehwAAMNdwAAChV6A= From: "Vijay Gaur" To: X-OriginalArrivalTime: 05 Feb 2004 14:58:04.0361 (UTC) FILETIME=[74FC3B90:01C3EBF8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, My setup is like this: =20 UA1----->(TLS)----->Proxy------>(UDP)--->UA2 Here UA1 makes call and dialog gets established between UA1 and UA2. = Contact of UA1 contains transport parameter tls (Contact: = sip@ua1.com;transport=3Dtls). Now when UA2 generates BYE it doesn't put = any transport parameter in request URI (BYE sip:ua1.com SIP/2.0). = Because of no transport parameter BYE doesn't get 200OK. Now my question is which transport (TLS or UDP) UA2 should put in = request URI? RFC 3261 says that in request message agent should put transport = parameter in request URI with transport which it is using. If I put transport=3Dudp in request URI UA2 BYE doesn't get 200OK, but = in case of transport=3Dtls it works fine. I appreciate your help. Thanks, Vijay -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Vijay Gaur Sent: Thursday, February 05, 2004 9:52 AM To: sip@ietf.org Subject: [Sip] Transport parameter in request URI Hi, My setup is like this: =20 UA1----->(TLS)----->Proxy------>(UDP)--->UA2 Here UA1 makes call and dialog gets established between UA1 and UA2. = Contact of UA2 contains transport parameter tls (Contact: = sip@ua1.com;transport=3Dtls). Now when UA2 generates BYE it doesn't put = any transport parameter in request URI (BYE sip:ua1.com SIP/2.0). = Because of no transport parameter BYE doesn't get 200OK. Now my question is which transport (TLS or UDP) UA2 should put in = request URI? RFC 3261 says that in request message agent should put transport = parameter in request URI with transport which it is using. If I put transport=3Dudp in request URI UA2 BYE doesn't get 200OK, but = in case of transport=3Dtls it works fine. I appreciate your help. Thanks, 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 6 02:51:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15558 for ; Fri, 6 Feb 2004 02:51:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0lo-0005kI-Dm for sip-archive@odin.ietf.org; Fri, 06 Feb 2004 02:51:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i167pO4P022086 for sip-archive@odin.ietf.org; Fri, 6 Feb 2004 02:51:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0lT-0005fS-UK; Fri, 06 Feb 2004 02:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0kx-0005e5-Si for sip@optimus.ietf.org; Fri, 06 Feb 2004 02:50:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15542 for ; Fri, 6 Feb 2004 02:50:28 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0ku-0002Wx-00 for sip@ietf.org; Fri, 06 Feb 2004 02:50:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0jw-0002VH-00 for sip@ietf.org; Fri, 06 Feb 2004 02:49:29 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0jE-0002Tn-00 for sip@ietf.org; Fri, 06 Feb 2004 02:48:44 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i167miq23871 for ; Fri, 6 Feb 2004 09:48:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 6 Feb 2004 09:48:44 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 09:48:44 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3EC85.A4CA3E2C" Date: Fri, 6 Feb 2004 09:48:43 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797703@esebe019.ntc.nokia.com> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-khartabil-sip-auth-analysis-00.txt Thread-Index: AcPsKhNp9ZOL1VvRQZ63A6oiXkQS6wAW1ZAQ To: X-OriginalArrivalTime: 06 Feb 2004 07:48:44.0244 (UTC) FILETIME=[A52C1140:01C3EC85] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] FW: I-D ACTION:draft-khartabil-sip-auth-analysis-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EC85.A4CA3E2C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Having tried to implement HTTP Authentication for SIP, we faced a few = problems. This draft tries to highlight those problems and in some cases = suggests a solution. Please read and comment. Thanks, Hisham > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org]On Behalf Of ext > Internet-Drafts@ietf.org > Sent: 05.February.2004 22:42 > Subject: I-D ACTION:draft-khartabil-sip-auth-analysis-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Analysis: HTTP Authentication for SIP > Author(s) : H. Khartabil > Filename : draft-khartabil-sip-auth-analysis-00.txt > Pages : 9 > Date : 2004-2-5 > =09 > The Session Initiation Protocol (SIP) provides a stateless, > challenge-based mechanism for authentication that is based on > authentication in HTTP. RFC 3261 fails to indicate the behaviour of > SIP intermediaries and User Agents in certain scenarios. This > documents presents such scenarios, analysis the currently available > text, and where possible, offers a solution. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-khartabil-sip-auth-a nalysis-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-auth-analysis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-auth-analysis-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C3EC85.A4CA3E2C Content-Type: application/octet-stream; name="ATT502613.TXT" Content-Description: ATT502613.TXT Content-Disposition: attachment; filename="ATT502613.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDA0LTItNTE1NDk1Mi5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1raGFydGFiaWwtc2lwLWF1 dGgtYW5hbHlzaXMtMDAudHh0DQo= ------_=_NextPart_001_01C3EC85.A4CA3E2C Content-Type: application/octet-stream; name="draft-khartabil-sip-auth-analysis-00.URL" Content-Description: draft-khartabil-sip-auth-analysis-00.URL Content-Disposition: attachment; filename="draft-khartabil-sip-auth-analysis-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1raGFydGFiaWwtc2lwLWF1dGgtYW5hbHlzaXMtMDAudHh0DQo= ------_=_NextPart_001_01C3EC85.A4CA3E2C-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 6 02:58:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15819 for ; Fri, 6 Feb 2004 02:58:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0sh-0006ih-Il for sip-archive@odin.ietf.org; Fri, 06 Feb 2004 02:58:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i167wVXt025768 for sip-archive@odin.ietf.org; Fri, 6 Feb 2004 02:58:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0sE-0006VB-G4; Fri, 06 Feb 2004 02:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0rn-0006T9-S3 for sip@optimus.ietf.org; Fri, 06 Feb 2004 02:57:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15798 for ; Fri, 6 Feb 2004 02:57:32 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0rk-0002vP-00 for sip@ietf.org; Fri, 06 Feb 2004 02:57:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0qs-0002sW-00 for sip@ietf.org; Fri, 06 Feb 2004 02:56:38 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0q2-0002pN-00 for sip@ietf.org; Fri, 06 Feb 2004 02:55:46 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i167tkq04149 for ; Fri, 6 Feb 2004 09:55:46 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 6 Feb 2004 09:55:43 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 09:55:43 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2004 09:55:42 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797705@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Conference policy URI Thread-Index: AcPiJAx3RA9FNGizTkyVU/mXNnfJVQKYddSgAAAnywA= To: X-OriginalArrivalTime: 06 Feb 2004 07:55:43.0264 (UTC) FILETIME=[9EED7200:01C3EC86] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] FW: [Sipping] Conference policy URI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This will most likely be a SIP WG item. /Hisham > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 06.February.2004 09:52 > To: jdrosen@dynamicsoft.com > Cc: sipping@ietf.org > Subject: RE: [Sipping] Conference policy URI >=20 >=20 > Thanks Jonathan. A draft has been submitted to the SIP WG. >=20 > http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy > -uri-call-info-purpose-00.txt >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: 24.January.2004 04:44 > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > Cc: sipping@ietf.org > > Subject: Re: [Sipping] Conference policy URI > >=20 > >=20 > > I think this is a reasonable usage of Call-Info. However,=20 > it can only=20 > > be done if a "purpose" tag value is registered with IANA, as=20 > > indicated=20 > > by section 20.9. However, it ocurred to me, when reading=20 > > this, that we=20 > > never set up an IANA registry for call-info purpose tokens! Oops!=20 > > Thats easily rectifiable; when the draft defining the=20 > > 'policy-uri' (or=20 > > whatever its called) purpose tag is written, it should also=20 > > create the=20 > > registry and register the other tokens defined in rfc3261. > >=20 > > -Jonathan R. > >=20 > > hisham.khartabil@nokia.com wrote: > >=20 > > > Hi, > > >=20 > > > There was consensus on the XCON mailing list that the conference > > > state event package needs to include in the notification the > > > conference policy URI. > > >=20 > > > There was also consensus that some participants may not want to > > > subscribe to the conference package but would still like to learn > > > the conference policy URI. In this case, it was suggested that the > > > Call-info header carries such information. Perhaps the > > > cc-conferencing draft can include examples of that. > > >=20 > > > Thanks, Hisham > > >=20 > > > _______________________________________________ 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 > > >=20 > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > >=20 > >=20 >=20 > _______________________________________________ > 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 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 6 05:34:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19552 for ; Fri, 6 Feb 2004 05:34:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3Jf-0007wv-Pv for sip-archive@odin.ietf.org; Fri, 06 Feb 2004 05:34:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16AYVZ7030556 for sip-archive@odin.ietf.org; Fri, 6 Feb 2004 05:34:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3JB-0007vX-St; Fri, 06 Feb 2004 05:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3Ir-0007uk-5E for sip@optimus.ietf.org; Fri, 06 Feb 2004 05:33:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19508 for ; Fri, 6 Feb 2004 05:33:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3In-00022x-00 for sip@ietf.org; Fri, 06 Feb 2004 05:33:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap3Hr-00020H-00 for sip@ietf.org; Fri, 06 Feb 2004 05:32:40 -0500 Received: from 203-195-202-178.now-india.net.in ([203.195.202.178] helo=indiafire.intellinet-india.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap3H4-0001uI-00 for sip@ietf.org; Fri, 06 Feb 2004 05:31:51 -0500 Received: from sponge ([172.16.2.51]) by indiafire.intellinet-india.com (8.11.6/8.11.6) with SMTP id i16A8x423995; Fri, 6 Feb 2004 15:39:01 +0530 Message-ID: <0ab201c3ec9e$0be87f00$330210ac@india.internal.net> From: "Keshava Murthy" To: , Date: Fri, 6 Feb 2004 16:13:21 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AAF_01C3ECCC.241F9940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCUSE_16,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] Carrying TCAP over SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0AAF_01C3ECCC.241F9940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there any progres in this area? I dont see any discussions after = draft-miller-sip-tcap-00.txt released.. Thanks, K.S. Keshava Murthy Technical Architect IntelliNet Technologies Foundations for Global Networks Phone +91 80 5125 6018 x 147 Web www.intellinet-tech.com=20 Attachment: Information contained in this e-mail being proprietary to IntelliNet = Technologies is 'privileged' and 'confidential' and intended for use = only by the individual or entity to which it is addressed. If you are = not the intended recipient (or have received this e-mail in error) = please notify the sender immediately and destroy this e-mail. You are = notified that any use, copying, disclosure or dissemination of the = information contained in the e-mail in any manner whatsoever is strictly = prohibited. Please advise immediately if you or your employer does not = consent to Internet email for messages of this kind. Opinions, = conclusions and other information in this message that do not relate to = the official business of IntelliNet Technologies shall be understood as = neither given nor endorsed by it. IntelliNet Technologies India Pvt Ltd 413/4 Oxford Towers, 139 Airport Road Bangalore, KA - 560017, India Phone +91 80 5125 6018 Fax +91 80 520 2947 Web www.intellinet-tech.com=20 ------=_NextPart_000_0AAF_01C3ECCC.241F9940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is there any progres in this area? I = dont see any=20 discussions after draft-miller-sip-tcap-00.txt released..
 
Thanks,
K.S. Keshava Murthy
Technical=20 Architect
 
IntelliNet Technologies
Foundations = for Global=20 Networks
 
Phone +91 80 5125 6018 x = 147
Web www.intellinet-tech.com =
 
Attachment:
 
Information contained in this e-mail = being=20 proprietary to IntelliNet Technologies is 'privileged' and = 'confidential' and=20 intended for use only by the individual or entity to which it is = addressed. If=20 you are not the intended recipient (or have received this e-mail in = error)=20 please notify the sender immediately and destroy this e-mail. You are = notified=20 that any use, copying, disclosure or dissemination of the information = contained=20 in the e-mail in any manner whatsoever is strictly prohibited. Please = advise=20 immediately if you or your employer does not consent to Internet email = for=20 messages of this kind. Opinions, conclusions and other information in = this=20 message that do not relate to the official business of IntelliNet = Technologies=20 shall be understood as neither given nor endorsed by it.
 
IntelliNet Technologies India Pvt = Ltd
413/4=20 Oxford Towers, 139 Airport Road
Bangalore, KA - 560017,=20 India
Phone +91 80 5125 6018
Fax +91 80 520 = 2947
Web www.intellinet-tech.com=20
------=_NextPart_000_0AAF_01C3ECCC.241F9940-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 6 05:44:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19803 for ; Fri, 6 Feb 2004 05:44:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3T6-0000lM-Im for sip-archive@odin.ietf.org; Fri, 06 Feb 2004 05:44:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16AiGaR002865 for sip-archive@odin.ietf.org; Fri, 6 Feb 2004 05:44:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3Sr-0000i1-Mj; Fri, 06 Feb 2004 05:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNQs-00065H-Gd for sip@optimus.ietf.org; Wed, 04 Feb 2004 08:51:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05687 for ; Wed, 4 Feb 2004 08:51:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNQq-0005gx-00 for sip@ietf.org; Wed, 04 Feb 2004 08:51:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoNPx-0005ct-00 for sip@ietf.org; Wed, 04 Feb 2004 08:50:14 -0500 Received: from zdemail04.zdem.compaq.com ([161.114.112.28]) by ietf-mx with esmtp (Exim 4.12) id 1AoNPl-0005Y3-00 for sip@ietf.org; Wed, 04 Feb 2004 08:50:01 -0500 Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.86.63]) by zdemail04.zdem.compaq.com (Postfix) with ESMTP id 62D09E94 for ; Wed, 4 Feb 2004 14:49:25 +0100 (CET) Received: from rtoexc02.emea.cpqcorp.net ([16.41.86.56]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 4 Feb 2004 14:44:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB25.09995C82" Subject: [Sip] Some details in RFC 3398 Date: Wed, 4 Feb 2004 14:44:40 +0100 Message-ID: <67EBB9787FE159418BA12D0D8D44511141D552@rtoexc02.emea.cpqcorp.net> Thread-Topic: [Sip] Some details in RFC 3398 Thread-Index: AcOIyL9+jCtvRzYcTlug4wrHb8FycRiW1PjQ From: "El Moussawi, Ali" To: X-OriginalArrivalTime: 04 Feb 2004 13:44:40.0768 (UTC) FILETIME=[09D38400:01C3EB25] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EB25.09995C82 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have two tiny questions concerning RFC3398. In 7.1.6 , what do you think the cause code should be in the REL sent to the PSTN network after interwork tinmer expires ? =20 On the other hand, in 8.2.3, it says that upon receipt of a SIP 181 response, the gateway should send an early ACM to the PSTN side, plus a CPG with event code 6. What is the use of CPG since the other side will already know that its call is beying handled when it receives a early ACM ? Is the CPG mandatory ? Thanks a lot=20 ------_=_NextPart_001_01C3EB25.09995C82 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi all,

I have two tiny = questions=20 concerning RFC3398.

In  7.1.6 , what do you think the = cause code=20 should be in the REL sent to the PSTN network after interwork tinmer = expires=20 ?  

On=20 the other hand, in 8.2.3, it says that upon receipt of a SIP 181 = response,=20 the gateway should send an early ACM to the PSTN side, plus a = CPG with=20 event code 6. What is the use of CPG since the other side will already = know that=20 its call is beying handled when it receives a early ACM ? Is the CPG = mandatory=20 ?

Thanks a=20 lot 

=00 ------_=_NextPart_001_01C3EB25.09995C82-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 6 05:44:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19820 for ; Fri, 6 Feb 2004 05:44:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3T6-0000lL-IV for sip-archive@odin.ietf.org; Fri, 06 Feb 2004 05:44:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16AiGFn002862 for sip-archive@odin.ietf.org; Fri, 6 Feb 2004 05:44:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3St-0000j9-H2; Fri, 06 Feb 2004 05:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AodHm-00041S-Ez for sip@optimus.ietf.org; Thu, 05 Feb 2004 01:46:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21107 for ; Thu, 5 Feb 2004 01:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AodHj-00011L-00 for sip@ietf.org; Thu, 05 Feb 2004 01:46:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AodGi-0000wh-00 for sip@ietf.org; Thu, 05 Feb 2004 01:45:47 -0500 Received: from [194.185.97.20] (helo=gmoblmail2.net.vodafone.it) by ietf-mx with esmtp (Exim 4.12) id 1AodFu-0000n8-00 for sip@ietf.org; Thu, 05 Feb 2004 01:44:54 -0500 Received: from NUOVODELL (gmoboutz2.net.vodafone.it [194.185.97.56] (may be forged)) by gmoblmail2.net.vodafone.it (8.12.9-20030924/8.12.9) with ESMTP id i156hgFU017439 for ; Thu, 5 Feb 2004 07:43:56 +0100 Reply-To: From: "Marco Pissarello" To: Date: Thu, 5 Feb 2004 07:43:34 +0100 Organization: Agsm Telecomunicazioni Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040204170002.6306.36851.Mailman@www1.ietf.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=CLICK_BELOW, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Re: Contents of Sip digest Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ing. Marco Pissarello mobile: +39 3484786881 mobile: +39 3486090637 phone: +39 0454856103 mail: marco.pissarello@fastwebnet.it -----Messaggio originale----- Da: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Per conto di sip-request@ietf.org Inviato: mercoled=EC 4 febbraio 2004 18.00 A: sip@ietf.org Oggetto: Sip digest, Vol 1 #1250 - 9 msgs Send Sip mailing list submissions to sip@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/sip or, via email, send a message with subject or body 'help' to sip-request@ietf.org You can reach the person managing the list at sip-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Sip digest..." Today's Topics: 1. draft-ietf-sip-gruu-00 (Orit Levin) 2. Re: draft-ietf-sip-gruu-00 (Dean Willis) 3. Re: I-D ACTION:draft-ietf-sip-publish-02.txt (Jonathan Rosenberg) 4. Re: draft-ietf-sip-gruu-00 (Jonathan Rosenberg) 5. Call transfer using SIP (Matthew.Gardiner@aculab.com) 6. Re: Call transfer using SIP (Paul Kyzivat) 7. Re: Call transfer using SIP (Conroy, Lawrence (SMTP)) 8. RE: Call transfer using SIP (Matthew.Gardiner@aculab.com) 9. RE: Call transfer using SIP (Chris Boulton) --__--__-- Message: 1 Date: Tue, 3 Feb 2004 14:58:25 -0800 From: "Orit Levin" To: "Jonathan Rosenberg" , Subject: [Sip] draft-ietf-sip-gruu-00 I have the following remarks regarding the GRUU draft: 1. The draft states that one of the GRUU properties is =3D20 " o It MUST NOT be possible, based on inspection of the URI, to determine the associated Contact URI or Address of Record." It MUST be possible to achieve such a property for a GRUU (if the Registrar wants to enforce such a policy for its domain), but it is not part of the requirements for the GRUU concept to always enforce such a policy. 2. It is expressed throughout the draft that=3D20 "This extension allows a UA to obtain a GRUU, and to use a GRUU. These two mechanisms are separate, in that a UA can obtain a GRUU in any way it likes, and use the mechanisms in this specification to use them. Similarly, a UA can obtain a GRUU but never use it." For consistency, I suggest in section "6.2 Using the GRUU" change the first sentence from "A UA first obtains a GRUU using the procedures of Section 6.1." to=3D20 "A UA first obtains a GRUU using the procedures of Section 6.1 or by other means". Thanks, Orit. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Monday, February 02, 2004 10:54 PM To: Christian Jansson Cc: Paul Kyzivat; Jussi.Turunen@nokia.com; nataraju.alilaghatta@wipro.com; sanjsinh@cisco.com; sip@ietf.org Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and target refresh request Christian Jansson wrote: > Perhaps a little late, and hopefully not off topic. Comments inline. Not too late, not off topic. >=3D20 >=3D20 >>Jonathan R. wrote >>This, however, leads me into thinking a bit on the lifecycle >>management for GRUUs. Currently, GRUU is bound to a single=3D20 >>registration, where the registration is defined by the Contact URI. If >=3D20 >=3D20 >>the UA should "move", in the sense that it acquires a new IP = address,=3D20 >>this will be a new Contact URI, and therefore, a new GRUU. It would be >>nice if, instead, the GRUU were truly bound to the UA instance, = and=3D20 >>that even if the UA instance changed IP addresses, the GRUU could=3D20 >>remain unchanged. In such a case, if the UA moves, there is = actually=3D20 >>no need to issue any target refresh requests. The UA would simply=3D20 >>re-register, update the binding of its GRUU to its new IP=3D20 >>address, and=3D20 >>existing calls would be correctly routed. >=3D20 >=3D20 > But if the ip actually changes, it would be necessary to send an updated > SDP with the new ip in the c=3D3D line. Yes, that is true. If media relays are used (i.e., TURN), it might = be=3D20 possible to avoid even this, but lets leave that aside for now. > So your idea won't save you from > having to send a SIP request to the other end every time the ip changes > in an INVITE session.=3D20 Right. However, it does solve the problem that, previously, if both=3D20 endpoints moved at the same time, the call would fail - neither = side=3D20 could signal the other. > For a non-INVITE session though the idea would > save a lot of request from being sent if the session only contains > signaling. Right, in particular, a long lived presence subscription, for example. -Jonathan R. --=3D20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --__--__-- Message: 2 Date: Tue, 03 Feb 2004 17:58:47 -0600 From: Dean Willis To: Orit Levin , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-gruu-00 Orit Levin wrote: > I have the following remarks regarding the GRUU draft: >=20 > 1. The draft states that one of the GRUU properties is =20 > " o It MUST NOT be possible, based on inspection of the URI, to > determine the associated Contact URI or Address of Record." >=20 > It MUST be possible to achieve such a property for a GRUU (if the > Registrar wants to enforce such a policy for its domain), but it is = not > part of the requirements for the GRUU concept to always enforce such a > policy. I have to admit I concur with this position. There might be very useful=20 situations where the anonymity aspect of the GRUU would be undesirable. I can even envision models where the GRUU is cryptographically=20 validatable as representing an instance associated with a specific AOR,=20 including variations where the validation can or cannot be done without=20 prior knowledge of the associated AOR. As far as I can tell, reversibility does not impact the given rationale=20 for the requirements, that: With these rules, it is possible, though not required, to construct = a GRUU without requiring the maintenance of any additional state. To = do that, the URI would be constructed in the following fashion: So I believe I would support making this a SHOULD strength requirement.=20 Conceivably some discussion of the security implications of NOT meeting=20 this requirement would be appropriate. -- Dean --__--__-- Message: 3 Date: Wed, 04 Feb 2004 00:54:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft To: aki.niemi@nokia.com CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt aki.niemi@nokia.com wrote: > Hi Jonathan, >=20 > Thanks a lot for the excellent comments. Most of them I will directly > fold into -03. Few clarifications below. >=20 > Cheers, Aki >=20 > Jonathan Rosenberg wrote: >=20 > >=20 >> * section 3, paragraph 3: >>=20 >>> That is, the steady-state of this event package in the absence >>> of, or in addition >> to, soft state >>> provided through the PUBLISH mechanism >>=20 >> this makes it sound like steady state is a function of the event=20 >> packae only. the hard state is a function of the resource uRI and=20 >> event package. Indeed, one may think of an event package as merely >> sub-resource within the full resource. I wonder if it wouldn't be >> useful to come up with a term for this - for example, "scoped=20 >> resource" is a combination of a URI and event package, and=20 >> identifies a particular piece of event state. >=20 > I don't quite follow, but I agree the quoted text is rather vague. > To me the hard state, or "preconfigured" state is just another source > of event state to the composer. The mechanism to set that state might > be other than PUBLISH. Right. I agree with that. Let me try again. Requoting the paragraph: PUBLISH requests create soft state in the ESC. This state has a defined lifetime and will expire after a negotiated amount of time, requiring the publication to be refreshed by subsequent PUBLISH requests. Local policy at the compositor may in turn define hard state for a particular event package. That is, the steady-state of this event package in the absence of, or in addition to, soft state provided through the PUBLISH mechanism. Setting this hard state or configuring the composer policy is out of the scope of this specification. The words "hard state for a particular event package" read to me like it = meant that hard state was defined on a package by package basis. But,=20 its not. There would be hard state generally for a particular=20 URI/package basis. So, I'd suggest: There may also be hard state provisioned for each resource for a particular event package. This hard state represents the resource state that is present at all times, and does not expire. My other comment was that the concept of "for each resource for each=20 package" is a common concept, for which I was looking for a term to = define. >=20 > >=20 >> * section 5.1: >>=20 >>> As with any other SIP message, the PUBLISH mechanism MAY use the=20 >>> content indirection mechanism defined in [10]. >>=20 >> this statement makes [10] a normative reference, I believe. It is=20 >> listed as informative in the references section. >=20 > I'm not sure I agree. I've understood the RFC editor's policy so that > an informative reference is not required for implementing the RFC. > It's an interesting question as to how this relates to RFC 2119 > terminology. But I think a MAY makes the feature optional so that it > fits the informative reference definition. No - Keith is right in his note. Think of it this way - would the=20 feature interop if, one day, the referenced I-D evaporated and people=20 implemented it differently? In this case, no. If they chose to implement = the content indirection, and there was no spec, they would do it=20 differently and there would be no interop. I would just drop the text to avoid the dependency. >=20 > >=20 >> * section 5.3 is out of place. Section 5 is about generating=20 >> requests. the subsections for the most part deal with the specific >> 4 sub-cases you identified in 5.1. However, 5.3 talks about setting >> expirations, which is something that is actually done for the cases >> in 5.2, 5.4, 5.5 and 5.6. I would suggest that eaech of those four >> sections rather describe how the Expires header field is >> constructed for each case. That is consistent with having a column >> in table 1 on expires. Indeed, each section should also talk about >> bodies and etag. Along those lines, section 5.2 does not actually >> say that a body has to be present; it shouold be stated given the >> importance of this fact from table 1. >=20 > I think the reason for this is that I envisioned a PUBLISH carrying > state in some other place than the body. However, I don't know if > such a case would ever exist, and other people have also commented on > this. I think it is safe to assume that the state is always carried > in the body, as opposed to "typically". Yes. >> * the steps in section 6 omit handling for the case where there was >> no SIP-If-Match header field. step 6 says to check for it, and all >> the following steps assume it was there. I would suggest adding a >> bullet to step 6 which says, if there was no SIP-If-Match header >> field, the ESC creates a new etag, and associates it with as-yet >> empty event state. Processing continues in the steps below. This >> way, you always exit step 6 with an etag. >=20 > The attempt was to make etag generation part of step 9. This way, an > entity-tag is generated for each successful publication and returned > in 2xx, irrespective of whether the publication was an initial > publication, a refresh, or a modification. Indeed, a 2xx to a removal > could be treated the same, although such an entity-tag is useless at > that point. >=20 > So I think it is ok to exit step 6 without an entity tag, as long as > step 9 is clear that entity-tags are generated for all successful > publications. >=20 Step 8 requires an entity tag to be defined, however. >> * sectiton 11.1: >>=20 >>> Authentication issues are discussed in SIP [2]. The exact >> methods for >>> creation and manipulation of the ESC authorization policies are=20 >>> outside the scope of this document. >>=20 >> you will get dinged on this by Bellovin, guaranteed. He wants to >> see statements about baseline mandtory to implement mechahnisms.=20 >> Its fine to say that this mechanism is digest, as mandated by >> rfc3261. >>=20 >>> To prevent replay attacks, implementations SHOULD require=20 >>> authentication with anti-replay protection. >> Authentication issues are >>> discussed in SIP [2]. >>=20 >> as above.... does this mean digest with next-nonce or are you >> talking sips? >>=20 >> and section 11.4: >>=20 >>> To prevent such attacks, implementations SHOULD, at a minimum,=20 >>> provide integrity protection across the To, From, Event,=20 >>> SIP-If-Match, Route, and Expires headers and the bodies >> of PUBLISH >>> requests. >>=20 >> as above, he will ask for a mechanism. This requiurement makes the >> choice sips. >>=20 >> Same in 11.5. >=20 > I see what you are saying. But is it really so that each new method > that gets added to SIP needs to explicitly mandate certain security > mechanisms? At least going beyond the security considerations in RFC > 3261 seems unnecessary, since the properties of PUBLISH are very > similar to, say, REGISTER. I have made this same comment in past discussions of specs going through = iesg. However, the security ADs believe strongly in reptition of=20 security requirements in specifications. Trust me, you WILL get dinged=20 on this. It is much easier to just add text stating the same normative=20 requiremetns as in rfc3261, then to get a discuss during iesg = evaluation. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com --__--__-- Message: 4 Date: Wed, 04 Feb 2004 01:03:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft To: Dean Willis CC: Orit Levin , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-gruu-00 inline. Dean Willis wrote: > Orit Levin wrote: >=20 >> I have the following remarks regarding the GRUU draft: >> >> 1. The draft states that one of the GRUU properties is " o It MUST = >> NOT be possible, based on inspection of the URI, to >> determine the associated Contact URI or Address of Record." >> >> It MUST be possible to achieve such a property for a GRUU (if the >> Registrar wants to enforce such a policy for its domain), but it is = not >> part of the requirements for the GRUU concept to always enforce such = a >> policy. >=20 >=20 > I have to admit I concur with this position. There might be very = useful=20 > situations where the anonymity aspect of the GRUU would be = undesirable. >=20 > I can even envision models where the GRUU is cryptographically=20 > validatable as representing an instance associated with a specific = AOR,=20 > including variations where the validation can or cannot be done = without=20 > prior knowledge of the associated AOR. >=20 > As far as I can tell, reversibility does not impact the given = rationale=20 > for the requirements, that: >=20 > With these rules, it is possible, though not required, to construct = a > GRUU without requiring the maintenance of any additional state. To = do > that, the URI would be constructed in the following fashion: >=20 > So I believe I would support making this a SHOULD strength = requirement.=20 > Conceivably some discussion of the security implications of NOT = meeting=20 > this requirement would be appropriate. I am ok to lessen the requirement. The question becomes, do we want a way to allow the client to signal=20 that a randomized gruu is desired, or is it up to the server? I would=20 much prefer to leave it up to the server, in which case the only thing=20 that we need to change is the requirement, above. I changed the text to=20 read: In many cases, it will be desirable to construct the GRUU in such a way that it will not be possible, based on inspection of the URI, to determine the associated Contact URI or Address of Record. Whether or not a GRUU should be constructed with this property is a local policy decision of the administrator. Orit writes: > 2. It is expressed throughout the draft that=20 > "This extension allows a UA to obtain a GRUU, and to use a GRUU. These > two mechanisms are separate, in that a UA can obtain a GRUU in any way > it likes, and use the mechanisms in this specification to use them. > Similarly, a UA can obtain a GRUU but never use it." >=20 > For consistency, I suggest in section "6.2 Using the GRUU" change the > first sentence from >=20 > "A UA first obtains a GRUU using the procedures of Section 6.1." > to=20 > "A UA first obtains a GRUU using the procedures of Section 6.1 or = by > other means". OK, with the addition of "outside the scope of this specification.". -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com --__--__-- Message: 5 From: Matthew.Gardiner@aculab.com To: sip@ietf.org Date: Wed, 4 Feb 2004 10:04:49 -0000=20 Subject: [Sip] Call transfer using SIP 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. ------_=3D_NextPart_001_01C3EB06.531F57C0 Content-Type: text/plain; charset=3D"iso-8859-1" Could somebody please confirm that if I am writing a call control application offering call hold and transfer then the definitive document = to follow is draft-ietf-sipping-service-examples-05.txt? Matthew Gardiner Software Engineer Aculab=20 Tel: +44 (0) 1908 273 911 Fax: +44 (0) 1908 273 801 Email: mailto:matthew.gardiner@aculab.com Website: For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.=20 ------_=3D_NextPart_001_01C3EB06.531F57C0 Content-Type: text/html; charset=3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable Call transfer using SIP

Could somebody please confirm that = if =3D I am writing a call control application offering call hold and transfer = =3D then the definitive document to follow is =3D draft-ietf-sipping-service-examples-05.txt?

Matthew Gardiner
Software Engineer
Aculab
Tel: +44 (0) 1908 273 =3D 911
Fax: +44 (0) 1908 273 801
Email: mailto:matthew.gardiner@acu= l=3D ab.com
Website: <http://www.aculab.com>




For Aculab's privacy policy and = =3D E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm. = =3D


------_=3D_NextPart_001_01C3EB06.531F57C0-- --__--__-- Message: 6 Date: Wed, 04 Feb 2004 10:07:14 -0500 From: Paul Kyzivat To: Matthew.Gardiner@aculab.com CC: sip@ietf.org Subject: Re: [Sip] Call transfer using SIP Matthew.Gardiner@aculab.com wrote: > Could somebody please confirm that if I am writing a call control=20 > application offering call hold and transfer then the definitive = document=20 > to follow is draft-ietf-sipping-service-examples-05.txt? No. The *definitive* document is RFC3261 and related documents. The=20 details of call control are derivative from that in somewhat the same=20 way the much of physics is derivative from F=3DMA. Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an=20 *example*. It is not normative. However, that draft is certainly helpful and educational. You would do=20 well to understand what is in there before completing your task. Paul --__--__-- Message: 7 From: "Conroy, Lawrence (SMTP)" To: Paul Kyzivat Cc: Matthew.Gardiner@aculab.com, sip@ietf.org Subject: Re: [Sip] Call transfer using SIP Date: Wed, 4 Feb 2004 16:09:52 +0000 Hi folks, It's an interesting point. Paul's comment seems to be "there are many different ways of skinning a=20 cat, and the only normative definition is of the knife". The IETF defines the details of knife behaviour, and it's up to=20 everyone else to sort out how to use it for their purpose. My understanding is that the IETF (and the SIP WG in particular) will=20 not produce normative definitions of these (or any other) teleservices, only definitions of=20 protocol elements that might be used for these (or other) purposes. SIPPING will consider such services and decide on the protocol elements=20 they think are needed (that don't exist already) and then SIP grinds through the details. Thus the only teleservice examples are in the service-examples document=20 (collected together as a convenience), these are non-normative, and there will never BE=20 normative teleservice definitions produced by these groups. Is this correct? all the best, Lawrence On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote: > > > Matthew.Gardiner@aculab.com wrote: >> Could somebody please confirm that if I am writing a call control=20 >> application offering call hold and transfer then the definitive=20 >> document to follow is draft-ietf-sipping-service-examples-05.txt? > > No. The *definitive* document is RFC3261 and related documents. The=20 > details of call control are derivative from that in somewhat the same=20 > way the much of physics is derivative from F=3DMA. > > Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an=20 > *example*. It is not normative. > > However, that draft is certainly helpful and educational. You would do = > well to understand what is in there before completing your task. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --__--__-- Message: 8 From: Matthew.Gardiner@aculab.com To: lwc@roke.co.uk, pkyzivat@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] Call transfer using SIP Date: Wed, 4 Feb 2004 16:24:01 -0000=20 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. ------_=3D_NextPart_001_01C3EB3B.4C9F6C20 Content-Type: text/plain; charset=3D"iso-8859-1" This vagueness makes it very difficult to engineer a telephony solution which interoperates with other vendors equipment. In the telephony arena getting call transfer right is of fundamental importance. A simple = document titled "Call transfer in SIP" would suffice in de-mystifying this area. -----Original Message----- From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] Sent: 04 February 2004 16:10 To: Paul Kyzivat Cc: Matthew.Gardiner@aculab.com; sip@ietf.org Subject: Re: [Sip] Call transfer using SIP Hi folks, It's an interesting point. Paul's comment seems to be "there are many different ways of skinning a=20 cat, and the only normative definition is of the knife". The IETF defines the details of knife behaviour, and it's up to=20 everyone else to sort out how to use it for their purpose. My understanding is that the IETF (and the SIP WG in particular) will=20 not produce normative definitions of these (or any other) teleservices, only definitions of=20 protocol elements that might be used for these (or other) purposes. SIPPING will consider such services and decide on the protocol elements=20 they think are needed (that don't exist already) and then SIP grinds through the details. Thus the only teleservice examples are in the service-examples document=20 (collected together as a convenience), these are non-normative, and there will never BE=20 normative teleservice definitions produced by these groups. Is this correct? all the best, Lawrence On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote: > > > Matthew.Gardiner@aculab.com wrote: >> Could somebody please confirm that if I am writing a call control=20 >> application offering call hold and transfer then the definitive=20 >> document to follow is draft-ietf-sipping-service-examples-05.txt? > > No. The *definitive* document is RFC3261 and related documents. The=20 > details of call control are derivative from that in somewhat the same=20 > way the much of physics is derivative from F=3DMA. > > Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an=20 > *example*. It is not normative. > > However, that draft is certainly helpful and educational. You would do = > well to understand what is in there before completing your task. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --=20 Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is = confidential to Roke Manor Research Ltd and must not be passed to any third party = without permission. This communication is for information only and shall not = create or change any contractual relationship. For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.=20 ------_=3D_NextPart_001_01C3EB3B.4C9F6C20 Content-Type: text/html; charset=3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Call transfer using SIP

This vagueness makes it very difficult to engineer a = =3D telephony solution which interoperates with other vendors equipment. In = =3D the telephony arena getting call transfer right is of fundamental =3D importance. A simple document titled "Call transfer in SIP" = =3D would suffice in de-mystifying this area.

-----Original Message-----
From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk]
Sent: 04 February 2004 16:10
To: Paul Kyzivat
Cc: Matthew.Gardiner@aculab.com; = sip@ietf.org
Subject: Re: [Sip] Call transfer using SIP


Hi folks,
   It's an interesting point.
Paul's comment seems to be "there are many =3D different ways of skinning a
cat, and the
only normative definition is of the =3D knife".
The IETF defines the details of knife behaviour, = and =3D it's up to
everyone else to sort
out how to use it for their purpose.

My understanding is that the IETF (and the SIP WG in = =3D particular) will
not produce normative
definitions of these (or any other) teleservices, = =3D only definitions of
protocol elements that
might be used for these (or other) purposes.
SIPPING will consider such services and decide on = =3D the protocol elements
they think are needed
(that don't exist already) and then SIP grinds =3D through the details.

Thus the only teleservice examples are in the =3D service-examples document
(collected together
as a convenience), these are non-normative, and =3D there will never BE
normative teleservice
definitions produced by these groups. Is this =3D correct?

all the best,
   Lawrence

On 4 Feb 2004, at 3:07 pm, Paul Kyzivat = wrote:

>
>
> Matthew.Gardiner@aculab.com wrote:
>> Could somebody please confirm that if I am = =3D writing a call control
>> application offering call hold and = transfer =3D then the definitive
>> document to follow is =3D draft-ietf-sipping-service-examples-05.txt?
>
> No. The *definitive* document is RFC3261 and = =3D related documents. The
> details of call control are derivative from = =3D that in somewhat the same
> way the much of physics is derivative from =3D F=3D3DMA.
>
> Draft-ietf-sipping-service-examples-05.txt is = =3D (not surprisingly) an
> *example*. It is not normative.
>
> However, that draft is certainly helpful and = =3D educational. You would do
> well to understand what is in there before =3D completing your task.
>
>       Paul
>
>
> =3D _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip=
> This list is for NEW development of the core = =3D SIP Protocol
> Use sip-implementors@cs.columbia.edu for =3D questions on current sip
> Use sipping@ietf.org for new developments on = =3D the application of sip
>

--
Registered Office: Roke Manor Research Ltd, Siemens = =3D House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any =3D attachments is confidential to
Roke Manor Research Ltd and must not be passed to = =3D any third party without
permission. This communication is for information = =3D only and shall not create or
change any contractual relationship.


For Aculab's privacy policy and E-Mail = disclaimer, =3D Click Here : http://www.aculab.com/company/legal_notice.htm. = =3D


------_=3D_NextPart_001_01C3EB3B.4C9F6C20-- --__--__-- Message: 9 Subject: RE: [Sip] Call transfer using SIP Date: Wed, 4 Feb 2004 16:35:00 -0000 From: "Chris Boulton" To: "Conroy, Lawrence (SMTP)" , "Paul Kyzivat" Cc: , Lawrence - remember that SIP is a transport protocol which allows an objective to be reached in many differing ways. There is no correct behavior in many scenarios as long as they fall between the guidelines set out. It would be wrong to define normative behavior for such scenarios and so a push in the right direction towards preferred methods is the best approach. Chris. >-----Original Message----- >From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] >Sent: 04 February 2004 16:10 >To: Paul Kyzivat >Cc: Matthew.Gardiner@aculab.com; sip@ietf.org >Subject: Re: [Sip] Call transfer using SIP > >Hi folks, > It's an interesting point. >Paul's comment seems to be "there are many different ways of skinning a >cat, and the >only normative definition is of the knife". >The IETF defines the details of knife behaviour, and it's up to >everyone else to sort >out how to use it for their purpose. > >My understanding is that the IETF (and the SIP WG in particular) will >not produce normative >definitions of these (or any other) teleservices, only definitions of >protocol elements that >might be used for these (or other) purposes. >SIPPING will consider such services and decide on the protocol elements >they think are needed >(that don't exist already) and then SIP grinds through the details. > >Thus the only teleservice examples are in the service-examples document >(collected together >as a convenience), these are non-normative, and there will never BE >normative teleservice >definitions produced by these groups. Is this correct? > >all the best, > Lawrence > >On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote: > >> >> >> Matthew.Gardiner@aculab.com wrote: >>> Could somebody please confirm that if I am writing a call control >>> application offering call hold and transfer then the definitive >>> document to follow is draft-ietf-sipping-service-examples-05.txt? >> >> No. The *definitive* document is RFC3261 and related documents. The >> details of call control are derivative from that in somewhat the same >> way the much of physics is derivative from F=3D3DMA. >> >> Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an >> *example*. It is not normative. >> >> However, that draft is certainly helpful and educational. You would do >> well to understand what is in there before completing your task. >> >> Paul >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip This message has been scanned for viruses by MailControl - = www.mailcontrol.=3D 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 End of Sip Digest _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 6 06:14:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20702 for ; Fri, 6 Feb 2004 06:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3w0-0002zA-Cj for sip-archive@odin.ietf.org; Fri, 06 Feb 2004 06:14:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16BE8rc011447 for sip-archive@odin.ietf.org; Fri, 6 Feb 2004 06:14:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3vt-0002xE-Jr; Fri, 06 Feb 2004 06:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3vb-0002w7-0G for sip@optimus.ietf.org; Fri, 06 Feb 2004 06:13:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20665 for ; Fri, 6 Feb 2004 06:13:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3vX-00047G-00 for sip@ietf.org; Fri, 06 Feb 2004 06:13:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap3ud-00043K-00 for sip@ietf.org; Fri, 06 Feb 2004 06:12:44 -0500 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3u1-0003yC-00 for sip@ietf.org; Fri, 06 Feb 2004 06:12:06 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HSN00B01TOPBR@siemenscomms.co.uk> for sip@ietf.org; Fri, 06 Feb 2004 11:10:01 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HSN00A3ETLW9Q@siemenscomms.co.uk>; Fri, 06 Feb 2004 11:08:20 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 06 Feb 2004 11:12:57 +0000 Content-return: allowed Date: Fri, 06 Feb 2004 11:09:36 +0000 From: "Elwell, John" Subject: RE: [Sip] Optionality for History-Info To: "'Mary Barnes'" , "'sip@ietf.org'" Message-id: <50B1CBA96870A34799A506B2313F2667D4AB61@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Mary, I too am happy with option 4. Regards, John (john.elwell@siemens.com) > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] > Sent: 05 February 2004 14:39 > To: 'sip@ietf.org' > Subject: [Sip] Optionality for History-Info > > > I'm in the process of updating History Info > (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-in > fo-01.txt) > based upon a few comments I've received and merging the > requirements into > the solution document. However, I really need more feedback from the > working group to address the primary point raised during the > discussion in > Minneapolis on the optionality. Initial analysis way long > ago resulted in > the decision that Local Policy was the best approach to the > optionality, > since it didn't seem reasonable to use Require for an > optional header and > lack of the header should not prevent a basic request from > being processed. > However, a concern has been raised that Local Policy isn't > sufficient as it > requires coordination between clients and proxies (i.e. > there's no aspect of > the protocol that allows a client to define or discover that > the Proxy will > add the header). Supported, of course, is used to let the > Proxy know that > the information, if available, should be included in the responses. > > In taking a few steps back and re-evaluating all the possibilities for > making the optionality more under the control of the protocol > and I came up > with the following list of possibilities. It may not be > complete, nor are > the list of pros and cons intended to be exhaustive, but I > think it serves > as a useful basis for discussion. > > 1) Use Require > Pros: > - Puts the use of the header explicitly under control of the client > initiating the request. > > Cons: > - Seems extremely restrictive and functionally limiting, > although it would > depend upon the application at the end client that wants to > make use of the > information as to how detrimental this might be. > - Doesn't make sense since the applicability of History-Info isn't > restricted to the initiator of the request. > > > 2) Make use of the Request-Disposition header field as > defined in the caller > preferences draft to explicit request History-Info be included: > history-directive > > Pros: > - Consistent with the intent of that header in that it's a > mechanism for a > client to request how a server/proxy should handle a request > > Cons: > - that field isn't extensible > - doesn't really accomplish more than what can be implied by > the Supported > header (i.e. if the client wants the information in a > response, then if a > server is capable of adding the header, it SHOULD). > > 3) Make use of or define something similar to the Session > specific policy, > whereby the client "authorizes" a proxy to capture > History-Info and that > it's only captured in that case. > > Pros: > - Explicit. > > Cons: > - Seems like a lot of overhead, with little advantage. > > 4) Follow the approach of existing optional SIP headers added by > intermediaries (e.g. Path and Reason), which is that it's > purely a local > policy decision and doesn't require any coordination with the UA as to > whether it should or shouldn't be added. > > Pros: > - It's fairly straightforward and consistent with the intent > of optional > headers. > > Cons: > - Does require some guidelines to ensure that applications > that might use > the optional information are robust enough to handle the lack of > information. > > Feedback on these proposals is appreciated and hopefully this > discussion > will allow us to reach a final, constructive conclusion. > > Obviously, my preference is the 4th option and perhaps one > reason why we've > gotten so stuck on this point is that the guidelines for > applications on the > usage of the header are perhaps not obvious. So, it might be > useful to add > an additional section to the document (or perhaps include additional > information for each of the scenarios in the appendix) on application > guidelines around the usage of the information and default > behavior if the > information is not available. > > Regards, > Mary H. Barnes > mary.barnes@nortelnetworks.com > 972-684-5432 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Feb 7 20:19:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20370 for ; Sat, 7 Feb 2004 20:19:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apdba-0002SD-UV for sip-archive@odin.ietf.org; Sat, 07 Feb 2004 20:19:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i181JQ4Q009432 for sip-archive@odin.ietf.org; Sat, 7 Feb 2004 20:19:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApdbC-0002QK-5F; Sat, 07 Feb 2004 20:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApdaE-0002L9-03 for sip@optimus.ietf.org; Sat, 07 Feb 2004 20:18:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20322 for ; Sat, 7 Feb 2004 20:17:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApdaB-0001Me-00 for sip@ietf.org; Sat, 07 Feb 2004 20:17:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApdZc-0001FG-00 for sip@ietf.org; Sat, 07 Feb 2004 20:17:25 -0500 Received: from mailao.vtcif.telstra.com.au ([202.12.144.17]) by ietf-mx with esmtp (Exim 4.12) id 1ApdYL-0000pc-00 for sip@ietf.org; Sat, 07 Feb 2004 20:16:05 -0500 Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id A26B728B77 for ; Sun, 8 Feb 2004 12:15:25 +1100 (EST) Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 184FA22881 for ; Sun, 8 Feb 2004 12:15:25 +1100 (EST) Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA24417 for ; Sun, 8 Feb 2004 12:15:24 +1100 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sun, 8 Feb 2004 12:15:16 +1100 Message-ID: <1FD836F38652D211A63E0008C724434314CDC751@ntmsg0008.corpmail.telstra.com.au> Thread-Topic: SIP for controlling user to website interactions via http Thread-Index: AcPt4QT83bHRo9PkQburHzVJa0pPMQ== From: "Khare, Anir" To: Cc: "Khare, Anir" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] SIP for controlling user to website interactions via http Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I have a general query: Stateless HTTP protocol is currently used beyond its original purpose = i.e. ad-hoc access of information on web without any access-control = restrictions etc. Variety of techniques are used like cookies, http = redirects for mimicking user session with web site as well as for = identity management and SSO (Liberty). SIP seems to be a fit for streamlining majority of these issues around = user-web site http interactions. i.e. a scenario could be described as: = user opens a SIP session with web site, negotiates preferences etc. = using SDP. Then the session between user-website can consist of http, = RTP and other streaming protocols as necessary. SIP can be mediated by = the service provider/telcos (similar to telcos providing SIP based = signalling infrastructure for establishment of VoIP/MoIP services) for = establishing trust relationships between the user and the web-site, for = charging as well as for providing QoS for the transport of traffic in = the SIP session (using appropriate QoS signalling). Is SIP directly or indirectly used in this space? If not, was it = considered before and rejected? If rejected, what were the issues? Is there any other session control protocol under development for this = space? When Http used for SOAP in web services interactions, does the = notion of session gets formalised via any of the related web services = protocols?=20 Regards, Anir Khare Telstra Research Labs, Australia +61-3-6323 2659 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 8 22:01:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13673 for ; Sun, 8 Feb 2004 22:01:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1ey-0003dR-NX for sip-archive@odin.ietf.org; Sun, 08 Feb 2004 22:00:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1930W0N013909 for sip-archive@odin.ietf.org; Sun, 8 Feb 2004 22:00:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1eZ-0003YW-ML; Sun, 08 Feb 2004 22:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1eO-0003XS-N5 for sip@optimus.ietf.org; Sun, 08 Feb 2004 21:59:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13612 for ; Sun, 8 Feb 2004 21:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1eL-0005Xb-00 for sip@ietf.org; Sun, 08 Feb 2004 21:59:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq1dN-0005S3-00 for sip@ietf.org; Sun, 08 Feb 2004 21:58:54 -0500 Received: from mail.sphere.ad.jp ([210.150.250.130]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1cv-0005MV-00 for sip@ietf.org; Sun, 08 Feb 2004 21:58:25 -0500 Received: from HATA-5020 (p6161.nttpc.co.jp [210.136.166.161]) by mail.sphere.ad.jp (Postfix) with ESMTP id 6FA6B33A49; Mon, 9 Feb 2004 11:58:19 +0900 (JST) To: jdrosen@dynamicsoft.com, hata@sphere.ad.jp Cc: vhegde@san.rr.com, drage@lucent.com, pkyzivat@cisco.com, Brian.Rosen@marconi.com, sip@ietf.org Subject: Re: [Sip] Session timer question From: Hiroaki Hata References: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com> <001001c3b841$b5c99d60$2506c042@WXPvhegde> <3FD0E40A.7020008@dynamicsoft.com> <200402051452.BCE64762.BBIU@sphere.ad.jp> <4021F548.1070802@dynamicsoft.com> In-Reply-To: <4021F548.1070802@dynamicsoft.com> Message-Id: <200402091210.JBB39479.BIBU@sphere.ad.jp> X-Mailer: Winbiff without EditX [Version 2.42 PL6] X-Accept-Language: ja,en Date: Mon, 9 Feb 2004 12:10:07 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Jonathan I thought that a response to re-INVITE was a part of spec of session timer. That is independent on session timer specification. I understood the reason why the session timer works even if a peer doesn't support it. -- Hiro > > > Hiroaki Hata wrote: > > > Hi > > Even if UAC does not support timer and ignores sesssion expires header > > in a 2xx response, a session could be refreshed in case that UAC can response > > a 2xx to re-INVITE from UAS. If UAC is not able to recongize a difference between > > INVITE and re-INVITE and responds 4xx to the request of the refresh, a session > > would be terminated. It depends just upon the implementation of UAC, doesn't it? > > Why would the caller reject the re-INVITE? > > > > > PS.The table 2 Jonathan mentioned below is the Figure 3 in draft-13 but it is still > > called table 3 in text page20. > > Thanks for pointing this out. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 10 00:54:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17931 for ; Tue, 10 Feb 2004 00:54:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqQqi-0005MZ-PZ for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 00:54:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A5sKZ6020553 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 00:54:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqQqQ-0005JE-NP; Tue, 10 Feb 2004 00:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqQq6-0005Hw-OK for sip@optimus.ietf.org; Tue, 10 Feb 2004 00:53:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17899 for ; Tue, 10 Feb 2004 00:53:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqQq4-0001vD-00 for sip@ietf.org; Tue, 10 Feb 2004 00:53:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqQp7-0001pu-00 for sip@ietf.org; Tue, 10 Feb 2004 00:52:42 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AqQoU-0001kU-00 for sip@ietf.org; Tue, 10 Feb 2004 00:52:02 -0500 Received: from localhost (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id i1A5pvp28628; Tue, 10 Feb 2004 00:51:58 -0500 Subject: Re: [Sip] SIP for controlling user to website interactions via http From: Scott Lawrence To: "Khare, Anir" Cc: sip@ietf.org In-Reply-To: <1FD836F38652D211A63E0008C724434314CDC751@ntmsg0008.corpmail.telstra.com.au> References: <1FD836F38652D211A63E0008C724434314CDC751@ntmsg0008.corpmail.telstra.com.au> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Message-Id: <1076392317.3734.74.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 10 Feb 2004 00:51:57 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Sat, 2004-02-07 at 20:15, Khare, Anir wrote: > I have a general query: > > Stateless HTTP protocol is currently used beyond its original purpose i.e. ad-hoc access of information on web without any access-control restrictions etc. Variety of techniques are used like cookies, http redirects for mimicking user session with web site as well as for identity management and SSO (Liberty). > > SIP seems to be a fit for streamlining majority of these issues around user-web site http interactions. i.e. a scenario could be described as: user opens a SIP session with web site, negotiates preferences etc. using SDP. Then the session between user-website can consist of http, RTP and other streaming protocols as necessary. SIP can be mediated by the service provider/telcos (similar to telcos providing SIP based signalling infrastructure for establishment of VoIP/MoIP services) for establishing trust relationships between the user and the web-site, for charging as well as for providing QoS for the transport of traffic in the SIP session (using appropriate QoS signalling). SIP is no more suited to providing a session for those purposes than HTTP already is. -- Scott Lawrence Pingtel Corp. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 10 08:17:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15647 for ; Tue, 10 Feb 2004 08:17:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXlJ-0001tY-B7 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 08:17:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ADHD8S007222 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 08:17:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXl7-0001ru-Kv; Tue, 10 Feb 2004 08:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXkw-0001rU-Vz for sip@optimus.ietf.org; Tue, 10 Feb 2004 08:16:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15616 for ; Tue, 10 Feb 2004 08:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqXkv-00050r-00 for sip@ietf.org; Tue, 10 Feb 2004 08:16:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqXk0-0004vV-00 for sip@ietf.org; Tue, 10 Feb 2004 08:15:53 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AqXjW-0004qS-00 for sip@ietf.org; Tue, 10 Feb 2004 08:15:22 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2004 05:15:00 -0800 Received: from whoami.cisco.com (IDENT:mirapoint@whoami.cisco.com [64.101.128.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1ADEohu013100 for ; Tue, 10 Feb 2004 08:14:50 -0500 (EST) Received: from ARUNVENKW2K1 (rcdn-vpn-cluster-1-37.cisco.com [10.89.16.37]) by whoami.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADK27165; Tue, 10 Feb 2004 07:14:48 -0600 (CST) From: "arunvenk" To: Date: Tue, 10 Feb 2004 07:14:26 -0600 Message-ID: <000001c3efd7$cf0e16c0$0200a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Contact header on UPDATE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Moving to sip - no response on sip-implementors .... -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Arunachalam Venkatraman Sent: Friday, February 06, 2004 10:49 AM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Contact header on UPDATE RFC3311 - UPDATE Why is the Contact header mandatory on an UPDATE request? Why is the Contact header mandatory on a 2xx response to an UPDATE request? _______________________________________________ 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 exim@www1.ietf.org Tue Feb 10 15:11:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07219 for ; Tue, 10 Feb 2004 15:11:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeE7-0005NN-U0 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 15:11:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKBNr4020603 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 15:11:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeDn-0005FZ-2x; Tue, 10 Feb 2004 15:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeDH-00057Q-Mt for sip@optimus.ietf.org; Tue, 10 Feb 2004 15:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07006 for ; Tue, 10 Feb 2004 15:10:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeDE-0002Vh-00 for sip@ietf.org; Tue, 10 Feb 2004 15:10:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeC7-0002N7-00 for sip@ietf.org; Tue, 10 Feb 2004 15:09:20 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AqeBe-0002FV-00 for sip@ietf.org; Tue, 10 Feb 2004 15:08:50 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1AK8GNr002104; Tue, 10 Feb 2004 15:08:16 -0500 (EST) Message-ID: <40293A28.4070906@dynamicsoft.com> Date: Tue, 10 Feb 2004 15:08:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: arunvenk CC: sip@ietf.org Subject: Re: [Sip] Contact header on UPDATE References: <000001c3efd7$cf0e16c0$0200a8c0@amer.cisco.com> In-Reply-To: <000001c3efd7$cf0e16c0$0200a8c0@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit UPDATE is a target refresh request, which means it updates the remote target (i.e., the Contact). That means, like INVITE, it needs to contain a contact. Thanks, Jonathan R. arunvenk wrote: > Moving to sip - no response on sip-implementors .... > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > Arunachalam Venkatraman > Sent: Friday, February 06, 2004 10:49 AM > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Contact header on UPDATE > > RFC3311 - UPDATE > Why is the Contact header mandatory on an UPDATE request? > > Why is the Contact header mandatory on a 2xx response to an UPDATE > request? > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 10 15:22:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09173 for ; Tue, 10 Feb 2004 15:22:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeOX-0000tL-UY for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 15:22:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKM92A003182 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 15:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeOQ-0000kQ-I2; Tue, 10 Feb 2004 15:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeNm-0000Ql-KP for sip@optimus.ietf.org; Tue, 10 Feb 2004 15:21:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08601 for ; Tue, 10 Feb 2004 15:21:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeNl-00044E-00 for sip@ietf.org; Tue, 10 Feb 2004 15:21:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeMp-0003wq-00 for sip@ietf.org; Tue, 10 Feb 2004 15:20:24 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AqeM1-0003ie-00 for sip@ietf.org; Tue, 10 Feb 2004 15:19:33 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 10 Feb 2004 12:17:57 -0800 Received: from whoami.cisco.com (IDENT:mirapoint@whoami.cisco.com [64.101.128.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1AKJ1hu016290; Tue, 10 Feb 2004 15:19:01 -0500 (EST) Received: from ARUNVENKW2Kl (arunvenk-w2kl.cisco.com [64.101.150.225]) by whoami.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ADK38910; Tue, 10 Feb 2004 14:19:00 -0600 (CST) From: "Arunachalam Venkatraman" To: "Jonathan Rosenberg" Cc: Subject: RE: [Sip] Contact header on UPDATE Date: Tue, 10 Feb 2004 14:19:00 -0600 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: <40293A28.4070906@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Since INVITE establishes the target information, it is clear why it is mandatory on the INVITE. In subsequent rerquests withina dialog, the Contact need not be mandatory. If the remote traget is to be changed, then the Contact must be specified, otherwise not. What is broken if UPDATE does not have a Contact? What functionality is lost? My understanding for making Contact mandatory on a re-INVITE, was to avoid making re-INVITE any different from an INVITE. It is not a terribly onerous thing to provide Conatct on an UPDATE (and its 200), but I wish to understand what is achieved by doing it and what is lost by not doing it. Regards, Venkat -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, February 10, 2004 2:08 PM To: arunvenk Cc: sip@ietf.org Subject: Re: [Sip] Contact header on UPDATE UPDATE is a target refresh request, which means it updates the remote target (i.e., the Contact). That means, like INVITE, it needs to contain a contact. Thanks, Jonathan R. arunvenk wrote: > Moving to sip - no response on sip-implementors .... > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > Arunachalam Venkatraman > Sent: Friday, February 06, 2004 10:49 AM > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Contact header on UPDATE > > RFC3311 - UPDATE > Why is the Contact header mandatory on an UPDATE request? > > Why is the Contact header mandatory on a 2xx response to an UPDATE > request? > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 10 15:38:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12486 for ; Tue, 10 Feb 2004 15:38:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqee5-0002xO-8o for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 15:38:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKcDOX011365 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 15:38:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqedu-0002tT-JB; Tue, 10 Feb 2004 15:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqed0-0002jR-9K for sip@optimus.ietf.org; Tue, 10 Feb 2004 15:37:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12457 for ; Tue, 10 Feb 2004 15:37:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqecy-0005PR-00 for sip@ietf.org; Tue, 10 Feb 2004 15:37:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqec5-0005Kl-00 for sip@ietf.org; Tue, 10 Feb 2004 15:36:10 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqebm-0005FF-00 for sip@ietf.org; Tue, 10 Feb 2004 15:35:50 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1AKZENr002127; Tue, 10 Feb 2004 15:35:15 -0500 (EST) Message-ID: <4029407A.5060003@dynamicsoft.com> Date: Tue, 10 Feb 2004 15:35:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hiroaki Hata CC: vhegde@san.rr.com, drage@lucent.com, pkyzivat@cisco.com, Brian.Rosen@marconi.com, sip@ietf.org Subject: Re: [Sip] Session timer question References: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com> <001001c3b841$b5c99d60$2506c042@WXPvhegde> <3FD0E40A.7020008@dynamicsoft.com> <200402051452.BCE64762.BBIU@sphere.ad.jp> <4021F548.1070802@dynamicsoft.com> <200402091210.JBB39479.BIBU@sphere.ad.jp> In-Reply-To: <200402091210.JBB39479.BIBU@sphere.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hiroaki Hata wrote: > Jonathan > I thought that a response to re-INVITE was a part of spec of session timer. re-INVITEs are part of rfc3261. Thus, an rfc3261 compliant UA will respond to a reinvite, and it shouldn't reject it for no reason. -Jonathan R. > >> >>Hiroaki Hata wrote: >> >> >>>Hi >>>Even if UAC does not support timer and ignores sesssion expires header >>>in a 2xx response, a session could be refreshed in case that UAC can response >>>a 2xx to re-INVITE from UAS. If UAC is not able to recongize a difference between >>>INVITE and re-INVITE and responds 4xx to the request of the refresh, a session >>>would be terminated. It depends just upon the implementation of UAC, doesn't it? >> >>Why would the caller reject the re-INVITE? >> >> >>>PS.The table 2 Jonathan mentioned below is the Figure 3 in draft-13 but it is still >>>called table 3 in text page20. >> >>Thanks for pointing this out. >> >>-Jonathan R. >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 10 16:06:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15243 for ; Tue, 10 Feb 2004 16:06:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf5Q-0005MI-Lk for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 16:06:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AL6SfU020597 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 16:06:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf51-0005Ew-2R; Tue, 10 Feb 2004 16:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf49-0005DK-Hr for sip@optimus.ietf.org; Tue, 10 Feb 2004 16:05:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14939 for ; Tue, 10 Feb 2004 16:05:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf47-0000yB-00 for sip@ietf.org; Tue, 10 Feb 2004 16:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf39-0000s3-00 for sip@ietf.org; Tue, 10 Feb 2004 16:04:08 -0500 Received: from [63.126.135.16] (helo=mail1.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqf2L-0000hq-00 for sip@ietf.org; Tue, 10 Feb 2004 16:03:17 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i1AKRTTl023044 for ; Tue, 10 Feb 2004 12:27:31 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Feb 2004 12:27:29 -0800 Message-ID: <017B1BB60535DF4285666089FA048AC20172EFDA@SONOMA.netscreen.com> From: Anil Bollineni To: "'sip@ietf.org'" Date: Tue, 10 Feb 2004 12:27:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F014.4A72DE40" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] CallId question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This 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_01C3F014.4A72DE40 Content-Type: text/plain Hello, I have a question about CallId. Suppose two UA's generate callid's putting theire hostnames and send to firewall/NAT. UA1:INVITE CallID: call1@192.10.10.10 UA2: INVITE CallId: call1@192.10.10.12 Because those callid information contain IP addresses, the firewall/NAT should translate these IP addresses by putting it's own IP in callId. The callId's are changed to call1@firewall_ip, call1@firewall_ip. When responses come back from their respective UAS's the firewall/NAT translates the it's IP address in callId's to their original IP's. My question is should I change the string "call1" to something generated by firewall or Is it OK to leave like that. Even though they have same CallId, the proxy should discriminate the calls by from-tag, callid, and to-tag. According to Spec, any UA should have a different means of generating callid's with those of other UA's. Anything to do correctly to the above procedure? Thanks in advance, Anil This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. ------_=_NextPart_001_01C3F014.4A72DE40 Content-Type: text/html

Hello,

 

            I have a question about CallId. Suppose two UA's generate callid's putting theire hostnames and send to firewall/NAT.

            UA1:INVITE

                  CallID: call1@192.10.10.10

            UA2: INVITE

                     CallId: call1@192.10.10.12

           

            Because those callid information contain IP addresses, the firewall/NAT should translate these IP addresses by putting it's own IP in callId. The callId's are changed to call1@firewall_ip, call1@firewall_ip. When responses come back from their respective UAS's the firewall/NAT translates the it's IP address in callId's to their original IP's. My question is should I change the string "call1" to something generated by firewall or Is it OK to leave like that. Even though they have same CallId, the proxy should discriminate the calls by from-tag, callid, and to-tag.

According to Spec, any UA should have a different means of generating callid's with those of other UA's.

 

Anything to do correctly to the above procedure?

 

Thanks in advance,

Anil

This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information.

 

------_=_NextPart_001_01C3F014.4A72DE40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 10 16:19:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17560 for ; Tue, 10 Feb 2004 16:19:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfHn-0007t3-66 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 16:19:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALJFrg030255 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 16:19:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfHa-0007la-1k; Tue, 10 Feb 2004 16:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfH0-0007im-5C for sip@optimus.ietf.org; Tue, 10 Feb 2004 16:18:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17320 for ; Tue, 10 Feb 2004 16:18:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfGy-0003bN-00 for sip@ietf.org; Tue, 10 Feb 2004 16:18:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfFT-0003EH-00 for sip@ietf.org; Tue, 10 Feb 2004 16:16:52 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1AqfDn-0002oC-00 for sip@ietf.org; Tue, 10 Feb 2004 16:15:07 -0500 Received: from sip (pD9E1033B.dip.t-dialin.net [217.225.3.59]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1ALEx2T009065; Tue, 10 Feb 2004 22:15:00 +0100 (MET) From: "Christian Stredicke" To: "'Anil Bollineni'" Cc: Subject: RE: [Sip] CallId question Date: Tue, 10 Feb 2004 22:15:00 +0100 Message-ID: <037f01c3f01a$f1f2c120$0a02a8c0@sip> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0380_01C3F023.53B72920" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <017B1BB60535DF4285666089FA048AC20172EFDA@SONOMA.netscreen.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0380_01C3F023.53B72920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable :-) That's the reason why we started to AVOID IP addresses in the call = ID!!! =20 Well I guess the firewall which is changing the Call-ID is a half-way implementation of an application layer firewall. What it is doing is = simply junk and it's a miracle if it's working with any SIP compliant devices. =20 The "call1" part should be significantly random to avoid using the same call-ID. That's why most of the user agents chose a call ID that is random-generated. =20 Christian =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Anil Bollineni Sent: Tuesday, February 10, 2004 9:27 PM To: 'sip@ietf.org' Subject: [Sip] CallId question =20 Hello, =20 I have a question about CallId. Suppose two UA's generate callid's putting theire hostnames and send to firewall/NAT. UA1:INVITE CallID: call1@192.10.10.10 UA2: INVITE CallId: call1@192.10.10.12 =20 Because those callid information contain IP addresses, the firewall/NAT should translate these IP addresses by putting it's own IP = in callId. The callId's are changed to call1@firewall_ip, = call1@firewall_ip. When responses come back from their respective UAS's the firewall/NAT translates the it's IP address in callId's to their original IP's. My question is should I change the string "call1" to something generated by firewall or Is it OK to leave like that. Even though they have same = CallId, the proxy should discriminate the calls by from-tag, callid, and to-tag. According to Spec, any UA should have a different means of generating callid's with those of other UA's.=20 =20 Anything to do correctly to the above procedure? =20 Thanks in advance, Anil This email contains material that is confidential. The content of this = email is for the sole use of the intended recipient(s). Any review or = distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If = you are not the intended recipient, please contact the sender and = delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. =20 ------=_NextPart_000_0380_01C3F023.53B72920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

:-) = That’s the reason why we started to AVOID IP addresses in the call = ID!!!

 

Well I guess = the firewall which is changing the Call-ID is a half-way implementation of = an application layer firewall. What it is doing is simply junk and = it’s a miracle if it’s working with any SIP compliant devices.

 

The = “call1” part should be significantly random to avoid using the same call-ID. = That’s why most of the user agents chose a call ID that is = random-generated.

 

Christian

 

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of Anil Bollineni
Sent: Tuesday, February = 10, 2004 9:27 PM
To: 'sip@ietf.org<= font size=3D2 face=3DTahoma>'
Subject: [Sip] CallId = question

 

Hello,

 

        = ;    I have a question about CallId. Suppose two UA's generate callid's = putting theire hostnames and send to firewall/NAT.

        = ;    UA1:INVITE

        = ;          CallID: call1@192.10.10.10

        = ;    UA2: INVITE

        = ;             CallId: call1@192.10.10.12

        = ;   

        = ;    Because those callid information contain IP addresses, the firewall/NAT = should translate these IP addresses by putting it's own IP in callId. The = callId's are changed to call1@firewall_ip, call1@firewall_ip. When responses come = back from their respective UAS's the firewall/NAT translates the it's IP address = in callId's to their original IP's. My question is should I change the = string "call1" to something generated by firewall or Is it OK to = leave like that. Even though they have same CallId, the proxy should discriminate = the calls by from-tag, callid, and to-tag.

According to Spec, any UA should have a = different means of generating callid's with those of other UA's. =

 

Anything to do correctly to the above = procedure?

 

Thanks in advance,

Anil

This email contains material that is confidential. The content of = this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly = prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. = NetScreen does not guarantee the accuracy or completeness of third party materials = or information.

 

------=_NextPart_000_0380_01C3F023.53B72920-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 10 16:32:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19088 for ; Tue, 10 Feb 2004 16:32:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfUR-0000ja-8U for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 16:32:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALWJDc002760 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 16:32:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfUA-0000gi-BM; Tue, 10 Feb 2004 16:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfTN-0000bK-Q7 for sip@optimus.ietf.org; Tue, 10 Feb 2004 16:31:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18923 for ; Tue, 10 Feb 2004 16:31:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfTL-000624-00 for sip@ietf.org; Tue, 10 Feb 2004 16:31:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfRK-0005TI-00 for sip@ietf.org; Tue, 10 Feb 2004 16:29:08 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AqfOg-0004qO-00 for sip@ietf.org; Tue, 10 Feb 2004 16:26:22 -0500 Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1ALPsNr002164; Tue, 10 Feb 2004 16:25:54 -0500 (EST) Message-ID: <40294C5A.1070205@dynamicsoft.com> Date: Tue, 10 Feb 2004 16:25:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] Questions on draft-ietf-sip-session-timer-13 and refresh timers References: <1074885187.20359.276.camel@bdsl.greycouncil.com> In-Reply-To: <1074885187.20359.276.camel@bdsl.greycouncil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Dean Willis wrote: > I'me reviewing some IESG comments on this draft, and I've found > something I don't understand. > > The original comment from Ted was something like "Why do we recommend > refresh at 1/2 the session timer in sections 7 and 8, but require a BYE > at a recommended 1/3St-10s in section 10?" > > I understand why we require refresh, and why we suggested refreshing at > 1/2 of the session timer value. What I don't understand is the BYE logic > in Section 10. > > >>From Section 10: > > If no 2xx response to a session refresh request is received before > the session expiration, the UA SHOULD send a BYE request to terminate > the session. It SHOULD send this BYE slightly before session > expiration. The minimum of ten seconds and one third the session > interval is RECOMMENDED. > > For example, if the session interval is 120 seconds, one third of > this is 40 seconds. Since the minimum of 10 seconds and 40 seconds > is 10 seconds, the BYE would be sent 10 seconds before the session > expires. > > > I read this as: > > A UA has issues a session refresh request, and is waiting around for > that transaction to complete. Unfortunately, it either 1) didn't issue > the request sufficiently early for the transaction to complete before > the session is going to expire, so it needs to abandon the refreshing > transaction and terminate the session before the session expires, > or 2) the session refresh request failed, but we're going to continue to > use this session for a while before tearing it down before it expires. > > It seems more reasonable that the UA should issue the session refresh > request far enough in advance of session expiration that the session > refresh request will complete (or fail with timeout) before the session > expires, and that if the session refresh request fails, the UA should > immediately terminate the session with a BYE. I am inclined to agree with this. I honestly cannot remember why we chose {1/3,10s}. Indeed, this rule actually contradicts RFC3261! From section 12.2.1.2: 12.2.1.2 Processing the Responses The UAC will receive responses to the request from the transaction layer. If the client transaction returns a timeout, this is treated as a 408 (Request Timeout) response. The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if the request had been sent outside a dialog. This behavior is described in Section 8.1.3.4. Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the Route header of the request. When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present. Rosenberg, et. al. Standards Track [Page 75] RFC 3261 SIP: Session Initiation Protocol June 2002 If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if no response at all is received for the request (the client transaction would inform the TU about the timeout.) In other words, it recommends exactly the behavior you are describing - on transaction timeout, terminate the dialog. > > This implies that the lowest allowable threshold for the negotiated > session timer should be larger than the largest timeout value for a > session refresh request (which could be an INVITE transaction). It also > may place requirements on UAs that have implemented non-standard timer > values to calculate this lowest allowable threshold for the negotiated > session timer value and include this calculated value in their > negotiation by initializing the Min-SE value. I think the spec should state that no entity can request a session timer below 1 minute. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 10 21:14:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12861 for ; Tue, 10 Feb 2004 21:14:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqjtF-00008M-65 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 21:14:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B2EDoW000452 for sip-archive@odin.ietf.org; Tue, 10 Feb 2004 21:14:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqjt4-00006A-4e; Tue, 10 Feb 2004 21:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqjsW-0008Pm-HT for sip@optimus.ietf.org; Tue, 10 Feb 2004 21:13:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12813 for ; Tue, 10 Feb 2004 21:13:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqjsT-0007HN-00 for sip@ietf.org; Tue, 10 Feb 2004 21:13:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqjrX-0007Au-00 for sip@ietf.org; Tue, 10 Feb 2004 21:12:27 -0500 Received: from law11-oe45.law11.hotmail.com ([64.4.16.17] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqjr2-00073i-00 for sip@ietf.org; Tue, 10 Feb 2004 21:11:56 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Feb 2004 18:11:26 -0800 Received: from 218.246.32.76 by law11-oe45.law11.hotmail.com with DAV; Wed, 11 Feb 2004 02:11:26 +0000 X-Originating-IP: [218.246.32.76] X-Originating-Email: [embedsong@hotmail.com] X-Sender: embedsong@hotmail.com From: "jack zhao" To: Date: Tue, 25 Mar 2003 10:12:38 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C2F2B7.104B9140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 11 Feb 2004 02:11:26.0383 (UTC) FILETIME=[5A884BF0:01C3F044] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,DATE_IN_PAST_96_XX, FORGED_OUTLOOK_TAGS,MIME_BASE64_TEXT autolearn=no version=2.60 Subject: [Sip] about call waiting using SUBSCRIBE/NOTIFY! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C2F2B7.104B9140 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldoYXQgSSBleHBlY3QgaXMgbGlrZSB0aGlzOg0KQXNzdW1lOiBUaGVyZSBh cmUgMiBVQXMsIEEgYW5kIEIuDQoNCjEuIEEgaXMgYnVzeSwgKEluIElQMjAwNiwgdGhhdCBtZWFu cyBib3RoIDIgbGluZXMgaGFzIGEgY29ubmVjdGlvbiB3aXRoIHNvbWVib2R5KQ0KMi4gQiBjYWxs IEEgYW5kIGdvdCBhIDQ4NiBCVVNZIHJlcGx5Lg0KMy4gQiBkZWNpZGUgdG8gd2FpdCBmb3IgQS4g QiBzZW5kIGEgU1VCU0NSSUJFIHRvIEEgYW5kIGhhbmcgdXAuIA0KNC4gQWZ0ZXIgY2VydGFpbiBw ZXJpb2Qgb2YgdGltZSwgQSBmaW5hbGx5IGNsb3NlIG9uZSBvZiBpdCdzIGNvbm5lY3Rpb24gYW5k IGhhcyBhIGZyZWUNCiAgICBsaW5lLiANCjUuIEEgc2VuZCBhIE5PVElGWSB0byBCIGluZGljYXRl IHRoYXQgaGUgaXMgZnJlZSB0byBhY2NlcHQgY29ubmVjdGlvbi4NCjYuIEIgcmVjZWl2ZSB0aGlz IE5PVElGWSBhbmQgc3RhcnQgdG8gcmluZy4gQiBVTlNVQlNDUklCRSB0aGUgZXZlbnQgYWxzby4N CjcuIEFmdGVyIHVzZXIgcGlja3VwIEIsIEIgc2VuZCBhIElOVklURSB0byBBIHRyeSB0byBlc3Rh Ymxpc2ggYSBjb25uZWN0aW9uLg0KOC4gQSBzdGFydCByaW5naW5nIHdoZW4gaXQgcmVjZWl2ZSBJ TlZJVEUuIEZyb20gbm93IG9uLCBpdCBpcyB0aGUgc2FtZSBhcyB0aGUNCiAgICByZWd1bGFyIGNh bGwgb3V0Lg0KDQpJZiB5b3UgaGF2ZSBnb3QgdGhlIElFVEYgZHJhZnQgb3IgUkZDIGFib3V0IGNh bGwtd2FpdGluZyBwbGVhc2UgdGVsbCBtZSBvciBzZW5kIGl0IHRvIG1lLg0KDQpCZXN0IFJlZ2Fy ZHMsDQpqYWNrIHpoYW8= ------=_NextPart_000_002D_01C2F2B7.104B9140 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjEyNzYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkRl YXIgYWxsLDwvRk9OVD48L0RJVj4NCjxESVY+DQo8RElWPjxGT05UIGZhY2U90MK8msP383cgY29s b3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFzcz01NDYzNTU1MDEtMTAwMjIwMDQ+PC9TUEFO PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3Qwryaw/fzdyBjb2xvcj0jMDAw MGZmIHNpemU9Mj48U1BBTiBjbGFzcz01NDYzNTU1MDEtMTAwMjIwMDQ+V2hhdCBJIA0KZXhwZWN0 IGlzIGxpa2UgdGhpczo8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPdDCvJrD 9/N3IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTU0NjM1NTUwMS0xMDAyMjAwND5B c3N1bWU6IA0KVGhlcmUgYXJlIDIgVUFzLCBBIGFuZCBCLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U90MK8msP383cgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFz cz01NDYzNTU1MDEtMTAwMjIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT3Qwryaw/fzdyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz01NDYzNTU1 MDEtMTAwMjIwMDQ+MS4gQSBpcyANCmJ1c3ksIChJbiBJUDIwMDYsIHRoYXQgbWVhbnMgYm90aCZu YnNwOzIgbGluZXMgaGFzJm5ic3A7YSBjb25uZWN0aW9uIHdpdGggDQpzb21lYm9keSk8L1NQQU4+ PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPdDCvJrD9/N3IGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIGNsYXNzPTU0NjM1NTUwMS0xMDAyMjAwND4yLiBCIA0KY2FsbCBBIGFuZCBnb3Qg YSZuYnNwOzQ4NiBCVVNZIHJlcGx5LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U90MK8msP383cgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9NTQ2MzU1NTAxLTEw MDIyMDA0PjMuIEIgDQpkZWNpZGUgdG8gd2FpdCBmb3IgQS4mbmJzcDtCJm5ic3A7c2VuZCBhJm5i c3A7U1VCU0NSSUJFIHRvIEEmbmJzcDthbmQgaGFuZyANCnVwLiZuYnNwOzwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U90MK8msP383cgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQ QU4gY2xhc3M9NTQ2MzU1NTAxLTEwMDIyMDA0PjQuIA0KQWZ0ZXIgY2VydGFpbiBwZXJpb2Qgb2Yg dGltZSwgQSBmaW5hbGx5IGNsb3NlIG9uZSBvZiBpdCdzIGNvbm5lY3Rpb24gYW5kIGhhcyBhIA0K ZnJlZTwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U90MK8msP383cgY29sb3I9 IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFzcz01NDYzNTU1MDEtMTAwMjIwMDQ+Jm5ic3A7Jm5i c3A7Jm5ic3A7IGxpbmUuIDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U90MK8 msP383cgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9NTQ2MzU1NTAxLTEwMDIyMDA0 PjUuIEEgDQpzZW5kIGEgTk9USUZZIHRvIEIgaW5kaWNhdGUgdGhhdCBoZSBpcyBmcmVlIHRvIGFj Y2VwdCANCmNvbm5lY3Rpb24uPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3Q wryaw/fzdyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz01NDYzNTU1MDEtMTAwMjIw MDQ+Ni4gQiANCnJlY2VpdmUgdGhpcyBOT1RJRlkgYW5kIHN0YXJ0IHRvIHJpbmcuIEIgVU5TVUJT Q1JJQkUgdGhlIGV2ZW50IA0KYWxzby48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPdDCvJrD9/N3IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTU0NjM1NTUwMS0x MDAyMjAwND43LiANCkFmdGVyIHVzZXIgcGlja3VwIEIsIEIgc2VuZCBhIElOVklURSB0byBBIHRy eSB0byBlc3RhYmxpc2ggYSANCmNvbm5lY3Rpb24uPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT3Qwryaw/fzdyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz01NDYz NTU1MDEtMTAwMjIwMDQ+OC4gQSANCnN0YXJ0IHJpbmdpbmcgd2hlbiBpdCByZWNlaXZlIElOVklU RS4gRnJvbSBub3cgb24sIGl0IGlzIHRoZSBzYW1lIGFzIA0KdGhlPC9TUEFOPjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT3Qwryaw/fzdyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiAN CmNsYXNzPTU0NjM1NTUwMS0xMDAyMjAwND4mbmJzcDsmbmJzcDsmbmJzcDsgcmVndWxhciBjYWxs IA0Kb3V0LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U90MK8msP383cgY29s b3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFzcz01NDYzNTU1MDEtMTAwMjIwMDQ+PC9TUEFO PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3Qwryaw/fzdyBjb2xvcj0jMDAw MGZmIHNpemU9Mj48U1BBTiBjbGFzcz01NDYzNTU1MDEtMTAwMjIwMDQ+PFNQQU4gDQpjbGFzcz01 NDYzNTU1MDEtMTAwMjIwMDQ+SWYgeW91IGhhdmUgZ290IHRoZSBJRVRGIGRyYWZ0IG9yIFJGQyBh Ym91dCANCmNhbGwtd2FpdGluZyBwbGVhc2UgdGVsbCBtZSBvciBzZW5kIGl0IHRvIG1lLjwvU1BB Tj48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPdDCvJrD9/N3IGNvbG9yPSMw MDAwZmYgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTQ2MzU1NTAxLTEwMDIyMDA0PjwvU1BBTj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U90MK8msP383cgY29sb3I9IzAwMDBmZiBz aXplPTI+PFNQQU4gY2xhc3M9NTQ2MzU1NTAxLTEwMDIyMDA0PkJlc3QgDQpSZWdhcmRzLDwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U90MK8msP383cgY29sb3I9IzAwMDBmZiBz aXplPTI+PFNQQU4gY2xhc3M9NTQ2MzU1NTAxLTEwMDIyMDA0PmphY2sgDQp6aGFvPC9TUEFOPjwv Rk9OVD48L0RJVj48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_002D_01C2F2B7.104B9140-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 03:23:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21663 for ; Wed, 11 Feb 2004 03:23:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqpde-0007A8-MH for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 03:22:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B8MU9T027519 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 03:22:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqpdB-00076d-5G; Wed, 11 Feb 2004 03:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqpce-00075k-3g for sip@optimus.ietf.org; Wed, 11 Feb 2004 03:21:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21624 for ; Wed, 11 Feb 2004 03:21:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqpcb-0005dT-00 for sip@ietf.org; Wed, 11 Feb 2004 03:21:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqpbm-0005Ye-00 for sip@ietf.org; Wed, 11 Feb 2004 03:20:34 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqpbR-0005Tm-00 for sip@ietf.org; Wed, 11 Feb 2004 03:20:13 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Feb 2004 00:27:55 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1B8Jgu5029390; Wed, 11 Feb 2004 00:19:42 -0800 (PST) Received: from [212.157.205.40] (sjc-vpn3-3.cisco.com [10.21.64.3]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMG48529; Wed, 11 Feb 2004 00:19:40 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 10 Feb 2004 15:34:06 -0800 Subject: Re: [Sip] CallId question From: Cullen Jennings To: Anil Bollineni , Message-ID: In-Reply-To: <017B1BB60535DF4285666089FA048AC20172EFDA@SONOMA.netscreen.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3159303580_347360" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_FONT_BIG, HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3159303580_347360 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The NAT/FW must not go changing this stuff. If it does, a S/MIME signed sipfrag will fail. There is no need for the NAT to go change call IDs On 2/10/04 12:27 PM, "Anil Bollineni" wrote: > Hello, > > I have a question about CallId. Suppose two UA's generate callid's > putting theire hostnames and send to firewall/NAT. > UA1:INVITE > CallID: call1@192.10.10.10 > UA2: INVITE > CallId: call1@192.10.10.12 > > Because those callid information contain IP addresses, the > firewall/NAT should translate these IP addresses by putting it's own IP in > callId. The callId's are changed to call1@firewall_ip, call1@firewall_ip. When > responses come back from their respective UAS's the firewall/NAT translates > the it's IP address in callId's to their original IP's. My question is should > I change the string "call1" to something generated by firewall or Is it OK to > leave like that. Even though they have same CallId, the proxy should > discriminate the calls by from-tag, callid, and to-tag. > According to Spec, any UA should have a different means of generating callid's > with those of other UA's. > > Anything to do correctly to the above procedure? > > Thanks in advance, > Anil > This email contains material that is confidential. The content of this email > is for the sole use of the intended recipient(s). Any review or distribution > by persons other than the intended recipient(s) without the express permission > of NetScreen Technologies, Inc. is strictly prohibited. If you are not the > intended recipient, please contact the sender and delete/destroy all copies of > this email and any related attachments. NetScreen does not guarantee the > accuracy or completeness of third party materials or information. > > > --B_3159303580_347360 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Sip] CallId question
The NAT/FW must not go changing this stuff. If it does, a S/MIME signed sip= frag will fail. There is no need for the NAT to go change call IDs



On 2/10/04 12:27 PM, "Anil Bollineni" <ABollineni@netscreen.co= m> wrote:

Hello,
 
            I h= ave a question about CallId. Suppose two UA's generate callid's putting thei= re hostnames and send to firewall/NAT.
            UA1= :INVITE
            &nb= sp;    CallID: call1@192.10.10.10
            UA2= : INVITE
            &nb= sp;       CallId: call1@192.10.10.12
                         Bec= ause those callid information contain IP addresses, the firewall/NAT should = translate these IP addresses by putting it's own IP in callId. The callId's = are changed to call1@firewall_ip, call1@firewall_ip. When responses come bac= k from their respective UAS's the firewall/NAT translates the it's IP addres= s in callId's to their original IP's. My question is should I change the str= ing "call1" to something generated by firewall or Is it OK to leav= e like that. Even though they have same CallId, the proxy should discriminat= e the calls by from-tag, callid, and to-tag.
According to Spec, any UA should have a different means of generating calli= d's with those of other UA's.
 
Anything to do correctly to the above procedure?
 
Thanks in advance,
Anil
This email contains material that is confidential. The content of this emai= l is for the sole use of the intended recipient(s). Any review or distributi= on by persons other than the intended recipient(s) without the express permi= ssion of NetScreen Technologies, Inc. is strictly prohibited. If you are not= the intended recipient, please contact the sender and delete/destroy all co= pies of this email and any related attachments. NetScreen does not guarantee= the accuracy or completeness of third party materials or information.

--B_3159303580_347360-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 08:06:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29738 for ; Wed, 11 Feb 2004 08:06:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqu4J-0007kP-1f for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 08:06:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BD6INf029719 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 08:06:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqu42-0007iK-Et; Wed, 11 Feb 2004 08:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqu3f-0007hZ-N5 for sip@optimus.ietf.org; Wed, 11 Feb 2004 08:05:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29698 for ; Wed, 11 Feb 2004 08:05:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqu3e-0001BZ-00 for sip@ietf.org; Wed, 11 Feb 2004 08:05:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqu2k-00016H-00 for sip@ietf.org; Wed, 11 Feb 2004 08:04:43 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1Aqu2Q-00010p-00 for sip@ietf.org; Wed, 11 Feb 2004 08:04:22 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 11 Feb 2004 14:03:44 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <1W0JZZNN>; Wed, 11 Feb 2004 14:03:44 +0100 Message-Id: <953B9B08F98DD61183F8000347AE660106186205@G8PPV.blf01.telekom.de> From: "Jesske, R" To: ali.el-moussawi@hp.com, sip@ietf.org Cc: "Poetzl, Joachim" , "Martinez-Rebordosa, Anna" , "Schuette, Wolfgang" , "Benz, Robert" , "Pinker, Gerold" Subject: AW: [Sip] Some details in RFC 3398 Date: Wed, 11 Feb 2004 14:03:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Ali, I think this is a wrong description of ISUP Procedures on the outgoing ISUP side. If you are looking in Q.732.2-5 you will find the correct description of call forwarding scenarios. You will never find a situation were a ACM and a CPG will be send in backward direction at once, because all information will be given in the early ACM. The "Generic notification indicator" will be set to "Call is a diverting call" that's all. No CPG is now needed to indicate the same. With regard to the timer expiry please look in Q.1912.5 there you will find detail information. (e.g. T7 --> 484 Address Incomplete, T9-->480 Temporarily Unavailable...) I hope this helps. Best Regards Roland -----Ursprungliche Nachricht----- Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org]Im Auftrag von El Moussawi, Ali Gesendet: Mittwoch, 4. Februar 2004 14:45 An: sip@ietf.org Betreff: [Sip] Some details in RFC 3398 Hi all, I have two tiny questions concerning RFC3398. In 7.1.6 , what do you think the cause code should be in the REL sent to the PSTN network after interwork tinmer expires ? On the other hand, in 8.2.3, it says that upon receipt of a SIP 181 response, the gateway should send an early ACM to the PSTN side, plus a CPG with event code 6. What is the use of CPG since the other side will already know that its call is beying handled when it receives a early ACM ? Is the CPG mandatory ? Thanks a lot _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 08:16:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29970 for ; Wed, 11 Feb 2004 08:16:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquDp-0000Ej-CU for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 08:16:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BDG9TR000905 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 08:16:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquDi-0000DR-QS; Wed, 11 Feb 2004 08:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquDJ-000080-77 for sip@optimus.ietf.org; Wed, 11 Feb 2004 08:15:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29945 for ; Wed, 11 Feb 2004 08:15:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AquDI-00029k-00 for sip@ietf.org; Wed, 11 Feb 2004 08:15:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AquCJ-000249-00 for sip@ietf.org; Wed, 11 Feb 2004 08:14:36 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AquBM-0001ut-00 for sip@ietf.org; Wed, 11 Feb 2004 08:13:36 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 11 Feb 2004 14:12:58 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <1W0JZ534>; Wed, 11 Feb 2004 14:12:57 +0100 Message-Id: <953B9B08F98DD61183F8000347AE660106186206@G8PPV.blf01.telekom.de> From: "Jesske, R" To: mary.barnes@nortelnetworks.com, sip@ietf.org Subject: AW: [Sip] Optionality for History-Info Date: Wed, 11 Feb 2004 14:12:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Mary, I'm also happy with option 4. Best Regards Roland -----Ursprungliche Nachricht----- Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org]Im Auftrag von Mary Barnes Gesendet: Donnerstag, 5. Februar 2004 15:39 An: 'sip@ietf.org' Betreff: [Sip] Optionality for History-Info I'm in the process of updating History Info (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-01.txt) based upon a few comments I've received and merging the requirements into the solution document. However, I really need more feedback from the working group to address the primary point raised during the discussion in Minneapolis on the optionality. Initial analysis way long ago resulted in the decision that Local Policy was the best approach to the optionality, since it didn't seem reasonable to use Require for an optional header and lack of the header should not prevent a basic request from being processed. However, a concern has been raised that Local Policy isn't sufficient as it requires coordination between clients and proxies (i.e. there's no aspect of the protocol that allows a client to define or discover that the Proxy will add the header). Supported, of course, is used to let the Proxy know that the information, if available, should be included in the responses. In taking a few steps back and re-evaluating all the possibilities for making the optionality more under the control of the protocol and I came up with the following list of possibilities. It may not be complete, nor are the list of pros and cons intended to be exhaustive, but I think it serves as a useful basis for discussion. 1) Use Require Pros: - Puts the use of the header explicitly under control of the client initiating the request. Cons: - Seems extremely restrictive and functionally limiting, although it would depend upon the application at the end client that wants to make use of the information as to how detrimental this might be. - Doesn't make sense since the applicability of History-Info isn't restricted to the initiator of the request. 2) Make use of the Request-Disposition header field as defined in the caller preferences draft to explicit request History-Info be included: history-directive Pros: - Consistent with the intent of that header in that it's a mechanism for a client to request how a server/proxy should handle a request Cons: - that field isn't extensible - doesn't really accomplish more than what can be implied by the Supported header (i.e. if the client wants the information in a response, then if a server is capable of adding the header, it SHOULD). 3) Make use of or define something similar to the Session specific policy, whereby the client "authorizes" a proxy to capture History-Info and that it's only captured in that case. Pros: - Explicit. Cons: - Seems like a lot of overhead, with little advantage. 4) Follow the approach of existing optional SIP headers added by intermediaries (e.g. Path and Reason), which is that it's purely a local policy decision and doesn't require any coordination with the UA as to whether it should or shouldn't be added. Pros: - It's fairly straightforward and consistent with the intent of optional headers. Cons: - Does require some guidelines to ensure that applications that might use the optional information are robust enough to handle the lack of information. Feedback on these proposals is appreciated and hopefully this discussion will allow us to reach a final, constructive conclusion. Obviously, my preference is the 4th option and perhaps one reason why we've gotten so stuck on this point is that the guidelines for applications on the usage of the header are perhaps not obvious. So, it might be useful to add an additional section to the document (or perhaps include additional information for each of the scenarios in the appendix) on application guidelines around the usage of the information and default behavior if the information is not available. Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 08:25:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00115 for ; Wed, 11 Feb 2004 08:25:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquMc-0000rQ-KT for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 08:25:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BDPEdi003246 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 08:25:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquMS-0000pH-JN; Wed, 11 Feb 2004 08:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquM3-0000oZ-98 for sip@optimus.ietf.org; Wed, 11 Feb 2004 08:24:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00103 for ; Wed, 11 Feb 2004 08:24:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AquM2-0002ug-00 for sip@ietf.org; Wed, 11 Feb 2004 08:24:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AquL6-0002pr-00 for sip@ietf.org; Wed, 11 Feb 2004 08:23:41 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AquKm-0002kr-00 for sip@ietf.org; Wed, 11 Feb 2004 08:23:20 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 11 Feb 2004 14:22:47 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <1W0JZ6MZ>; Wed, 11 Feb 2004 14:22:46 +0100 Message-Id: <953B9B08F98DD61183F8000347AE660106186207@G8PPV.blf01.telekom.de> From: "Jesske, R" To: mary.barnes@nortelnetworks.com, sebastien.prouvost@francetelecom.com Cc: sip@ietf.org Subject: AW: RE : [Sip] draft-ietf-sip-history-info-01.txt Date: Wed, 11 Feb 2004 14:22:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Mary, Yes your last paragraph is the correct interpretation of my email. I think a specific privacy tag enables the domain more flexibility with regard to the information shown to the next domain or the user. E.g. a forwarding entity does not allow the presentation of the URI but the originating do. With a general privacy tag all information will not be forwarded to the UAS, but if you have an explicit tag for the history info only the history info will be not shown and the originating URI will be shown. Also information that is only needed for domain/local purposes will be hidden but not the information of the originating of the SIP session. From my understanding a specific privacy tag will help in such kind of use. Best Regards Roland -----Ursprungliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] Gesendet: Mittwoch, 4. Februar 2004 23:13 An: 'PROUVOST S?bastien FTRD/DAC/ISS'; Jesske, Roland Cc: sip@ietf.org Betreff: RE: RE : [Sip] draft-ietf-sip-history-info-01.txt Sebastien and Roland, I apologize for the delay in responding. You are correct in that one privacy aspect currently addressed for History-Info is around the UA's ability to require privacy for elements of a message that can somehow divulge information about the end client's identity. In some ways, History-Info could be considered in the category of Record Route, Via, etc. However, HI is an optional header and per the recommendation in RFC 3323, the decision was made that if Header privacy was requested, then History-Info SHOULD not be included. In addition, if through local policy or some other local information available wrt the retargeted URIs, there is knowledge that there should be privacy applied to these URIs, then as discussed in RFC 3323, the intermediary processing that request can also add the Privacy header to ensure that History-Info is also not captured by subsequent intermediaries. This latter point perhaps is not so clearly or explicitly spelled out in the current document in the privacy sections, but there is discussion in the detailed proxy processing behaviour in 2.3.3 that the local policy can define whether the History-Info captured would leave a specific domain (this is of course for optionality, as well, which is another issue that I'll address in a separate email). It seems that what's being discussed in these emails is introducing a specific privacy tag against those entries that local policy defines should not be forwarded outside a specific domain, so that they can be removed (and don't need to be kept persistent by a privacy service). Right now, there's an asumption that these entries are somehow known by the proxy, but perhaps an explicit tag would be useful. OR are you talking about extending the current model in RFC 3323 to specifically address the use of a privacy service for History-Info headers? Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 -----Original Message----- From: PROUVOST Sebastien FTRD/DAC/ISS [mailto:sebastien.prouvost@francetelecom.com] Sent: Thursday, January 22, 2004 4:32 AM To: Jesske, R; sip@ietf.org; Barnes, Mary [NGC:B622:EXCH]; Watson, Mark [MOP:EP10:EXCH]; fluffy@cisco.com Subject: RE : [Sip] draft-ietf-sip-history-info-01.txt I fully support this proposal. The privacy regarding the history-info header relates to the privacy policy accorded to the target of the request (before it is retargeted). Therefore it shall not depend on the privacy policy accorded to the calling UA. The history-info header shall have its own privacy value. Moreover in case the request is retargeted more than once (particularly if the targets represent different users), it shall be possible to request privacy for a target independently of the others. Regards, Sebastien Prouvost France Telecom R&D/DAC/CAR -----Message d'origine----- De : Jesske, R [mailto:R.Jesske@t-com.net] Envoye : vendredi 16 janvier 2004 10:29 A : sip@ietf.org Cc : Poetzl, Joachim; Alexeitsev, D Objet : [Sip] draft-ietf-sip-history-info-01.txt Dear all, in 1.3 Ensuring the Privacy of History_Info it is proposed to use a priv-value of Session or Header level privacy. I would like to propose a own privacy level for the history info, because the Information shows also information about the network. With regard to the provider operating a network some of the providers don't like to transmit information about call history. Or a redirecting party don't like to show the redirecting address. Therefore it should be possible to delete the history info at domain boundaries based on the privacy-value. I propose the priv-value = "history_info" for the whole History-Info header. In addition a option would be useful where only parts (e.g Indes1.1) of the history info are restricted. That could be done with a privacy statement within the History-Info . Best Regards Roland Deutsche Telekom AG T Com Zentrale Roland Jesske, T332-2 Section T33; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 email: r.jesske@t-com.net _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 08:30:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00282 for ; Wed, 11 Feb 2004 08:30:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquRN-0001N6-Fv for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 08:30:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BDU9c7005210 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 08:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquRG-0001H6-AD; Wed, 11 Feb 2004 08:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquQI-0001Ec-H5 for sip@optimus.ietf.org; Wed, 11 Feb 2004 08:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00255 for ; Wed, 11 Feb 2004 08:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AquQH-0003JG-00 for sip@ietf.org; Wed, 11 Feb 2004 08:29:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AquPD-0003Dp-00 for sip@ietf.org; Wed, 11 Feb 2004 08:27:56 -0500 Received: from smtp2.webway.se ([213.204.186.36]) by ietf-mx with esmtp (Exim 4.12) id 1AquOa-00035c-00 for sip@ietf.org; Wed, 11 Feb 2004 08:27:16 -0500 Received: from edvina.net (apollo.webway.se [213.204.186.40]) by smtp2.webway.se (Postfix) with ESMTP id 77D036DF27; Wed, 11 Feb 2004 14:30:38 +0100 (CET) Message-ID: <402A2D89.2020406@edvina.net> Date: Wed, 11 Feb 2004 14:26:33 +0100 From: "Olle E. Johansson" Organization: Edvina AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.76.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] 302 Redirect on REGISTER Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Is it ok to send a 302 redirect on a register to redirect the UA to another SIP registrar? /Olle _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 09:37:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02504 for ; Wed, 11 Feb 2004 09:37:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvUY-0006dU-Nu for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 09:37:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BEbUNI025446 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 09:37:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvU5-0006Xt-KA; Wed, 11 Feb 2004 09:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvTp-0006Wn-Il for sip@optimus.ietf.org; Wed, 11 Feb 2004 09:36:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02461 for ; Wed, 11 Feb 2004 09:36:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqvTn-0002Sm-00 for sip@ietf.org; Wed, 11 Feb 2004 09:36:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqvSq-0002N8-00 for sip@ietf.org; Wed, 11 Feb 2004 09:35:45 -0500 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 1AqvSb-0002Hm-00 for sip@ietf.org; Wed, 11 Feb 2004 09:35:29 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HSX00N01CG74B@siemenscomms.co.uk> for sip@ietf.org; Wed, 11 Feb 2004 14:33:44 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HSX00M4ACG7U1@siemenscomms.co.uk> for sip@ietf.org; Wed, 11 Feb 2004 14:33:43 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Feb 2004 14:39:00 +0000 Content-return: allowed Date: Wed, 11 Feb 2004 14:35:02 +0000 From: "Elwell, John" To: "'sip@ietf.org'" Message-id: <50B1CBA96870A34799A506B2313F2667D4AB88@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_F1FY7NFbJ3HcvVN3zh7Y0Q)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] New I-D on state update Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_F1FY7NFbJ3HcvVN3zh7Y0Q) Content-type: text/plain Content-Transfer-Encoding: 7BIT Please be aware of a new I-D on state update (I did not see any notice on the list): http://www.ietf.org/internet-drafts/draft-elwell-sip-state-update-00.txt Abstract: This document examines the need for updating state information, such as remote party identity, during a SIP dialog. It explores existing mechanisms that might be appropriate and identifies matters that need to be fixed to make this possible. John Elwell (john.elwell@siemens.com) --Boundary_(ID_F1FY7NFbJ3HcvVN3zh7Y0Q) Content-type: text/html Content-Transfer-Encoding: 7BIT New I-D on state update

Please be aware of a new I-D on state update (I did not see any notice on the list):

http://www.ietf.org/internet-drafts/draft-elwell-sip-state-update-00.txt

Abstract: This document examines the need for updating state information, such as remote party identity, during a SIP dialog. It explores existing mechanisms that might be appropriate and identifies matters that need to be fixed to make this possible.

John Elwell (john.elwell@siemens.com)

--Boundary_(ID_F1FY7NFbJ3HcvVN3zh7Y0Q)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 10:09:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04061 for ; Wed, 11 Feb 2004 10:09:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvzH-0004M1-Dv for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 10:09:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BF9FqD016675 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 10:09:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqvz3-0004GG-5L; Wed, 11 Feb 2004 10:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqvyo-0004At-Gp for sip@optimus.ietf.org; Wed, 11 Feb 2004 10:08:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03966 for ; Wed, 11 Feb 2004 10:08:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqvym-0005dV-00 for sip@ietf.org; Wed, 11 Feb 2004 10:08:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqvxq-0005YV-00 for sip@ietf.org; Wed, 11 Feb 2004 10:07:46 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AqvxW-0005TC-00 for sip@ietf.org; Wed, 11 Feb 2004 10:07:26 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1BF6sID006737; Wed, 11 Feb 2004 16:06:54 +0100 Received: from nextenso.com (nx0068.nextenso.alcatel.fr [139.54.130.68]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id i1BF6amM003538; Wed, 11 Feb 2004 16:06:36 +0100 Message-ID: <402A4530.9020901@nextenso.com> Date: Wed, 11 Feb 2004 16:07:28 +0100 From: Thomas Froment Organization: Nextenso User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: fr-FR, en, zh MIME-Version: 1.0 To: Anil Bollineni CC: sip@ietf.org Subject: Re: [Sip] CallId question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > The NAT/FW must not go changing this stuff. If it does, a S/MIME > signed sipfrag will fail. There is no need for the NAT to go change > call IDs Yes, NAT does not change the content of SIP messages (Call-ID, Via-Header, or SDP content...), since it maps IP/ports at the transport level (TCP/UDP...). That's even why it is necessary to use additional functions (STUN/TURN and more..) to make SIP work with NAT... > > > > On 2/10/04 12:27 PM, "Anil Bollineni" wrote: > > Hello, > > I have a question about CallId. Suppose two UA's > generate callid's putting theire hostnames and send to firewall/NAT. > UA1:INVITE > CallID: call1@192.10.10.10 > UA2: INVITE > CallId: call1@192.10.10.12 > > Because those callid information contain IP addresses, > the firewall/NAT should translate these IP addresses by putting > it's own IP in callId. The callId's are changed to > call1@firewall_ip, call1@firewall_ip. When responses come back > from their respective UAS's the firewall/NAT translates the it's > IP address in callId's to their original IP's. My question is > should I change the string "call1" to something generated by > firewall or Is it OK to leave like that. Even though they have > same CallId, the proxy should discriminate the calls by from-tag, > callid, and to-tag. > According to Spec, any UA should have a different means of > generating callid's with those of other UA's. > > Anything to do correctly to the above procedure? > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 10:40:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05706 for ; Wed, 11 Feb 2004 10:40:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwTQ-0000fk-LM for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 10:40:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BFeOLR002522 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 10:40:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwT8-0000dC-3W; Wed, 11 Feb 2004 10:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwSu-0000bu-D4 for sip@optimus.ietf.org; Wed, 11 Feb 2004 10:39:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05645 for ; Wed, 11 Feb 2004 10:39:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwSs-0000lN-00 for sip@ietf.org; Wed, 11 Feb 2004 10:39:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqwRx-0000fP-00 for sip@ietf.org; Wed, 11 Feb 2004 10:38:53 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AqwRW-0000Yv-00 for sip@ietf.org; Wed, 11 Feb 2004 10:38:27 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1BFbYID003763; Wed, 11 Feb 2004 16:37:34 +0100 Received: from nextenso.com (nx0068.nextenso.alcatel.fr [139.54.130.68]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id i1BFbHmM003637; Wed, 11 Feb 2004 16:37:17 +0100 Message-ID: <402A4C61.1060908@nextenso.com> Date: Wed, 11 Feb 2004 16:38:09 +0100 From: Thomas Froment Organization: Nextenso User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: fr-FR, en, zh MIME-Version: 1.0 To: sip@ietf.org CC: oej@edvina.net Subject: Re: [Sip] 302 Redirect on REGISTER References: <402A2D89.2020406@edvina.net> In-Reply-To: <402A2D89.2020406@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Olle E. Johansson wrote: > Is it ok to send a 302 redirect on a register to redirect the UA to > another SIP registrar? > > /Olle In section 10.3 of RFC 3261, it is written: "registrar MAY redirect REGISTER requests as appropriate. One common usage would be for a registrar listening on a multicast interface to redirect multicast REGISTER requests to its own unicast interface with a 302 (Moved Temporarily) response." So, I would consider you MAY do it. Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 11:30:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08234 for ; Wed, 11 Feb 2004 11:30:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxFf-0005F0-M5 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 11:30:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGUFrs020145 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 11:30:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxFX-0005DV-Ja; Wed, 11 Feb 2004 11:30:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxFM-0005Av-7k for sip@optimus.ietf.org; Wed, 11 Feb 2004 11:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08189 for ; Wed, 11 Feb 2004 11:29:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxFL-0006ux-00 for sip@ietf.org; Wed, 11 Feb 2004 11:29:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxE9-0006bh-00 for sip@ietf.org; Wed, 11 Feb 2004 11:28:43 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AqxC6-00064x-00 for sip@ietf.org; Wed, 11 Feb 2004 11:26:34 -0500 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BGOqI01915; Wed, 11 Feb 2004 11:24:53 -0500 (EST) Received: from ztcfd03m.ca.nortel.com ([47.10.32.202]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1FNDXLYL; Wed, 11 Feb 2004 11:24:52 -0500 Received: from americasm01.nt.com (wbvws178.ca.nortel.com [47.11.181.106]) by ztcfd03m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1GSX387A; Wed, 11 Feb 2004 11:24:52 -0500 Message-ID: <402A5753.DB01C1FB@americasm01.nt.com> Date: Wed, 11 Feb 2004 11:24:51 -0500 From: "Dusan Mudric" Organization: Nortel Networks X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Scott Lawrence , Paul Kyzivat , ksrini@motorola.com, sip@ietf.org Subject: Re: [Sip] Registering Multiple 'Contacts' References: <4002E0B9.8030203@cisco.com> <400FEFD1.60004@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi: Let me compare given example with registration renewal. It my clarify some doubts. Registration renewal is done for the same Contact URI's, within the same call leg, using the same Call-ID and incremented CSeq number in the refresh REGISTER request. This just extends registration time but doesn't change or add Contact URI. At refresh, Contact(s)'s CSeq number is updated with a new one, as well as {action, expires, qvalue} parameters. It is unlikely that Contact parameters are going to be changed in the renewal requests. For the same Contact URI in a refresh REGISTER request, if Call-ID is different, the Contact's Call-ID is updated with a new one, if expiration time is not zero. There is no replace of Contact URI's. Only remove (expires=0 for the Contact) and add. Is this right? Thanks, Dusan. Jonathan Rosenberg wrote: > > Scott Lawrence wrote: > > > Srinivasan Krishnamoorthy wrote: > > > > > >>> Section 10.2.4 of RFC3261 'Refreshing Bindings' says: > >>> "The UA then issues a REGISTER request for each of its bindings > >>>before the expiration interval has elapsed. It MAY combine several > >>>updates into one REGISTER request." > >>> The above seems to indicate that the UAC may send: (forgive the > >>>Syntax) > >>> REGISTER To: user@operator.net > >>> Contact: sip:user1@10.0.0.1;expires=3600 > >>> 200 OK > >>> REGISTER To: user@operator.net > >>> Contact: sip:user1@192.0.0.1;expires=3600 > >>> 200 OK > >>> This, according to RFC3261, will register both Contact1 and Contact2 > >>>for user@operator.net. (The server will then use the q parameter > >>> of the contact for priority among contacts) > > > > > > Paul Kyzivat writes: > > > > > >>Yes. > > > > > > My reading is that the results should differ depending on the Call-Id > > used in those two REGISTER requests: > > > > - If they have different Call-Id values, then the server should > > register both contacts. > > > > - If they have the same Call-Id value, then the second REGISTER > > should cause the server to replace the first contact with the > > second, so that there would be only > > No, this is not the case. The callid/cseq are used as an ordering > tool. In the abovoe case, if the Call-ID are the same, both contacts > are added, and both are marked as having that particular callid, but > with different cseq. if the Call-id are different, both contacts are > added, but with different call-id and cseq. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 15:38:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20862 for ; Wed, 11 Feb 2004 15:38:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar174-0002u4-OC for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 15:37:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKbaeh010943 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 15:37:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar16X-0002gt-M0; Wed, 11 Feb 2004 15:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar16K-0002di-2M for sip@optimus.ietf.org; Wed, 11 Feb 2004 15:36:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20754 for ; Wed, 11 Feb 2004 15:36:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar16I-0001sW-00 for sip@ietf.org; Wed, 11 Feb 2004 15:36:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar15L-0001jZ-00 for sip@ietf.org; Wed, 11 Feb 2004 15:35:52 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar14T-0001VI-00 for sip@ietf.org; Wed, 11 Feb 2004 15:34:58 -0500 Received: from softarmor.com (dhcp216-12-250-244.dfwb.dal.wayport.net [216.12.250.244]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1BKZwsb029861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Feb 2004 14:35:59 -0600 Message-ID: <402A91C0.3020504@softarmor.com> Date: Wed, 11 Feb 2004 14:34:08 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] IPR notice on GRUU filed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: IPR Notice Date: Tue, 10 Feb 2004 18:33:37 -0500 (EST) From: IESG Secretary To: jdrosen@dynamicsoft.com CC: mankin@psg.com, , , Dear Mr. Rosenberg, An IPR Notice has been posted that pertains to your Internet-Draft entitled "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Iniation Protocol (SIP)" (http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-00.txt). The title of the IPR Notice is "Microsoft Corporation's Statement About IPR Claimed in draft-ietf-sip-gruu" (http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-sip-gruu.txt). The IETF Secretariat _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 11 16:14:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24974 for ; Wed, 11 Feb 2004 16:14:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1gU-0006pn-TS for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 16:14:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLEEZN026209 for sip-archive@odin.ietf.org; Wed, 11 Feb 2004 16:14:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1gI-0006nT-Da; Wed, 11 Feb 2004 16:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1fZ-0006kM-O1 for sip@optimus.ietf.org; Wed, 11 Feb 2004 16:13:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24668 for ; Wed, 11 Feb 2004 16:13:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1fY-0006vF-00 for sip@ietf.org; Wed, 11 Feb 2004 16:13:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1eF-0006ec-00 for sip@ietf.org; Wed, 11 Feb 2004 16:11:56 -0500 Received: from [216.90.186.146] (helo=mail.ipnetfusion.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1cq-0005Ka-00 for sip@ietf.org; Wed, 11 Feb 2004 16:10:28 -0500 Received: from ipnetfusion.com (pc223 [192.1.2.223]) (authenticated) by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i1BL5OG04362 for ; Wed, 11 Feb 2004 15:05:24 -0600 Message-ID: <402A9913.9030003@ipnetfusion.com> Date: Wed, 11 Feb 2004 15:05:23 -0600 From: cthakker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Record-Route and Contact Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, If a UAC generates a request in Dialog (say an ACK for 200 it received), If the 200 had a Record-Route with loose routing and also a Contact header where should it route the request ? Can it route it directly to the IP/FQDN specified in the uri of Contact ? Does any header take precedence over other when generating a subsequent request in a Dialog ? Is the significance of Contact header end-to-end or between UAs. For the example given in the RFC 3261 (alice and bob), can the intermediate proxies modify the value of the Contact header in the response sent by Alice to Bob ? Thank you, Chintan ipNetFusion Inc, Dallas, Tx - 75080 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 12 02:11:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10597 for ; Thu, 12 Feb 2004 02:11:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAzu-0006e7-UT for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 02:10:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C7As19025455 for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 02:10:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAz5-0006I6-5n; Thu, 12 Feb 2004 02:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAy4-00061P-9S for sip@optimus.ietf.org; Thu, 12 Feb 2004 02:09:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08332 for ; Thu, 12 Feb 2004 02:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArAy0-00063L-00 for sip@ietf.org; Thu, 12 Feb 2004 02:08:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArAx3-0005yK-00 for sip@ietf.org; Thu, 12 Feb 2004 02:07:58 -0500 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 1ArAwU-0005p9-00 for sip@ietf.org; Thu, 12 Feb 2004 02:07:22 -0500 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sip@ietf.org; Thu, 12 Feb 2004 08:06:52 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <1SQ4MQ0C>; Thu, 12 Feb 2004 08:06:51 +0100 Message-Id: From: "Beck01, Wolfgang" To: sip@ietf.org Date: Thu, 12 Feb 2004 08:06:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] HTTP digest and RADIUS; new version of the Sterman draft availabl e Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt contains a revised version of the draft. It has a Security Considerations section now and I've added support for Authentication-Info. Please send your comments to to the radiusext mailing list, radiusext@ops.ietf.org. Wolfgang Beck _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 12 09:32:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25336 for ; Thu, 12 Feb 2004 09:32:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHt3-0007to-8V for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 09:32:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CEWH4G030303 for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 09:32:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHsn-0007rU-Sj; Thu, 12 Feb 2004 09:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHs3-0007ob-V6 for sip@optimus.ietf.org; Thu, 12 Feb 2004 09:31:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25302 for ; Thu, 12 Feb 2004 09:31:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHry-0001uX-00 for sip@ietf.org; Thu, 12 Feb 2004 09:31:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHr2-0001qJ-00 for sip@ietf.org; Thu, 12 Feb 2004 09:30:13 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArHqS-0001h7-00 for sip@ietf.org; Thu, 12 Feb 2004 09:29:36 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CESne26455; Thu, 12 Feb 2004 09:28:49 -0500 (EST) Received: from ztcfd03m.ca.nortel.com ([47.10.32.202]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1FNH7S79; Thu, 12 Feb 2004 09:28:49 -0500 Received: from americasm01.nt.com (wbvws178.ca.nortel.com [47.11.181.106]) by ztcfd03m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1GSX39SJ; Thu, 12 Feb 2004 09:28:49 -0500 Message-ID: <402B8DA0.A7D7AA7@americasm01.nt.com> Date: Thu, 12 Feb 2004 09:28:48 -0500 From: "Dusan Mudric" Organization: Nortel Networks X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew.Gardiner@aculab.com CC: cthakker@ipnetfusion.com, sip@ietf.org Subject: Re: [Sip] Record-Route and Contact References: <8C9A566C643ED6119E8900A0C9DE297A01F8645C@saturn.aculab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=CLICK_BELOW autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Matthew.Gardiner@aculab.com wrote: > > It's my understanding that Record-Route headers take precedence over > the IP/FQDN in the contact header of the response, as they > (Record-Route headers) are inserted by specifically by the proxies in > order to influence the route that subsequent messaging takes. Assumption is that proxy is in a Record-Route URI domain. Otherwise some other means can be used to route a request. > They influence, not only the route taken by the ACK, furthermore that taken > by any subsequent requests. Except REGISTER, which must ignore a Record-Route. > > -----Original Message----- > From: cthakker [mailto:cthakker@ipnetfusion.com] > Sent: 11 February 2004 21:05 > To: sip@ietf.org > Subject: [Sip] Record-Route and Contact > > Hi all, > If a UAC generates a request in Dialog (say an ACK for 200 it > received), > > If the 200 had a Record-Route with loose routing and also a Contact > header where should it route the request ? Can it route it directly to > > the IP/FQDN specified in the uri of Contact ? Does any header take > precedence over other when generating a subsequent request in a Dialog > ? > Is the significance of Contact header end-to-end or between UAs. For > the example given in the RFC 3261 (alice and bob), can the > intermediate > proxies modify the value of the Contact header in the response sent by > > Alice to Bob ? > > Thank you, > > Chintan > ipNetFusion Inc, > Dallas, Tx - 75080 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > For Aculab's privacy policy and E-Mail disclaimer, Click Here : > http://www.aculab.com/company/legal_notice.htm. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 12 17:34:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20421 for ; Thu, 12 Feb 2004 17:34:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPPP-0005oq-Ja for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 17:34:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CMYBH8022367 for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 17:34:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPPG-0005nd-3b; Thu, 12 Feb 2004 17:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPOi-0005fE-LR for sip@optimus.ietf.org; Thu, 12 Feb 2004 17:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20323 for ; Thu, 12 Feb 2004 17:33:25 -0500 (EST) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPOe-0005LZ-00 for sip@ietf.org; Thu, 12 Feb 2004 17:33:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPNk-0005EV-00 for sip@ietf.org; Thu, 12 Feb 2004 17:32:28 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1ArPMn-00052I-00 for sip@ietf.org; Thu, 12 Feb 2004 17:31:29 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1CMUvPp014648 for ; Fri, 13 Feb 2004 04:00:58 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 13 Feb 2004 04:02:34 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 04:00:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Contact header on UPDATE Date: Fri, 13 Feb 2004 04:00:56 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEADEDB396@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] Contact header on UPDATE Thread-Index: AcPwFGWMfuXbbZEESjqac0vYFkXqCwBofo6Q To: , Cc: X-OriginalArrivalTime: 12 Feb 2004 22:30:56.0915 (UTC) FILETIME=[E1FB2E30:01C3F1B7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Comments inline... Thanks & Regards, Nataraju A.B.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Arunachalam Venkatraman Sent: Wednesday, February 11, 2004 1:49 AM To: Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] Contact header on UPDATE Jonathan Since INVITE establishes the target information, it is clear why it is mandatory on the INVITE. In subsequent rerquests withina dialog, the Contact need not be mandatory. If the remote traget is to be changed, then the Contact must be specified, otherwise not. What is broken if UPDATE does not have a Contact? What functionality is lost? My understanding for making Contact mandatory on a re-INVITE, was to avoid making re-INVITE any different from an INVITE. It is not a terribly onerous thing to provide Conatct on an UPDATE (and its 200), but I wish to understand what is achieved by doing it and what is lost by not doing it. [ABN] here you are using UPDATE with an intention of updating your contact information. I can narrate your scenario as sending an envelope without addressee contact information. In this case for sure envelope does not reach the intended destination.=20 Here I meant that you are sending an UPDATE to update your contact information with the remote party, and UPADTE without contact information what does it serves for you -- Nothing... hence contact is mandatory for UPDAET request... Regards, Venkat -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, February 10, 2004 2:08 PM To: arunvenk Cc: sip@ietf.org Subject: Re: [Sip] Contact header on UPDATE UPDATE is a target refresh request, which means it updates the remote target (i.e., the Contact). That means, like INVITE, it needs to contain a contact. Thanks, Jonathan R. arunvenk wrote: > Moving to sip - no response on sip-implementors .... > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > Arunachalam Venkatraman > Sent: Friday, February 06, 2004 10:49 AM > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Contact header on UPDATE > > RFC3311 - UPDATE > Why is the Contact header mandatory on an UPDATE request? > > Why is the Contact header mandatory on a 2xx response to an UPDATE > request? > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 12 17:48:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20858 for ; Thu, 12 Feb 2004 17:48:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPcz-0006xg-1F for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 17:48:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CMmCSd026696 for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 17:48:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPcn-0006vP-Td; Thu, 12 Feb 2004 17:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPcM-0006uR-79 for sip@optimus.ietf.org; Thu, 12 Feb 2004 17:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20814 for ; Thu, 12 Feb 2004 17:47:30 -0500 (EST) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPcH-0006c1-00 for sip@ietf.org; Thu, 12 Feb 2004 17:47:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPbP-0006X7-00 for sip@ietf.org; Thu, 12 Feb 2004 17:46:37 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1ArPb4-0006RS-00 for sip@ietf.org; Thu, 12 Feb 2004 17:46:14 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1CMjiPp021125 for ; Fri, 13 Feb 2004 04:15:44 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 13 Feb 2004 04:17:20 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 04:15:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F1B9.F1565D9E" Subject: RE: [Sip] Record-Route and Contact Date: Fri, 13 Feb 2004 04:15:41 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEADEDB397@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] Record-Route and Contact Thread-Index: AcPxPSvcfc1sfFgsSC25ttgTcirnrgAew0uw To: , Cc: X-OriginalArrivalTime: 12 Feb 2004 22:45:42.0817 (UTC) FILETIME=[F2051910:01C3F1B9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,CLICK_BELOW,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F1B9.F1565D9E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Thanks & Regards, Nataraju A.B.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Matthew.Gardiner@aculab.com Sent: Thursday, February 12, 2004 1:09 PM To: cthakker@ipnetfusion.com Cc: sip@ietf.org Subject: RE: [Sip] Record-Route and Contact =20 It's my understanding that Record-Route headers take precedence over the IP/FQDN in the contact header of the response, as they (Record-Route headers) are inserted by specifically by the proxies in order to influence the route that subsequent messaging takes. They influence, not only the route taken by the ACK, furthermore that taken by any subsequent requests. [ABN] once 200 for INVITE is received it forms the Route header for further requests sent in the same dialog. The logic to form Route header is been clearly mentioned in the Rfc3261 and the contact information in 200-INVITE forms the Req-URI for subsequent requests.=20 -----Original Message-----=20 From: cthakker [mailto:cthakker@ipnetfusion.com]=20 Sent: 11 February 2004 21:05=20 To: sip@ietf.org=20 Subject: [Sip] Record-Route and Contact=20 =20 Hi all,=20 If a UAC generates a request in Dialog (say an ACK for 200 it received),=20 =20 If the 200 had a Record-Route with loose routing and also a Contact=20 header where should it route the request ? Can it route it directly to=20 the IP/FQDN specified in the uri of Contact ? Does any header take=20 precedence over other when generating a subsequent request in a Dialog ? Is the significance of Contact header end-to-end or between UAs. For=20 the example given in the RFC 3261 (alice and bob), can the intermediate=20 proxies modify the value of the Contact header in the response sent by=20 Alice to Bob ?=20 Thank you,=20 Chintan=20 ipNetFusion Inc,=20 Dallas, Tx - 75080=20 =20 _______________________________________________=20 Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol=20 Use sip-implementors@cs.columbia.edu for questions on current sip=20 Use sipping@ietf.org for new developments on the application of sip=20 =20 For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.=20 =20 ------_=_NextPart_001_01C3F1B9.F1565D9E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] Record-Route and Contact

 

 

Thanks & Regards,
Nataraju A.B.

-----Original = Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of Matthew.Gardiner@aculab.com
Sent: Thursday, February 12, 2004 1:09 PM
To: = cthakker@ipnetfusion.com
Cc: sip@ietf.org
Subject: RE: [Sip] = Record-Route and Contact

 

It's my understanding that Record-Route = headers take precedence over the IP/FQDN in the contact header of the response, as = they (Record-Route headers) are inserted by specifically by the proxies in = order to influence the route that subsequent messaging takes. They influence, not = only the route taken by the ACK, furthermore that taken by any subsequent = requests.

[ABN] = once 200 for INVITE is received it forms the Route header for further requests = sent in the same dialog. The logic to form Route header is been clearly = mentioned in the Rfc3261 and the contact information in 200-INVITE forms the Req-URI for subsequent requests.

-----Original Message-----
From: cthakker [mailto:cthakker@ipnetfusion.com<= /a>]
Sent: = 11 = February 2004 21:05
To: = sip@ietf.org
Subject: [Sip] = Record-Route and Contact

 

Hi all,
 If a UAC generates = a request in Dialog (say an ACK for 200 it received),
  =
 If the 200 had a = Record-Route with loose routing and also a Contact
header where should it = route the request ? Can it route it directly to
the IP/FQDN specified in = the uri of Contact ? Does any header take
precedence over other = when generating a subsequent request in a Dialog ?
 Is the = significance of Contact header end-to-end or between UAs. For
the example given in the = RFC 3261 (alice and bob), can the intermediate
proxies modify the value = of the Contact header in the response sent by
Alice to Bob = ?

 Thank you,

 Chintan
 ipNetFusion = Inc,
 Dallas, Tx - = 75080

 

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

 

For Aculab's privacy policy = and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.

 

------_=_NextPart_001_01C3F1B9.F1565D9E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 12 18:10:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22332 for ; Thu, 12 Feb 2004 18:10:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPyG-0004TZ-NN for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 18:10:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CNACxr017141 for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 18:10:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPy7-0004Q2-U4; Thu, 12 Feb 2004 18:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPxZ-00047Y-Pa for sip@optimus.ietf.org; Thu, 12 Feb 2004 18:09:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22197 for ; Thu, 12 Feb 2004 18:09:26 -0500 (EST) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPxV-0000wv-00 for sip@ietf.org; Thu, 12 Feb 2004 18:09:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPwY-0000rw-00 for sip@ietf.org; Thu, 12 Feb 2004 18:08:26 -0500 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1ArPvi-0000hx-00 for sip@ietf.org; Thu, 12 Feb 2004 18:07:35 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1CN708V015409 for ; Fri, 13 Feb 2004 04:37:00 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 13 Feb 2004 04:38:37 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 04:37:00 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Sip-implementors] Via: processing Date: Fri, 13 Feb 2004 04:36:59 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEADEDB398@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] RE: [Sip-implementors] Via: processing Thread-Index: AcPnT4Kg0BWKLk73SbWHQuKZwWUX4AKbAfvg To: , Cc: X-OriginalArrivalTime: 12 Feb 2004 23:07:00.0115 (UTC) FILETIME=[EB594E30:01C3F1BC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I guess putting FQDN or IP addresses in the Via header driven by the tradeoff between overhead in DNS query for FQDN name but provides robustness or direct usage of IP address which lead to undeliverable in case intermediate entities failure.=20 It's my feeling, please correct me if I am wrong.... Thanks & Regards, Nataraju A.B.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Paul D.Smith Sent: Friday, January 30, 2004 9:56 PM To: 'brett@broadsoft.com' Cc: SIP WG Subject: [Sip] RE: [Sip-implementors] Via: processing Brett, Arlie, RFC3261 clearly allows a response to be "rerouted" if it can be determined that the response did not reach the first-attempt target. For example, if the request is received over TCP, and the connection has gone and cannot be reestablished by the time the response is ready to be sent back, RFC3261 states the following --- from RFC3261, section 18.2.2, 1st bullet. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. --- end of cut RFC3263 then gives an algorithm for attempting to determine alternate IP addresses to which the response might be sent. Clearly having an FQDN in the sent-by will give a chance of success which having an IP address will not, especially if the sent-by and received IP addresses are the same! Paul DS. Paul D.Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: 29 January 2004 00:27 To: SIP (E-mail) Subject: RE: [Sip-implementors] Via: processing > I'm looking at the spec for Via: processing. =20 > RFC 3261 clearly shows that a Via: line can=20 > contain DNS names, as well as textual > representations of network addresses. >=20 > How many products actually implement support=20 > for resolving DNS names provided in Via: lines? =20 Not very many support DNS resolution of a Via entry. However many support the concept of adding the Via's received parameter when it does not match the Via's sent-by address. > This seems... well, it seems unnecessary, > potentially insecure (allowing for easy DDoS=20 > and potentially amplification attacks), and=20 > just a general nuisance. Is this kind of > thing ever actually used for a good purpose? =20 Some people have toyed with the idea of advancing response addresses based upon rfc3263 during failure situations. > Does any product do anything *but* just put=20 > real network addresses in Via: lines in > requests? Yes. _______________________________________________ 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 13 01:23:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10711 for ; Fri, 13 Feb 2004 01:23:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWjI-00042R-JF for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 01:23:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D6NC2V015520 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 01:23:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWj7-000416-6Q; Fri, 13 Feb 2004 01:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWit-00040C-BE for sip@optimus.ietf.org; Fri, 13 Feb 2004 01:22:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10682 for ; Fri, 13 Feb 2004 01:22:43 -0500 (EST) From: ranjit.avasarala@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWim-0003w6-00 for sip@ietf.org; Fri, 13 Feb 2004 01:22:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWhp-0003s1-00 for sip@ietf.org; Fri, 13 Feb 2004 01:21:42 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1ArWha-0003nv-00 for sip@ietf.org; Fri, 13 Feb 2004 01:21:32 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1D6KpPp001303 for ; Fri, 13 Feb 2004 11:50:51 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 13 Feb 2004 11:52:28 +0530 Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 11:50:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Sip-implementors] Via: processing Date: Fri, 13 Feb 2004 11:50:50 +0530 Message-ID: Thread-Topic: [Sip] RE: [Sip-implementors] Via: processing Thread-Index: AcPnT4Kg0BWKLk73SbWHQuKZwWUX4AKbAfvgAA/D3zA= To: , , Cc: X-OriginalArrivalTime: 13 Feb 2004 06:20:51.0103 (UTC) FILETIME=[8706DAF0:01C3F1F9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi actually putting IP address in Via is not recommended when the SIP message has to traverse through NAT. So it is better to have FQDN instead of IP.=20 Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Nataraju Alilaghatta (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) Sent: Friday, February 13, 2004 4:37 AM To: Paul.D.Smith@dataconnection.com; brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] RE: [Sip-implementors] Via: processing I guess putting FQDN or IP addresses in the Via header driven by the tradeoff between overhead in DNS query for FQDN name but provides robustness or direct usage of IP address which lead to undeliverable in case intermediate entities failure.=20 It's my feeling, please correct me if I am wrong.... Thanks & Regards, Nataraju A.B.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Paul D.Smith Sent: Friday, January 30, 2004 9:56 PM To: 'brett@broadsoft.com' Cc: SIP WG Subject: [Sip] RE: [Sip-implementors] Via: processing Brett, Arlie, RFC3261 clearly allows a response to be "rerouted" if it can be determined that the response did not reach the first-attempt target. For example, if the request is received over TCP, and the connection has gone and cannot be reestablished by the time the response is ready to be sent back, RFC3261 states the following --- from RFC3261, section 18.2.2, 1st bullet. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. --- end of cut RFC3263 then gives an algorithm for attempting to determine alternate IP addresses to which the response might be sent. Clearly having an FQDN in the sent-by will give a chance of success which having an IP address will not, especially if the sent-by and received IP addresses are the same! Paul DS. Paul D.Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: 29 January 2004 00:27 To: SIP (E-mail) Subject: RE: [Sip-implementors] Via: processing > I'm looking at the spec for Via: processing. > RFC 3261 clearly shows that a Via: line can=20 > contain DNS names, as well as textual > representations of network addresses. >=20 > How many products actually implement support > for resolving DNS names provided in Via: lines? =20 Not very many support DNS resolution of a Via entry. However many support the concept of adding the Via's received parameter when it does not match the Via's sent-by address. > This seems... well, it seems unnecessary, > potentially insecure (allowing for easy DDoS > and potentially amplification attacks), and=20 > just a general nuisance. Is this kind of > thing ever actually used for a good purpose? =20 Some people have toyed with the idea of advancing response addresses based upon rfc3263 during failure situations. > Does any product do anything *but* just put > real network addresses in Via: lines in > requests? Yes. _______________________________________________ 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 13 02:59:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27383 for ; Fri, 13 Feb 2004 02:59:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYDj-0002dF-SO for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 02:58:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D7whXd010116 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 02:58:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYD4-0002Sj-22; Fri, 13 Feb 2004 02:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYCv-0002S0-3c for sip@optimus.ietf.org; Fri, 13 Feb 2004 02:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27340 for ; Fri, 13 Feb 2004 02:57:47 -0500 (EST) From: Matthew.Gardiner@aculab.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYCn-0004aF-00 for sip@ietf.org; Fri, 13 Feb 2004 02:57:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYBu-0004W4-00 for sip@ietf.org; Fri, 13 Feb 2004 02:56:51 -0500 Received: from [213.249.233.131] (helo=mx0.aculab.com) by ietf-mx with esmtp (Exim 4.12) id 1ArYBU-0004Rc-00 for sip@ietf.org; Fri, 13 Feb 2004 02:56:24 -0500 Received: from localhost (io.aculab.com [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id 4D35D41D7; Fri, 13 Feb 2004 08:03:58 +0000 (GMT) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05175-07; Fri, 13 Feb 2004 08:03:53 +0000 (GMT) Received: from saturn.aculab.com (unknown [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 343A541EC; Fri, 13 Feb 2004 08:03:53 +0000 (GMT) Received: by saturn.aculab.com with Internet Mail Service (5.5.2655.55) id <1S9PWT6N>; Fri, 13 Feb 2004 07:57:02 -0000 Message-ID: <8C9A566C643ED6119E8900A0C9DE297A01F86467@saturn.aculab.com> To: nataraju.alilaghatta@wipro.com Cc: sip@ietf.org, cthakker@ipnetfusion.com Subject: RE: [Sip] Record-Route and Contact Date: Fri, 13 Feb 2004 07:56:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F206.F1DCA280" X-Aculab-Com-Scanned: by amavisd-new-20030616-p5 (Debian) at aculab.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,CLICK_BELOW,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F206.F1DCA280 Content-Type: text/plain; charset="iso-8859-1" I was under the impression that the Route header is to be used in order that UAs can influence the route taken (subsequent to initial INVITE) to include particular proxy/proxies. To me, that's what 20.34 (of 3261) implies. Are you saying that somewhere in 3261 it states that the Contact info in the 200-INVITE be used to build a "Route:" header for later insertion into, for example, an ACK request? -----Original Message----- From: nataraju.alilaghatta@wipro.com [mailto:nataraju.alilaghatta@wipro.com] Sent: 12 February 2004 22:46 To: Matthew.Gardiner@aculab.com; cthakker@ipnetfusion.com Cc: sip@ietf.org Subject: RE: [Sip] Record-Route and Contact Thanks & Regards, Nataraju A.B. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Matthew.Gardiner@aculab.com Sent: Thursday, February 12, 2004 1:09 PM To: cthakker@ipnetfusion.com Cc: sip@ietf.org Subject: RE: [Sip] Record-Route and Contact It's my understanding that Record-Route headers take precedence over the IP/FQDN in the contact header of the response, as they (Record-Route headers) are inserted by specifically by the proxies in order to influence the route that subsequent messaging takes. They influence, not only the route taken by the ACK, furthermore that taken by any subsequent requests. [ABN] once 200 for INVITE is received it forms the Route header for further requests sent in the same dialog. The logic to form Route header is been clearly mentioned in the Rfc3261 and the contact information in 200-INVITE forms the Req-URI for subsequent requests. -----Original Message----- From: cthakker [ mailto:cthakker@ipnetfusion.com ] Sent: 11 February 2004 21:05 To: sip@ietf.org Subject: [Sip] Record-Route and Contact Hi all, If a UAC generates a request in Dialog (say an ACK for 200 it received), If the 200 had a Record-Route with loose routing and also a Contact header where should it route the request ? Can it route it directly to the IP/FQDN specified in the uri of Contact ? Does any header take precedence over other when generating a subsequent request in a Dialog ? Is the significance of Contact header end-to-end or between UAs. For the example given in the RFC 3261 (alice and bob), can the intermediate proxies modify the value of the Contact header in the response sent by Alice to Bob ? Thank you, Chintan ipNetFusion Inc, Dallas, Tx - 75080 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm . Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm. ------_=_NextPart_001_01C3F206.F1DCA280 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Record-Route and Contact
I was under the impression that the Route header is to be used in order that UAs can influence the route taken (subsequent to initial INVITE) to include particular proxy/proxies. To me, that's what 20.34 (of 3261) implies.
 
Are you saying that somewhere in 3261 it states that the Contact info in the 200-INVITE be used to build a "Route:" header for later insertion into, for example, an ACK request?   
-----Original Message-----
From: nataraju.alilaghatta@wipro.com [mailto:nataraju.alilaghatta@wipro.com]
Sent: 12 February 2004 22:46
To: Matthew.Gardiner@aculab.com; cthakker@ipnetfusion.com
Cc: sip@ietf.org
Subject: RE: [Sip] Record-Route and Contact

 

 

Thanks & Regards,
Nataraju A.B.

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Matthew.Gardiner@aculab.com
Sent: Thursday, February 12, 2004 1:09 PM
To: cthakker@ipnetfusion.com
Cc: sip@ietf.org
Subject: RE: [Sip] Record-Route and Contact

 

It's my understanding that Record-Route headers take precedence over the IP/FQDN in the contact header of the response, as they (Record-Route headers) are inserted by specifically by the proxies in order to influence the route that subsequent messaging takes. They influence, not only the route taken by the ACK, furthermore that taken by any subsequent requests.

[ABN] once 200 for INVITE is received it forms the Route header for further requests sent in the same dialog. The logic to form Route header is been clearly mentioned in the Rfc3261 and the contact information in 200-INVITE forms the Req-URI for subsequent requests.

-----Original Message-----
From: cthakker [mailto:cthakker@ipnetfusion.com]
Sent: 11 February 2004 21:05
To: sip@ietf.org
Subject: [Sip] Record-Route and Contact

 

Hi all,
 If a UAC generates a request in Dialog (say an ACK for 200 it received),
 
 If the 200 had a Record-Route with loose routing and also a Contact
header where should it route the request ? Can it route it directly to
the IP/FQDN specified in the uri of Contact ? Does any header take
precedence over other when generating a subsequent request in a Dialog ?
 Is the significance of Contact header end-to-end or between UAs. For
the example given in the RFC 3261 (alice and bob), can the intermediate
proxies modify the value of the Contact header in the response sent by
Alice to Bob ?

 Thank you,

 Chintan
 ipNetFusion Inc,
 Dallas, Tx - 75080

 

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

 

For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.

 

Confidentiality Notice


The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.


For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.



------_=_NextPart_001_01C3F206.F1DCA280-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 13 03:43:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28717 for ; Fri, 13 Feb 2004 03:43:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYuR-0005tm-Hi for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 03:42:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D8gpGU022675 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 03:42:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYtf-0005na-AQ; Fri, 13 Feb 2004 03:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYta-0005n7-8K for sip@optimus.ietf.org; Fri, 13 Feb 2004 03:41:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28670 for ; Fri, 13 Feb 2004 03:41:52 -0500 (EST) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYtS-0000PU-00 for sip@ietf.org; Fri, 13 Feb 2004 03:41:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYsV-0000K6-00 for sip@ietf.org; Fri, 13 Feb 2004 03:40:53 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1ArYrV-0000Ar-00 for sip@ietf.org; Fri, 13 Feb 2004 03:39:50 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1D8dDPp026420 for ; Fri, 13 Feb 2004 14:09:15 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 13 Feb 2004 14:10:31 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 14:08:53 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F20C.CFBCC490" Subject: RE: [Sip] Record-Route and Contact Date: Fri, 13 Feb 2004 14:08:53 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEADF31212@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] Record-Route and Contact Thread-Index: AcPyCE8FovK5WHe6RrGr2qgkEbRDBQAASV8w To: Cc: , X-OriginalArrivalTime: 13 Feb 2004 08:38:53.0656 (UTC) FILETIME=[CFD02580:01C3F20C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,CLICK_BELOW,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F20C.CFBCC490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Thanks & Regards, Nataraju A.B.=20 -----Original Message----- From: Matthew.Gardiner@aculab.com [mailto:Matthew.Gardiner@aculab.com]=20 Sent: Friday, February 13, 2004 1:27 PM To: Nataraju Alilaghatta (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) Cc: sip@ietf.org; cthakker@ipnetfusion.com Subject: RE: [Sip] Record-Route and Contact =20 I was under the impression that the Route header is to be used in order that UAs can influence the route taken (subsequent to initial INVITE) to include particular proxy/proxies. To me, that's what 20.34 (of 3261) implies. =20 [ABN] You are right... =20 Are you saying that somewhere in 3261 it states that the Contact info in the 200-INVITE be used to build a "Route:" header for later insertion into, for example, an ACK request? =20 =20 [ABN] No... The contact serves the initial Req-URI for subsequent requests within dialog but then again while the finding next hop's address Route header (if there is one) takes precedence over Req-Uri. The top route header might modify the Req-URI if top route header is a strict router. =20 =20 -----Original Message----- From: nataraju.alilaghatta@wipro.com [mailto:nataraju.alilaghatta@wipro.com] Sent: 12 February 2004 22:46 To: Matthew.Gardiner@aculab.com; cthakker@ipnetfusion.com Cc: sip@ietf.org Subject: RE: [Sip] Record-Route and Contact =20 =20 Thanks & Regards, Nataraju A.B.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Matthew.Gardiner@aculab.com Sent: Thursday, February 12, 2004 1:09 PM To: cthakker@ipnetfusion.com Cc: sip@ietf.org Subject: RE: [Sip] Record-Route and Contact =20 It's my understanding that Record-Route headers take precedence over the IP/FQDN in the contact header of the response, as they (Record-Route headers) are inserted by specifically by the proxies in order to influence the route that subsequent messaging takes. They influence, not only the route taken by the ACK, furthermore that taken by any subsequent requests. [ABN] once 200 for INVITE is received it forms the Route header for further requests sent in the same dialog. The logic to form Route header is been clearly mentioned in the Rfc3261 and the contact information in 200-INVITE forms the Req-URI for subsequent requests.=20 -----Original Message-----=20 From: cthakker [mailto:cthakker@ipnetfusion.com]=20 Sent: 11 February 2004 21:05=20 To: sip@ietf.org=20 Subject: [Sip] Record-Route and Contact=20 =20 Hi all,=20 If a UAC generates a request in Dialog (say an ACK for 200 it received),=20 =20 If the 200 had a Record-Route with loose routing and also a Contact=20 header where should it route the request ? Can it route it directly to=20 the IP/FQDN specified in the uri of Contact ? Does any header take=20 precedence over other when generating a subsequent request in a Dialog ? Is the significance of Contact header end-to-end or between UAs. For=20 the example given in the RFC 3261 (alice and bob), can the intermediate=20 proxies modify the value of the Contact header in the response sent by=20 Alice to Bob ?=20 Thank you,=20 Chintan=20 ipNetFusion Inc,=20 Dallas, Tx - 75080=20 =20 _______________________________________________=20 Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol=20 Use sip-implementors@cs.columbia.edu for questions on current sip=20 Use sipping@ietf.org for new developments on the application of sip=20 =20 For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.=20 =20 Confidentiality Notice =20 =20 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. =20 For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.=20 ------_=_NextPart_001_01C3F20C.CFBCC490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] Record-Route and Contact

 

Thanks & Regards,
Nataraju A.B.

-----Original = Message-----
From: Matthew.Gardiner@aculab.com= = [mailto:Matthew.Gardiner@aculab.com= ]
Sent: Friday, February 13, 2004 1:27 PM
To: Nataraju Alilaghatta (WT01 - TELECOM & INTER-NETWORKING = SOLUTIONS)
Cc: sip@ietf.org; = cthakker@ipnetfusion.com
Subject: RE: [Sip] = Record-Route and Contact

 

I was under the impression that the Route header is to be used in order that UAs can influence the route taken (subsequent to initial INVITE) to include particular proxy/proxies. To me, that's what 20.34 (of = 3261) implies.

 

 [ABN] You are = right…

 

Are you saying = that somewhere in 3261 it states that the Contact info in the 200-INVITE be = used to build a "Route:" header for later insertion into, for = example, an ACK request?   

     

[ABN] No... The contact serves the initial Req-URI for subsequent requests within dialog but then again while the finding next hop’s address Route header (if there is one) takes precedence over = Req-Uri. The top route header might modify the Req-URI if top route header is a = strict router.

 

 

-----Original Message-----
From: nataraju.alilaghatta@wipro.com = [mailto:nataraju.alilaghatta@wipro.com]
Sent: 12 February 2004 22:46
To: Matthew.Gardiner@aculab.com= ; cthakker@ipnetfusion.com
Cc: sip@ietf.org
Subject: RE: [Sip] = Record-Route and Contact

 

 

Thanks = & Regards,
Nataraju A.B.

-----Original = Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of Matthew.Gardiner@aculab.com=
Sent: Thursday, February = 12, 2004 1:09 PM
To: cthakker@ipnetfusion.com
Cc: sip@ietf.org
Subject: RE: [Sip] = Record-Route and Contact

 

It's my understanding that Record-Route = headers take precedence over the IP/FQDN in the contact header of the response, as = they (Record-Route headers) are inserted by specifically by the proxies in = order to influence the route that subsequent messaging takes. They influence, not = only the route taken by the ACK, furthermore that taken by any subsequent = requests.

[ABN] = once 200 for INVITE is received it forms the Route header for further requests sent = in the same dialog. The logic to form Route header is been clearly mentioned in = the Rfc3261 and the contact information in 200-INVITE forms the Req-URI for subsequent requests.

-----Original Message-----
From: cthakker [mailto:cthakker@ipnetfusion.com<= /a>]
Sent: 11 February 2004 = 21:05
To: = sip@ietf.org
Subject: [Sip] = Record-Route and Contact

 

Hi all,
 If a UAC generates = a request in Dialog (say an ACK for 200 it received),
  =
 If the 200 had a = Record-Route with loose routing and also a Contact
header where should it = route the request ? Can it route it directly to
the IP/FQDN specified in = the uri of Contact ? Does any header take
precedence over other = when generating a subsequent request in a Dialog ?
 Is the = significance of Contact header end-to-end or between UAs. For
the example given in the = RFC 3261 (alice and bob), can the intermediate
proxies modify the value = of the Contact header in the response sent by
Alice to Bob = ?

 Thank you,

 Chintan
 ipNetFusion = Inc,
 Dallas, Tx - = 75080

 

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

 

For Aculab's privacy policy = and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.

 

Confidentiality Notice
 
 
The =
information contained in this electronic message and any attachments to =
this message are intended
for the exclusive use of the addressee(s) and may contain =
confidential or privileged information. If
you are not the intended recipient, please notify the =
sender at Wipro or Mailadmin@wipro.com =
immediately
and destroy all copies of this message and any =
attachments.

 



For Aculab's privacy policy and = E-Mail disclaimer, Click Here : = http://www.aculab.com/company/legal_notice.htm.



------_=_NextPart_001_01C3F20C.CFBCC490-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 13 10:41:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15512 for ; Fri, 13 Feb 2004 10:41:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfRX-0005Tl-FL for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 10:41:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFfRvD020997 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 10:41:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfR9-0005Oz-1C; Fri, 13 Feb 2004 10:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfQE-0005Lv-ML for sip@optimus.ietf.org; Fri, 13 Feb 2004 10:40:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15442 for ; Fri, 13 Feb 2004 10:40:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfQC-0003Xe-00 for sip@ietf.org; Fri, 13 Feb 2004 10:40:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfPD-0003U8-00 for sip@ietf.org; Fri, 13 Feb 2004 10:39:03 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1ArfOi-0003QN-00 for sip@ietf.org; Fri, 13 Feb 2004 10:38:32 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4]) by broadsoft.com (8.12.10/8.12.9) with SMTP id i1DFcWNe041499 for ; Fri, 13 Feb 2004 10:38:32 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] RE: [Sip-implementors] Via: processing Date: Fri, 13 Feb 2004 10:41:40 -0500 Message-ID: <004a01c3f247$dfd45420$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <10C4348A1BA43A4FA8D5B767E052CEADEDB398@blr-ec-msg04.wipro.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I guess putting FQDN or IP addresses in > the Via header driven by the tradeoff between > overhead in DNS query for FQDN name but provides > robustness or direct usage of IP address which > lead to undeliverable in case intermediate > entities failure. > > It's my feeling, please correct me if I am wrong.... The Via's sent-by FQDN only needs to be resolved during failure situations since the locally added "received" parameter would be tried before the sent-by. Thus providing an FQDN within the Via's sent-by does not really cause any overhead beyond the extra "received" parameter getting added to proxied Via entries. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 13 11:12:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17195 for ; Fri, 13 Feb 2004 11:12:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfvH-0000Dd-3F for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 11:12:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGCAsV000776 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 11:12:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfv7-00006c-HA; Fri, 13 Feb 2004 11:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfuT-0008WL-TL for sip@optimus.ietf.org; Fri, 13 Feb 2004 11:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17021 for ; Fri, 13 Feb 2004 11:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfuQ-000690-00 for sip@ietf.org; Fri, 13 Feb 2004 11:11:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArftP-00063Y-00 for sip@ietf.org; Fri, 13 Feb 2004 11:10:15 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1Arfso-0005yr-00 for sip@ietf.org; Fri, 13 Feb 2004 11:09:38 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i1DG97Dm014808; Fri, 13 Feb 2004 10:09:07 -0600 (CST) Message-ID: <402CF6A2.3060805@alcatel.com> Date: Fri, 13 Feb 2004 10:09:06 -0600 From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com, sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-publish-02.txt comments Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, Current version of SIP-PUBLISH as specified in draft-ietf-sip-publish-02.txt leaves out composer policy as out-of-scope. Can this lead to interoperability issues? If so, I suggest the draft defines some basic composer policy structure. Regards, Alex. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 13 13:26:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23971 for ; Fri, 13 Feb 2004 13:26:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ari0R-0003tf-14 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 13:25:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIPdx3014975 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 13:25:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhzs-0003qB-Ch; Fri, 13 Feb 2004 13:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhz7-0003dP-Kn for sip@optimus.ietf.org; Fri, 13 Feb 2004 13:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23908 for ; Fri, 13 Feb 2004 13:24:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arhz5-0003ST-00 for sip@ietf.org; Fri, 13 Feb 2004 13:24:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arhy4-0003Oa-00 for sip@ietf.org; Fri, 13 Feb 2004 13:23:14 -0500 Received: from [63.126.135.16] (helo=mail1.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1ArhxY-0003K2-00 for sip@ietf.org; Fri, 13 Feb 2004 13:22:40 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i1DILcTl024963; Fri, 13 Feb 2004 10:21:45 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Feb 2004 10:21:38 -0800 Message-ID: <017B1BB60535DF4285666089FA048AC20172EFE5@SONOMA.netscreen.com> From: Anil Bollineni To: "'Matthew.Gardiner@aculab.com'" , nataraju.alilaghatta@wipro.com Cc: sip@ietf.org, cthakker@ipnetfusion.com Subject: RE: [Sip] Record-Route and Contact Date: Fri, 13 Feb 2004 10:21:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F25E.38544400" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,CLICK_BELOW,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F25E.38544400 Content-Type: text/plain I believe Contact info is used to build a request URI and same set of URI's in Record-Route are used to build a Route header. If there is no Contact, the URI's in Record Route are used to build request URI. Regards, Anil This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. -----Original Message----- From: Matthew.Gardiner@aculab.com [mailto:Matthew.Gardiner@aculab.com] Sent: Thursday, February 12, 2004 11:57 PM To: nataraju.alilaghatta@wipro.com Cc: sip@ietf.org; cthakker@ipnetfusion.com Subject: RE: [Sip] Record-Route and Contact I was under the impression that the Route header is to be used in order that UAs can influence the route taken (subsequent to initial INVITE) to include particular proxy/proxies. To me, that's what 20.34 (of 3261) implies. Are you saying that somewhere in 3261 it states that the Contact info in the 200-INVITE be used to build a "Route:" header for later insertion into, for example, an ACK request? -----Original Message----- From: nataraju.alilaghatta@wipro.com [mailto:nataraju.alilaghatta@wipro.com] Sent: 12 February 2004 22:46 To: Matthew.Gardiner@aculab.com; cthakker@ipnetfusion.com Cc: sip@ietf.org Subject: RE: [Sip] Record-Route and Contact Thanks & Regards, Nataraju A.B. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Matthew.Gardiner@aculab.com Sent: Thursday, February 12, 2004 1:09 PM To: cthakker@ipnetfusion.com Cc: sip@ietf.org Subject: RE: [Sip] Record-Route and Contact It's my understanding that Record-Route headers take precedence over the IP/FQDN in the contact header of the response, as they (Record-Route headers) are inserted by specifically by the proxies in order to influence the route that subsequent messaging takes. They influence, not only the route taken by the ACK, furthermore that taken by any subsequent requests. [ABN] once 200 for INVITE is received it forms the Route header for further requests sent in the same dialog. The logic to form Route header is been clearly mentioned in the Rfc3261 and the contact information in 200-INVITE forms the Req-URI for subsequent requests. -----Original Message----- From: cthakker [mailto:cthakker@ipnetfusion.com ] Sent: 11 February 2004 21:05 To: sip@ietf.org Subject: [Sip] Record-Route and Contact Hi all, If a UAC generates a request in Dialog (say an ACK for 200 it received), If the 200 had a Record-Route with loose routing and also a Contact header where should it route the request ? Can it route it directly to the IP/FQDN specified in the uri of Contact ? Does any header take precedence over other when generating a subsequent request in a Dialog ? Is the significance of Contact header end-to-end or between UAs. For the example given in the RFC 3261 (alice and bob), can the intermediate proxies modify the value of the Contact header in the response sent by Alice to Bob ? Thank you, Chintan ipNetFusion Inc, Dallas, Tx - 75080 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm . Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm. ------_=_NextPart_001_01C3F25E.38544400 Content-Type: text/html RE: [Sip] Record-Route and Contact

I believe Contact info is used to build a request URI and same set of URI's in Record-Route are used to build a Route header. If there is no Contact, the URI's in Record Route are used to build request URI.

 

Regards,

Anil

 

This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information.

-----Original Message-----
From: Matthew.Gardiner@aculab.com [mailto:Matthew.Gardiner@aculab.com]
Sent: Thursday, February 12, 2004 11:57 PM
To: nataraju.alilaghatta@wipro.com
Cc: sip@ietf.org; cthakker@ipnetfusion.com
Subject: RE: [Sip] Record-Route and Contact

 

I was under the impression that the Route header is to be used in order that UAs can influence the route taken (subsequent to initial INVITE) to include particular proxy/proxies. To me, that's what 20.34 (of 3261) implies.

 

Are you saying that somewhere in 3261 it states that the Contact info in the 200-INVITE be used to build a "Route:" header for later insertion into, for example, an ACK request?   

-----Original Message-----
From: nataraju.alilaghatta@wipro.com [mailto:nataraju.alilaghatta@wipro.com]
Sent: 12 February 2004 22:46
To: Matthew.Gardiner@aculab.com; cthakker@ipnetfusion.com
Cc: sip@ietf.org
Subject: RE: [Sip] Record-Route and Contact

 

 

Thanks & Regards,
Nataraju A.B.

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Matthew.Gardiner@aculab.com
Sent: Thursday, February 12, 2004 1:09 PM
To: cthakker@ipnetfusion.com
Cc: sip@ietf.org
Subject: RE: [Sip] Record-Route and Contact

 

It's my understanding that Record-Route headers take precedence over the IP/FQDN in the contact header of the response, as they (Record-Route headers) are inserted by specifically by the proxies in order to influence the route that subsequent messaging takes. They influence, not only the route taken by the ACK, furthermore that taken by any subsequent requests.

[ABN] once 200 for INVITE is received it forms the Route header for further requests sent in the same dialog. The logic to form Route header is been clearly mentioned in the Rfc3261 and the contact information in 200-INVITE forms the Req-URI for subsequent requests.

-----Original Message-----
From: cthakker [mailto:cthakker@ipnetfusion.com]
Sent: 11 February 2004 21:05
To: sip@ietf.org
Subject: [Sip] Record-Route and Contact

 

Hi all,
 If a UAC generates a request in Dialog (say an ACK for 200 it received),
 
 If the 200 had a Record-Route with loose routing and also a Contact
header where should it route the request ? Can it route it directly to
the IP/FQDN specified in the uri of Contact ? Does any header take
precedence over other when generating a subsequent request in a Dialog ?
 Is the significance of Contact header end-to-end or between UAs. For
the example given in the RFC 3261 (alice and bob), can the intermediate
proxies modify the value of the Contact header in the response sent by
Alice to Bob ?

 Thank you,

 Chintan
 ipNetFusion Inc,
 Dallas, Tx - 75080

 

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

 

For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.

 

Confidentiality Notice
 
 
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.

 



For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm.



------_=_NextPart_001_01C3F25E.38544400-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 13 14:11:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26456 for ; Fri, 13 Feb 2004 14:11:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriiY-0000HB-5e for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 14:11:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DJBEnX000997 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 14:11:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriiN-0000Dt-Fg; Fri, 13 Feb 2004 14:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArihY-0000C0-4X for sip@optimus.ietf.org; Fri, 13 Feb 2004 14:10:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26419 for ; Fri, 13 Feb 2004 14:10:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArihV-0007JU-00 for sip@ietf.org; Fri, 13 Feb 2004 14:10:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArigW-0007G6-00 for sip@ietf.org; Fri, 13 Feb 2004 14:09:09 -0500 Received: from [63.126.135.16] (helo=mail1.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1Arifz-0007AI-00 for sip@ietf.org; Fri, 13 Feb 2004 14:08:35 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i1DJ7mTl000360 for ; Fri, 13 Feb 2004 11:07:54 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Feb 2004 11:07:48 -0800 Message-ID: <017B1BB60535DF4285666089FA048AC20172EFE6@SONOMA.netscreen.com> From: Anil Bollineni To: "'sip@ietf.org'" Date: Fri, 13 Feb 2004 11:07:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F264.AB1D2050" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] Changing Via In NAT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C3F264.AB1D2050 Content-Type: text/plain Dear All, In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT traversal. The received and rport parameter are used to send back the responses correctly. However if we don't use these extensions, and change the via ip address and port with that of firewall/port then the SIP responses will come directly to firewall, in that case the firewall permits the responses. UA1 inside the network sends requests to firewall/NAT. UA1 INVITE sip:user@domain.com SIP/2.0 ----------------> Firewall/NAT ----------------------------------------------->UA2 Via: SIP/2.0/UDP 10.1.1.1:4540 INVITE sip:user@domain.com SIP/2.0 Via: SIP/2.0/UDP firewall_ip:5060 (Maintain mapping) the UA2 will send the responses to firewall/NAT and firewall/NAT will write back the addresses in Via to original IP/port. I understand from the draft, if there are no SIP ALG functionality in firewall, then the extensions are used to make SIP traverse through NAT. However if we implement SIP ALG in firewall then we can make SIP traverse through NAT. Can anybody tell that this way is per SIP spec. Thank you, Anil This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. ------_=_NextPart_001_01C3F264.AB1D2050 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Dear All,

 

In draft-ietf-sip-nat-01.txt, there are SIP = extensions for NAT traversal. The received and rport parameter are used to send back = the responses correctly. However if we don't use these extensions, and = change the via ip address and port with that of firewall/port then the SIP = responses will come directly to firewall, in that case the firewall permits the responses. UA1 inside the network sends requests to = firewall/NAT.

 

UA1

INVITE sip:user@domain.com SIP/2.0 = --------------à<= font size=3D2 face=3DArial> Firewall/NAT =             =   ---------------------------------------------à<= font size=3D2 face=3DArial>UA2

Via: SIP/2.0/UDP = 10.1.1.1:4540          = ;            = ;    INVITE sip:user@domain.com SIP/2.0 =             =             =    

Via: = SIP/2.0/UDP firewall_ip:5060

         = ;            = ;            = ;            = ;            = ;            = ;   (Maintain mapping)

 

the UA2 will send the responses to firewall/NAT and firewall/NAT will write back the addresses in Via to original IP/port. = I understand from the draft, if there are no SIP ALG functionality in = firewall, then the extensions are used to make SIP traverse through NAT. However if we implement SIP ALG in firewall then we can make SIP traverse through = NAT. Can anybody tell that this way is per SIP spec.

 

Thank you,

Anil

 

This email contains material that is confidential. The content of this email = is for the sole use of the intended recipient(s). Any review or distribution = by persons other than the intended recipient(s) without the express = permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all = copies of this email and any related attachments. NetScreen does not guarantee = the accuracy or completeness of third party materials or = information.

 

------_=_NextPart_001_01C3F264.AB1D2050-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 13 16:01:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03083 for ; Fri, 13 Feb 2004 16:01:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkQw-0002TR-VW for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 16:01:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DL1ABA009446 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 16:01:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkQo-0002Qg-CG; Fri, 13 Feb 2004 16:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkQ0-0002Lo-U5 for sip@optimus.ietf.org; Fri, 13 Feb 2004 16:00:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03012 for ; Fri, 13 Feb 2004 16:00:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkPy-0001D7-00 for sip@ietf.org; Fri, 13 Feb 2004 16:00:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkP5-000193-00 for sip@ietf.org; Fri, 13 Feb 2004 15:59:16 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArkOB-00015J-00 for sip@ietf.org; Fri, 13 Feb 2004 15:58:19 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DKwJv20566 for ; Fri, 13 Feb 2004 22:58:19 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 22:58:18 +0200 Received: from nokia.com ([172.21.81.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 22:58:18 +0200 Message-ID: <402D3A6A.4070303@nokia.com> Date: Fri, 13 Feb 2004 22:58:18 +0200 From: Aki Niemi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: sip@ietf.org References: <402CF6A2.3060805@alcatel.com> In-Reply-To: <402CF6A2.3060805@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 20:58:18.0419 (UTC) FILETIME=[1B45C030:01C3F274] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-publish-02.txt comments Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Inline. ext Alex Audu wrote: > Folks, > > Current version of SIP-PUBLISH as specified in > draft-ietf-sip-publish-02.txt leaves out > composer policy as out-of-scope. Can this lead to interoperability > issues? If so, I suggest > the draft defines some basic composer policy structure. You're right in that the current draft leaves composer policy (both defining it or setting/changing it) out-of-scope. As to whether it leads to interop problems, probably not as far as PUBLISH is concerned. So any interop problems would be in terms of PIDF and what the PUA is expecting the watchers to see when it publishes certain tuples. So this is very presence specific. And for presence, it isn't really clear yet as to how the composer would go about resolving conflicts among the tuples coming from different sources. By not doing any sort of merging or selection among the tuples might work, so the default policy could be that a composer simply passes all tuples to watchers intact. But I don't know how helpful, or indeed what the proper way to state this default policy would be. Any suggestions? Cheers, Aki > Regards, > Alex. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 13 17:00:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09520 for ; Fri, 13 Feb 2004 17:00:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlM6-0008Uw-VU for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 17:00:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DM0DJ8032606 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 17:00:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlLy-0008Ri-JP; Fri, 13 Feb 2004 17:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlLB-0008PE-Fb for sip@optimus.ietf.org; Fri, 13 Feb 2004 16:59:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09425 for ; Fri, 13 Feb 2004 16:59:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlL9-0001WV-00 for sip@ietf.org; Fri, 13 Feb 2004 16:59:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlKG-0001Ra-00 for sip@ietf.org; Fri, 13 Feb 2004 16:58:20 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1ArlJT-0001Im-00 for sip@ietf.org; Fri, 13 Feb 2004 16:57:31 -0500 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1DLwZsa008982; Fri, 13 Feb 2004 15:58:35 -0600 Message-ID: <402D488A.7000700@softarmor.com> Date: Fri, 13 Feb 2004 15:58:34 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org CC: rohan@cisco.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Agenda Requests for SIP at IETF 59 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've started layong out the SIP WG supplemental web site for IETF 59 at the usual place: http://www.softarmor.com/sipwg/meets/ietf59/index.html This page includes a link for "Agenda Requests", which I shall try to keep up-to-date as requests are made. Remember -- we should use meeting time NOT to introduce new ideas, but to discuss issues that we just haven't been able to work out on the mailing list. If you have something that you think needs to be talked about in the meeting, please send me a request using the html template given below. Please include a link to the relevant draft, so that we can put together a "reading list". Here's the template, which I blatantly copied from Gonzalo's note to SIPPING: Gonzalo Camarillo Exploders
5
draft-camarillo-sipping-exploders-02.txt If the HTML here confuses you, fake it and I'll try and sort it out. 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 exim@www1.ietf.org Fri Feb 13 19:37:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17013 for ; Fri, 13 Feb 2004 19:37:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arno0-0001Y1-Lr for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 19:37:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1E0bCiL005878 for sip-archive@odin.ietf.org; Fri, 13 Feb 2004 19:37:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arnnq-0001Tu-Fk; Fri, 13 Feb 2004 19:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arnn8-0001RY-GI for sip@optimus.ietf.org; Fri, 13 Feb 2004 19:36:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16996 for ; Fri, 13 Feb 2004 19:36:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arnn6-0005SQ-00 for sip@ietf.org; Fri, 13 Feb 2004 19:36:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arnm9-0005PS-00 for sip@ietf.org; Fri, 13 Feb 2004 19:35:18 -0500 Received: from [63.126.135.16] (helo=mail1.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1ArnlU-0005KD-00 for sip@ietf.org; Fri, 13 Feb 2004 19:34:36 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i1E0XnTl002705 for ; Fri, 13 Feb 2004 16:34:05 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Feb 2004 16:33:49 -0800 Message-ID: <017B1BB60535DF4285666089FA048AC20172EFE7@SONOMA.netscreen.com> From: Anil Bollineni To: "'sip@ietf.org'" Date: Fri, 13 Feb 2004 16:33:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F292.35C2ED20" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] FW: Changing Via In NAT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C3F292.35C2ED20 Content-Type: text/plain Hi Guys, Can anybody have some comments about the discussion below. Thanks in Advance, Anil This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. -----Original Message----- From: Anil Bollineni Sent: Friday, February 13, 2004 11:08 AM To: 'sip@ietf.org' Subject: Changing Via In NAT Dear All, In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT traversal. The received and rport parameter are used to send back the responses correctly. However if we don't use these extensions, and change the via ip address and port with that of firewall/port then the SIP responses will come directly to firewall, in that case the firewall permits the responses. UA1 inside the network sends requests to firewall/NAT. UA1 INVITE sip:user@domain.com SIP/2.0 ----------------> Firewall/NAT ----------------------------------------------->UA2 Via: SIP/2.0/UDP 10.1.1.1:4540 INVITE sip:user@domain.com SIP/2.0 Via: SIP/2.0/UDP firewall_ip:5060 (Maintain mapping) the UA2 will send the responses to firewall/NAT and firewall/NAT will write back the addresses in Via to original IP/port. I understand from the draft, if there are no SIP ALG functionality in firewall, then the extensions are used to make SIP traverse through NAT. However if we implement SIP ALG in firewall then we can make SIP traverse through NAT. Can anybody tell that this way is per SIP spec. Thank you, Anil This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. ------_=_NextPart_001_01C3F292.35C2ED20 Content-Type: text/html

Hi Guys,

 

  Can anybody have some comments about the discussion below.

 

Thanks in Advance,

Anil

 

This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information.

-----Original Message-----
From: Anil Bollineni
Sent: Friday, February 13, 2004 11:08 AM
To: 'sip@ietf.org'
Subject: Changing Via In NAT

 

Dear All,

 

In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT traversal. The received and rport parameter are used to send back the responses correctly. However if we don't use these extensions, and change the via ip address and port with that of firewall/port then the SIP responses will come directly to firewall, in that case the firewall permits the responses. UA1 inside the network sends requests to firewall/NAT.

 

UA1

INVITE sip:user@domain.com SIP/2.0 --------------à Firewall/NAT               ---------------------------------------------àUA2

Via: SIP/2.0/UDP 10.1.1.1:4540                          INVITE sip:user@domain.com SIP/2.0                            

Via: SIP/2.0/UDP firewall_ip:5060

                                                                        (Maintain mapping)

 

the UA2 will send the responses to firewall/NAT and firewall/NAT will write back the addresses in Via to original IP/port. I understand from the draft, if there are no SIP ALG functionality in firewall, then the extensions are used to make SIP traverse through NAT. However if we implement SIP ALG in firewall then we can make SIP traverse through NAT. Can anybody tell that this way is per SIP spec.

 

Thank you,

Anil

 

This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information.

 

------_=_NextPart_001_01C3F292.35C2ED20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Feb 14 12:24:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24493 for ; Sat, 14 Feb 2004 12:24:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3Wk-0004Og-Kg for sip-archive@odin.ietf.org; Sat, 14 Feb 2004 12:24:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EHOQ78016840 for sip-archive@odin.ietf.org; Sat, 14 Feb 2004 12:24:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3WO-0004FT-1h; Sat, 14 Feb 2004 12:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3WB-0004EK-RN for sip@optimus.ietf.org; Sat, 14 Feb 2004 12:23:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24486 for ; Sat, 14 Feb 2004 12:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3WA-0003FH-00 for sip@ietf.org; Sat, 14 Feb 2004 12:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3VD-0003CB-00 for sip@ietf.org; Sat, 14 Feb 2004 12:22:52 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1As3UL-00036T-00 for sip@ietf.org; Sat, 14 Feb 2004 12:21:57 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2004 09:30:18 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1EHLO1o016988 for ; Sat, 14 Feb 2004 09:21:26 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn4-702.cisco.com [10.21.82.190]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMJ40698; Sat, 14 Feb 2004 09:21:23 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 13 Feb 2004 08:48:40 -0800 From: Cullen Jennings To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-khartabil-sip-policy-uri-call-info-purpose-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I like this draft, just one little NIT, I think it would be better to call the tag conf-policy-info instead of just policy-info Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 02:14:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26194 for ; Sun, 15 Feb 2004 02:14:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGTv-00059N-00 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 02:14:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F7EMlj019735 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 02:14:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGTa-00051H-8x; Sun, 15 Feb 2004 02:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGSr-0004lC-B0 for sip@optimus.ietf.org; Sun, 15 Feb 2004 02:13:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24816 for ; Sun, 15 Feb 2004 02:13:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsGSn-0005mg-00 for sip@ietf.org; Sun, 15 Feb 2004 02:13:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsGRp-0005j8-00 for sip@ietf.org; Sun, 15 Feb 2004 02:12:14 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AsGQu-0005dA-00 for sip@ietf.org; Sun, 15 Feb 2004 02:11:16 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2004 23:19:48 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1F7Am1m018477 for ; Sat, 14 Feb 2004 23:10:49 -0800 (PST) Received: from [10.0.1.3] (rtp-vpn1-45.cisco.com [10.82.224.45]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMJ51930; Sat, 14 Feb 2004 23:10:47 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 14 Feb 2004 23:03:21 -0800 From: Cullen Jennings To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Binary Encoding for SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I submitted a draft on binary encoding for SIP. This improves interoperability, improves speed, decreases sizes of messages, and generally makes life better for SIP which will no doubt eventually help with World Hunger. I need feedback, please let me know: a) Yah, lets do it b) No this is a stupid ideas and here are the reasons why c) There has not been many list comments, this draft involves some very complex issues. I need a year or two to develop an opinion on the single sentence inside it. d) I agree with Cowboy Willis Until it arrives in the archives, you can find it at http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html or, if you prefer ASCII encodings of everything, www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt Thanks, Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 03:21:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01626 for ; Sun, 15 Feb 2004 03:21:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsHWC-000667-Cv for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 03:20:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F8KmKd023436 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 03:20:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsHVU-000644-Mr; Sun, 15 Feb 2004 03:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsHUj-00062i-Si for sip@optimus.ietf.org; Sun, 15 Feb 2004 03:19:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01597 for ; Sun, 15 Feb 2004 03:19:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsHUh-0002MJ-00 for sip@ietf.org; Sun, 15 Feb 2004 03:19:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsHTm-0002K9-00 for sip@ietf.org; Sun, 15 Feb 2004 03:18:19 -0500 Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx with smtp (Exim 4.12) id 1AsHTQ-0002Hi-00 for sip@ietf.org; Sun, 15 Feb 2004 03:17:56 -0500 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1076827031; Sun Feb 15 10:18:48 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id <12SL5R40>; Sun, 15 Feb 2004 10:13:53 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F38101661A@MAILSERVER> From: Raphael Tryster To: "'Cullen Jennings'" , sip@ietf.org Subject: RE: [Sip] Binary Encoding for SIP Date: Sun, 15 Feb 2004 10:13:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F39B.A609DAD0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F39B.A609DAD0 Content-Type: text/plain Hello Cullen, Given that this is my first venture into the SIP email forum, and the first response to your posting, it is only fitting that I should vote for option c:). During the coming year or two, I hope to develop an opinion on whether the issues of backward compatibility and ease of debugging, which seem to make the binary option rather unpopular in Megaco, apply to SIP as well. If they do, it could have an adverse affect on World Hunger, as those with the right tools to debug binary messages will eat more, at the expense of the rest. Raphael Tryster -----Original Message----- From: Cullen Jennings [SMTP:fluffy@cisco.com] Sent: Sunday, 15 February 2004 9:03 To: sip@ietf.org Subject: [Sip] Binary Encoding for SIP I submitted a draft on binary encoding for SIP. This improves interoperability, improves speed, decreases sizes of messages, and generally makes life better for SIP which will no doubt eventually help with World Hunger. I need feedback, please let me know: a) Yah, lets do it b) No this is a stupid ideas and here are the reasons why c) There has not been many list comments, this draft involves some very complex issues. I need a year or two to develop an opinion on the single sentence inside it. d) I agree with Cowboy Willis Until it arrives in the archives, you can find it at http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html or, if you prefer ASCII encodings of everything, www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt Thanks, 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 ------_=_NextPart_001_01C3F39B.A609DAD0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Binary Encoding for SIP

Hello Cullen,

Given that this is my first venture into= the SIP email forum, and the first response to your posting, it is only = fitting that I should vote for option c:).

During the coming year or two, I hope to= develop an opinion on whether the issues of backward compatibility and e= ase of debugging, which seem to make the binary option rather unpopular i= n Megaco, apply to SIP as well.  If they do, it could have an advers= e affect on World Hunger, as those with the right tools to debug binary m= essages will eat more, at the expense of the rest.

Raphael Tryster

    -----Original Mess= age-----
    From:   Cullen Jennings [S= MTP:fluffy@cisco.com]
    Sent:   Sunday, 15 February 2004 9:03
    To:     sip@ietf.org
    Subject:    &nbs= p;   [Sip] Binary Enco= ding for SIP

       
    I submitted a draft on binary enc= oding for SIP. This improves
    interoperability, improves speed,= decreases sizes of messages, and generally
    makes life better for SIP which w= ill no doubt eventually help with World
    Hunger. I need feedback, please l= et me know:

    a) Yah, lets do it

    b) No this is a stupid ideas and h= ere are the reasons why

    c) There has not been many list co= mments, this draft involves some very
    complex issues. I need a year or = two to develop an opinion on the single
    sentence inside it.

    d) I agree with Cowboy Willis

    Until it arrives in the archives, = you can find it at

    http:/= /www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html

    or, if you prefer ASCII encodings = of everything,

    www.employees.org/~fluffy/ietf/dra= ft-jennings-sip-mime-01.txt

    Thanks, Cullen







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

------_=_NextPart_001_01C3F39B.A609DAD0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 10:46:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15322 for ; Sun, 15 Feb 2004 10:46:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsOTK-0008UJ-SL for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 10:46:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FFkInq032565 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 10:46:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsOT4-0008S6-Qz; Sun, 15 Feb 2004 10:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsOSg-0008RI-Ak for sip@optimus.ietf.org; Sun, 15 Feb 2004 10:45:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15310 for ; Sun, 15 Feb 2004 10:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsOSd-0007SQ-00 for sip@ietf.org; Sun, 15 Feb 2004 10:45:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsORr-0007Nx-00 for sip@ietf.org; Sun, 15 Feb 2004 10:44:48 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AsOR1-0007En-00 for sip@ietf.org; Sun, 15 Feb 2004 10:43:55 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1FFhmR4003817; Sun, 15 Feb 2004 10:43:48 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1FFhmH07799; Sun, 15 Feb 2004 10:43:48 -0500 Message-ID: <402F93B3.20100@cs.columbia.edu> Date: Sun, 15 Feb 2004 10:43:47 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org Subject: Re: [Sip] Binary Encoding for SIP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You should apply for a job at a local tabloid - headlining a discussion on the encoding of MIME body parts into the mother of all mailing list battles on protocol encoding. Given the first reaction to the draft: this is only about the SIP body. Cullen is not proposing that SIP headers be coded in ASN.1 :-) I'm for option (a), for the reasons you mention. The more interesting question is whether all SIP devices still need to be prepared to receive all the various encodings. Cullen Jennings wrote: > > I submitted a draft on binary encoding for SIP. This improves > interoperability, improves speed, decreases sizes of messages, and generally > makes life better for SIP which will no doubt eventually help with World > Hunger. I need feedback, please let me know: > > a) Yah, lets do it > > b) No this is a stupid ideas and here are the reasons why > > c) There has not been many list comments, this draft involves some very > complex issues. I need a year or two to develop an opinion on the single > sentence inside it. > > d) I agree with Cowboy Willis > > Until it arrives in the archives, you can find it at > > http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html > > or, if you prefer ASCII encodings of everything, > > www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt > > Thanks, Cullen > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 12:06:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17824 for ; Sun, 15 Feb 2004 12:06:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsPim-0004G7-K9 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 12:06:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FH6KEi016298 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 12:06:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsPiU-0004Dc-Kp; Sun, 15 Feb 2004 12:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsPi5-0004Cr-0j for sip@optimus.ietf.org; Sun, 15 Feb 2004 12:05:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17800 for ; Sun, 15 Feb 2004 12:05:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsPi3-0005CK-00 for sip@ietf.org; Sun, 15 Feb 2004 12:05:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsPh6-00059Q-00 for sip@ietf.org; Sun, 15 Feb 2004 12:04:37 -0500 Received: from v180.mailsnare.net ([206.246.200.180] helo=mail.mailsnare.net) by ietf-mx with esmtp (Exim 4.12) id 1AsPgN-00053I-00 for sip@ietf.org; Sun, 15 Feb 2004 12:03:51 -0500 Received: from acm.org (c-24-6-103-242.client.comcast.net [24.6.103.242]) by mail.mailsnare.net (Postfix) with ESMTP id B4B0710E6A4; Sun, 15 Feb 2004 17:02:43 +0000 (UTC) Message-ID: <402FA64B.2060907@acm.org> Date: Sun, 15 Feb 2004 09:03:07 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings Cc: sip@ietf.org Subject: Re: [Sip] Binary Encoding for SIP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by Clam AntiVirus X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I thought that binary body was already supported: RFC3261 section 7.4.1, third paragraph. Cullen Jennings wrote: > > I submitted a draft on binary encoding for SIP. This improves > interoperability, improves speed, decreases sizes of messages, and generally > makes life better for SIP which will no doubt eventually help with World > Hunger. I need feedback, please let me know: > > a) Yah, lets do it > > b) No this is a stupid ideas and here are the reasons why > > c) There has not been many list comments, this draft involves some very > complex issues. I need a year or two to develop an opinion on the single > sentence inside it. > > d) I agree with Cowboy Willis > > Until it arrives in the archives, you can find it at > > http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html > > or, if you prefer ASCII encodings of everything, > > www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt > > Thanks, Cullen > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 13:30:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19602 for ; Sun, 15 Feb 2004 13:30:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsR27-00081N-6f for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 13:30:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FIUNTx030771 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 13:30:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsR1n-0007zB-Tm; Sun, 15 Feb 2004 13:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsR1X-0007y4-89 for sip@optimus.ietf.org; Sun, 15 Feb 2004 13:29:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19553 for ; Sun, 15 Feb 2004 13:29:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsR1V-0001uE-00 for sip@ietf.org; Sun, 15 Feb 2004 13:29:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsR0a-0001qR-00 for sip@ietf.org; Sun, 15 Feb 2004 13:28:49 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1AsR0D-0001mD-00 for sip@ietf.org; Sun, 15 Feb 2004 13:28:25 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FIRdB05777 for ; Sun, 15 Feb 2004 12:27:39 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV70DP>; Sun, 15 Feb 2004 12:27:24 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF57900B@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'sip@ietf.org'" Date: Sun, 15 Feb 2004 12:27:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F3F1.5B962DA4" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] Updated History-Info draft submitted Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F3F1.5B962DA4 Content-Type: text/plain; charset="iso-8859-1" I have submitted an updated version of the History-Info draft. Until it becomes available in the respository, you can pick it up at: http://home.comcast.net/~mary.barnes/IETF/draft-ietf-sip-history-info-02.txt The primary changes are as follows: o Merged the SIPPING WG requirements draft into this document. Also, removed redirect server from ISSUER-req since the solution identified this as not being required (or desirable). o Added an explicit privacy requirement (PRIV-req-3) for the proxy's role in recognizing and maintaining privacy associated with a Request-URI being captured in History-Info due to local policy. (Note, that the text was already there, it just wasn't highlighted as an explicit requirement). o Removed the compact form for the header since unknown headers with multiple entries would not be recognized. o Added a summary of Application Considerations to address concerns about the optional usage of History-Info. There are 2 open issues identified in the draft: o Issue 1 is around the privacy issue that has been discussed recently on the list: http://www.ietf.org/mail-archive/working-groups/sip/current/msg09401.html http://www.ietf.org/mail-archive/working-groups/sip/current/msg09371.html It has been suggested that adding an additional field to the History-Info header (or extending the priv-values defined in RFC 3323) would facilitate the implementation of a local privacy policy associated with specific Request-URIs. o Issue 2 is around whether there needs to be some bounds on the size or number of History-Info entries. And if so, what's the mechanism for defining the bounds (e.g. limit the depth and breadth of the tree by putting upper limits on the Index? ) Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 ------_=_NextPart_001_01C3F3F1.5B962DA4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Updated History-Info draft submitted

I have submitted an updated version of the = History-Info draft.  Until it becomes available in the = respository, you can pick it up at:

http://home.comcast.net/~mary.barnes/IETF/draft-ietf-s= ip-history-info-02.txt

The primary changes are as follows:
o Merged the SIPPING WG requirements draft into this = document.
   Also, removed redirect server from = ISSUER-req since the
   solution identified this as not being = required (or desirable).
 
o Added an explicit privacy requirement (PRIV-req-3) = for the
  proxy's role in recognizing and maintaining = privacy associated
  with a Request-URI being captured in = History-Info due to local
  policy. (Note, that the text was already = there, it just wasn't
  highlighted as an explicit = requirement). 

o Removed the compact form for the header since = unknown headers
  with multiple entries would not be = recognized.

o Added a summary of Application Considerations to = address
  concerns about the optional usage of = History-Info.

There are 2 open issues identified in the = draft:
o Issue 1 is around the privacy issue that has been = discussed
  recently on the list:
http://www.ietf.org/mail-archive/working-groups/sip/cu= rrent/msg09401.html
http://www.ietf.org/mail-archive/working-groups/sip/cu= rrent/msg09371.html

  It has been suggested that adding an = additional field to the
  History-Info header (or extending the = priv-values defined in
  RFC 3323) would facilitate the implementation = of a local privacy
  policy associated with specific Request-URIs. =

o Issue 2 is around whether there needs to be some = bounds on the size
  or number of History-Info entries.  And = if so, what's the mechanism
  for defining the bounds (e.g. limit the depth = and breadth of the
  tree by putting upper limits on the Index? = ) 

Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com
972-684-5432


------_=_NextPart_001_01C3F3F1.5B962DA4-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 15:21:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23500 for ; Sun, 15 Feb 2004 15:21:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSlO-0005Ip-BG for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 15:21:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FKLEol020378 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 15:21:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSlD-0005FE-2Q; Sun, 15 Feb 2004 15:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSl1-0005CC-2f for sip@optimus.ietf.org; Sun, 15 Feb 2004 15:20:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23436 for ; Sun, 15 Feb 2004 15:20:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsSkz-0000Uw-00 for sip@ietf.org; Sun, 15 Feb 2004 15:20:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsSk6-0000RF-00 for sip@ietf.org; Sun, 15 Feb 2004 15:19:55 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AsSjj-0000MK-00 for sip@ietf.org; Sun, 15 Feb 2004 15:19:31 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FKISI19459; Sun, 15 Feb 2004 12:18:28 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV702H>; Sun, 15 Feb 2004 14:18:13 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF57900F@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Eric Burger'" , "SIP List (E-mail)" Subject: RE: [Sip] Comments on history-info Date: Sun, 15 Feb 2004 14:18:12 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Eric, Although Rohan responded to your "Big question:" part of this email: http://www1.ietf.org/mail-archive/working-groups/sip/current/msg08998.html it doesn't appear that I ever responded to the remaining points on the list. Thank you for reviewing the draft and providing detailed comments. In updating the draft, I considered your comments as indicated below [MB]. Regards, Mary. -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Thursday, November 06, 2003 3:44 AM To: SIP List (E-mail) Subject: [Sip] Comments on history-info Big question: Why don't we use multiple History-Info headers, instead of a (potentially VERY long) single header? I would argue for multiple headers on two grounds. First, the idea of a proxy modifying history information doesn't sound smart. If it screws up, it is hard to figure out who screwed up. Second, the index parameter frees us from worrying about header order, which is a VERY good thing. Overview: While the motivation for History-Info is for the initiator of a request to know what happened to a request, it is also of great use to the recipient (End of Section 2 overview paragraph). [MB]: I've clarified this. Section 1.2: How is History-Info any different than Via w.r.t. security? [MB]: It's quite similar actually, so I've added a statement to that effect in this section. I think the only difference being the dependency on the Index written by the previous hop to generate the index for the current hop. I do think the general M2M and M2E security solution would also be applicable to Via if TLS were not deemed to be sufficient (i.e if there were some reason why you would not want some intermediaries to be able to see the Via added by an "untrusted" intermediary). Nits: Section 2.5, first paragraph, last sentence: this would like be a local this would likely be a local ^^ [MB]: Fixed. Appendix B, message F8, extra space before last angle-bracket in the History-Info line. [MB]: Fixed. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 16:09:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24936 for ; Sun, 15 Feb 2004 16:09:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsTVo-0008Ff-8B for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 16:09:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FL9CRj031655 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 16:09:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsTVe-0008DR-CT; Sun, 15 Feb 2004 16:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsTVL-0008D3-5h for sip@optimus.ietf.org; Sun, 15 Feb 2004 16:08:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24929 for ; Sun, 15 Feb 2004 16:08:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsTVJ-0003ID-00 for sip@ietf.org; Sun, 15 Feb 2004 16:08:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsTUP-0003Fv-00 for sip@ietf.org; Sun, 15 Feb 2004 16:07:45 -0500 Received: from mail19b.dulles19-verio.com ([198.170.241.3]) by ietf-mx with smtp (Exim 4.12) id 1AsTTq-0003DN-00 for sip@ietf.org; Sun, 15 Feb 2004 16:07:10 -0500 Received: from www1913.dulles19-verio.com (161.58.134.174) by mail19b.dulles19-verio.com (RS ver 1.0.90vs) with SMTP id 0-0658889215; Sun, 15 Feb 2004 16:06:56 -0500 (EST) Date: Mon, 16 Feb 2004 05:06:50 +0800 From: neil quiogue To: Marc Petit-Huguenin cc: sip@ietf.org Subject: Re: [Sip] Binary Encoding for SIP Message-ID: <140639390.1076908010@[192.168.1.101]> In-Reply-To: <402FA64B.2060907@acm.org> References: <402FA64B.2060907@acm.org> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think what Cullen is proposing is to only send one type of MIME body part = encoding (i.e., binary) instead of having multiple possible MIME encoding=20 as specified on RFC3261/7.1.4. Regards, Neil --On dimanche 15 f=E9vrier 2004 09:03 -0800 Marc Petit-Huguenin=20 wrote: > I thought that binary body was already supported: RFC3261 section 7.4.1, > third paragraph. > > Cullen Jennings wrote: >> >> I submitted a draft on binary encoding for SIP. This improves >> interoperability, improves speed, decreases sizes of messages, and >> generally makes life better for SIP which will no doubt eventually help >> with World Hunger. I need feedback, please let me know: >> >> a) Yah, lets do it >> >> b) No this is a stupid ideas and here are the reasons why >> >> c) There has not been many list comments, this draft involves some very >> complex issues. I need a year or two to develop an opinion on the single >> sentence inside it. >> >> d) I agree with Cowboy Willis >> >> Until it arrives in the archives, you can find it at >> >> http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html >> >> or, if you prefer ASCII encodings of everything, >> >> www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt >> >> Thanks, Cullen >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 17:31:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27473 for ; Sun, 15 Feb 2004 17:31:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsUnB-0003Pr-Hn for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 17:31:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FMVD0h013128 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 17:31:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsUn1-0003O7-OE; Sun, 15 Feb 2004 17:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsUmA-0003Lw-P9 for sip@optimus.ietf.org; Sun, 15 Feb 2004 17:30:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27437 for ; Sun, 15 Feb 2004 17:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsUm8-0000R8-00 for sip@ietf.org; Sun, 15 Feb 2004 17:30:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsUlA-0000L1-00 for sip@ietf.org; Sun, 15 Feb 2004 17:29:09 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1AsUkV-0000DC-00 for sip@ietf.org; Sun, 15 Feb 2004 17:28:27 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i1FMRoLc001696 for ; Sun, 15 Feb 2004 16:27:50 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 15 Feb 2004 16:23:34 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <151R5AD9>; Sun, 15 Feb 2004 16:27:49 -0600 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9535@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'neil quiogue'" , Marc Petit-Huguenin Cc: sip@ietf.org Subject: RE: [Sip] Binary Encoding for SIP Date: Sun, 15 Feb 2004 16:26:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 15 Feb 2004 22:23:34.0546 (UTC) FILETIME=[598C4720:01C3F412] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Is SIGCOMP not good enough. Rgds/gf -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of neil quiogue Sent: Sunday, February 15, 2004 4:07 PM To: Marc Petit-Huguenin Cc: sip@ietf.org Subject: Re: [Sip] Binary Encoding for SIP I think what Cullen is proposing is to only send one type of MIME body pa= rt=20 encoding (i.e., binary) instead of having multiple possible MIME encoding= =20 as specified on RFC3261/7.1.4. Regards, Neil --On dimanche 15 f=E9vrier 2004 09:03 -0800 Marc Petit-Huguenin=20 wrote: > I thought that binary body was already supported: RFC3261 section 7.4.1= , > third paragraph. > > Cullen Jennings wrote: >> >> I submitted a draft on binary encoding for SIP. This improves >> interoperability, improves speed, decreases sizes of messages, and >> generally makes life better for SIP which will no doubt eventually hel= p >> with World Hunger. I need feedback, please let me know: >> >> a) Yah, lets do it >> >> b) No this is a stupid ideas and here are the reasons why >> >> c) There has not been many list comments, this draft involves some ver= y >> complex issues. I need a year or two to develop an opinion on the sing= le >> sentence inside it. >> >> d) I agree with Cowboy Willis >> >> Until it arrives in the archives, you can find it at >> >> http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html >> >> or, if you prefer ASCII encodings of everything, >> >> www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt >> >> Thanks, Cullen >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =20 This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 17:53:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28490 for ; Sun, 15 Feb 2004 17:53:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsV8N-0005Ui-Fl for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 17:53:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FMr75o021104 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 17:53:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsV8I-0005TD-7x; Sun, 15 Feb 2004 17:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsV8B-0005ST-76 for sip@optimus.ietf.org; Sun, 15 Feb 2004 17:52:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28466 for ; Sun, 15 Feb 2004 17:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsV88-0002LC-00 for sip@ietf.org; Sun, 15 Feb 2004 17:52:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsV7G-0002Gd-00 for sip@ietf.org; Sun, 15 Feb 2004 17:51:59 -0500 Received: from [202.12.233.17] (helo=mailao.ntcif.telstra.com.au) by ietf-mx with esmtp (Exim 4.12) id 1AsV6n-0002CW-00 for sip@ietf.org; Sun, 15 Feb 2004 17:51:29 -0500 Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailao.ntcif.telstra.com.au (Postfix) with ESMTP id D61F1143C7 for ; Mon, 16 Feb 2004 09:51:26 +1100 (EST) Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 536E112981 for ; Mon, 16 Feb 2004 09:51:26 +1100 (EST) Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA10016 for ; Mon, 16 Feb 2004 09:51:26 +1100 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F416.3B11DC70" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] Updated History-Info draft submitted Date: Mon, 16 Feb 2004 09:51:21 +1100 Message-ID: Thread-Topic: [Sip] Updated History-Info draft submitted Thread-Index: AcPz8feY7fdNamTVTYiuWDCdCsoBTwAI+C5w From: "Aders, David I" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F416.3B11DC70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Will interworking with and maintaining ISUP diversion information when = making a PSTN to SIP call be part of the scope of any future work for = the history-info draft? -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] Sent: Monday, 16 February 2004 5:27 AM To: 'sip@ietf.org' Subject: [Sip] Updated History-Info draft submitted I have submitted an updated version of the History-Info draft. Until it = becomes available in the respository, you can pick it up at: http://home.comcast.net/~mary.barnes/IETF/draft-ietf-sip-history-info-02.= txt=20 The primary changes are as follows:=20 o Merged the SIPPING WG requirements draft into this document.=20 Also, removed redirect server from ISSUER-req since the=20 solution identified this as not being required (or desirable).=20 =20 o Added an explicit privacy requirement (PRIV-req-3) for the=20 proxy's role in recognizing and maintaining privacy associated=20 with a Request-URI being captured in History-Info due to local=20 policy. (Note, that the text was already there, it just wasn't=20 highlighted as an explicit requirement). =20 o Removed the compact form for the header since unknown headers=20 with multiple entries would not be recognized.=20 o Added a summary of Application Considerations to address=20 concerns about the optional usage of History-Info.=20 There are 2 open issues identified in the draft:=20 o Issue 1 is around the privacy issue that has been discussed=20 recently on the list:=20 http://www.ietf.org/mail-archive/working-groups/sip/current/msg09401.html= =20 http://www.ietf.org/mail-archive/working-groups/sip/current/msg09371.html= =20 It has been suggested that adding an additional field to the=20 History-Info header (or extending the priv-values defined in=20 RFC 3323) would facilitate the implementation of a local privacy=20 policy associated with specific Request-URIs.=20 o Issue 2 is around whether there needs to be some bounds on the size=20 or number of History-Info entries. And if so, what's the mechanism=20 for defining the bounds (e.g. limit the depth and breadth of the=20 tree by putting upper limits on the Index? ) =20 Regards,=20 Mary H. Barnes=20 mary.barnes@nortelnetworks.com=20 972-684-5432=20 ------_=_NextPart_001_01C3F416.3B11DC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Updated History-Info draft submitted
Will interworking with and maintaining = ISUP=20 diversion information when making a PSTN to SIP call be part of the = scope=20 of any future work for the history-info draft?
-----Original Message-----
From: Mary Barnes=20 [mailto:mary.barnes@nortelnetworks.com]
Sent: Monday, 16 = February=20 2004 5:27 AM
To: 'sip@ietf.org'
Subject: [Sip] = Updated=20 History-Info draft submitted

I have submitted an updated version of the = History-Info=20 draft.  Until it becomes available in the respository, you can = pick it up=20 at:

http://home.comcast.net/~mary.barnes/IETF/draft-ietf-sip-= history-info-02.txt=20

The primary changes are as follows:
o=20 Merged the SIPPING WG requirements draft into this document. =
   Also, removed redirect server from ISSUER-req = since the=20
   solution identified this as not = being=20 required (or desirable).
  =
o Added an explicit privacy requirement (PRIV-req-3) for the=20
  proxy's role in recognizing and = maintaining=20 privacy associated
  with a Request-URI = being=20 captured in History-Info due to local
  = policy.=20 (Note, that the text was already there, it just wasn't =
  highlighted as an explicit requirement).  =

o Removed the compact form for the header since = unknown=20 headers
  with multiple entries would = not be=20 recognized.

o Added a summary of Application Considerations to = address=20
  concerns about the optional usage of=20 History-Info.

There are 2 open issues identified in the = draft:=20
o Issue 1 is around the privacy issue that has been = discussed=20
  recently on the list: =
http://www.ietf.org/mail-archive/working-groups/sip/curre= nt/msg09401.html=20
http://www.ietf.org/mail-archive/working-groups/sip/curre= nt/msg09371.html=20

  It has been suggested that adding an = additional field=20 to the
  History-Info header (or = extending the=20 priv-values defined in
  RFC 3323) = would=20 facilitate the implementation of a local privacy
  policy associated with specific Request-URIs. =

o Issue 2 is around whether there needs to be some = bounds on=20 the size
  or number of History-Info=20 entries.  And if so, what's the mechanism
 =20 for defining the bounds (e.g. limit the depth and breadth of the=20
  tree by putting upper limits on the = Index?=20 ) 

Regards,
Mary H. = Barnes=20
mary.barnes@nortelnetworks.com
972-684-5432


------_=_NextPart_001_01C3F416.3B11DC70-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 17:57:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29016 for ; Sun, 15 Feb 2004 17:57:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVCI-00063X-As for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 17:57:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FMvArS023240 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 17:57:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVCF-000607-H6; Sun, 15 Feb 2004 17:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVBm-0005tk-89 for sip@optimus.ietf.org; Sun, 15 Feb 2004 17:56:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28847 for ; Sun, 15 Feb 2004 17:56:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsVBj-0002z8-00 for sip@ietf.org; Sun, 15 Feb 2004 17:56:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsVA6-0002hz-00 for sip@ietf.org; Sun, 15 Feb 2004 17:54:55 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AsV8a-0002R3-00 for sip@ietf.org; Sun, 15 Feb 2004 17:53:20 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1FMrKR4023317 for ; Sun, 15 Feb 2004 17:53:20 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1FMrKH07939 for ; Sun, 15 Feb 2004 17:53:20 -0500 Message-ID: <402FF85F.4020202@cs.columbia.edu> Date: Sun, 15 Feb 2004 17:53:19 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-resource-priority-02 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I will shortly (finally...) be submitting draft-ietf-sip-resource-priority-02 http://www.cs.columbia.edu/sip/draft/resource-priority/draft-ietf-sip-resource-priority-02.html Changes are noted below, based on my reading of the January 2004 mailing list discussions and the reviews by Paul Kyvizat and Ben Campbell last fall. (1) Corrected BNF. [Paul, Rohan] (2) Added namespace registration template and converted initial registrations to that template. [multiple] (3) Now there is a single IANA section with subsections. [Rohan] (4) Current behavior for DSN, Q.735 specified as non-preemptive. DRSN left as implementation-defined. Not sure what other behavior one can specify for priorities. [Rohan] (5) Resource priority for SUBSCRIBE could make sense if a UA has a finite capacity for subscriptions and notifications (memory or bandwidth). Since NOTIFY establishes no state, only the generic request-queueing behavior applies. Text added. [Rohan] (6) Addressed wording comments (Section 3); was no longer in the draft anyway. [Rohan] (7) Complete request method list. [Rohan] Rather than speculating where this might be used, marked as 'o'. [Paul] (8) Changed 'support' to 'implement' and added some explanatory wording. [Rohan] (9) resource-priority option tag defined in Section 3. [Rohan] (10) RFC XXXX note added, but not really necessary since the new XML version contains &rfc.number; [Rohan] (11) Removed Appendix A ('Addressing the Requirements') [Ken Karlberg] (12) Typo and wording corrections [Paul, Ben] (13) Added distinction to Priority header, but left old text intact. [Paul] (14) For simplicity, restricted Accept-R-P to UAS; multiple R-P values have always been possible. [Paul] (15) Accept-R-P 420 marked as 'o', with explanation [Paul]. (I'm dubious on the reasoning since this means that 'm' cannot appear in any extension, thus diminishing the value of the table.) (16) Multiple namespaces handling made more concrete. [Paul] (17) Added caveat to OPTIONS handling under overload. [Paul] (18) OPTIONS handling made MUST. [Ben] (19) Added discussion on what happens if you modify an R-P value in transit. [Ben, others] Changes discussed, but not made: - Continues to allow one priority value since the presence of any value indicates special treatment, regardless of whether there is another value. (In other words, default behavior is a request with no Resource-Priority header.) This may be partially due to confusion in versioning; since the last IETF, there were no more 'default' values. (Indeed, the word does not appear in the document.) [Mike Pierce] - 417 generalization to any unknown parameter (since this would not allow the user to determine why the request failed) [Alex Audu] - No mechanism to name all elements in namespace, for simplicity and to avoid arguments over which list is referred to by all when a namespace gets additional values. [Paul] Given the stretch of the discussion, it is possible I missed a comment or discussion thread. If you respond to this message, please keep each item in a separate message as it is very difficult to deal with monster messages covering 20 different points. 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 exim@www1.ietf.org Sun Feb 15 18:02:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29555 for ; Sun, 15 Feb 2004 18:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVH2-0007i7-Hq for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 18:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FN24bn029620 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 18:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVGy-0007do-Fn; Sun, 15 Feb 2004 18:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVGn-0007VF-0o for sip@optimus.ietf.org; Sun, 15 Feb 2004 18:01:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29543 for ; Sun, 15 Feb 2004 18:01:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsVGj-0003mG-00 for sip@ietf.org; Sun, 15 Feb 2004 18:01:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsVFr-0003jx-00 for sip@ietf.org; Sun, 15 Feb 2004 18:00:52 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AsVFV-0003dw-00 for sip@ietf.org; Sun, 15 Feb 2004 18:00:29 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30105; Sun, 15 Feb 2004 18:00:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on history-info Date: Sun, 15 Feb 2004 17:59:59 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A191@zoe.office.snowshore.com> Thread-Topic: [Sip] Comments on history-info Thread-Index: AcP0APEouqnUCB5tQTSCZ63TeEfehAABicmQ From: "Eric Burger" To: "Mary Barnes" , "SIP List (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Excellent. Thinking about it a bit more, is there any reason to ALLOW stuffing = multiple history info info's on a single line? The idea going back to = SMTP was that you are only allowed to add history, not change it. = Putting multiple history info's in a single history-info header, by = definition, changes history. > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] > Sent: Sunday, February 15, 2004 3:18 PM > To: Eric Burger; SIP List (E-mail) > Subject: RE: [Sip] Comments on history-info >=20 >=20 > Eric, >=20 > Although Rohan responded to your "Big question:" part of this email: > http://www1.ietf.org/mail-archive/working-groups/sip/current/m > sg08998.html > it doesn't appear that I ever responded to the remaining=20 > points on the list. > Thank you for reviewing the draft and providing detailed=20 > comments. In > updating the draft, I considered your comments as indicated=20 > below [MB]. >=20 > Regards, > Mary.=20 >=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Thursday, November 06, 2003 3:44 AM > To: SIP List (E-mail) > Subject: [Sip] Comments on history-info >=20 >=20 > Big question: > Why don't we use multiple History-Info headers, instead of a=20 > (potentially > VERY long) single header? >=20 > I would argue for multiple headers on two grounds. >=20 > First, the idea of a proxy modifying history information doesn't sound > smart. If it screws up, it is hard to figure out who screwed up. >=20 > Second, the index parameter frees us from worrying about=20 > header order, which > is a VERY good thing. >=20 >=20 >=20 > Overview: > While the motivation for History-Info is for the initiator of=20 > a request to > know what happened to a request, it is also of great use to=20 > the recipient > (End of Section 2 overview paragraph). >=20 > [MB]: I've clarified this.=20 >=20 > Section 1.2: > How is History-Info any different than Via w.r.t. security? >=20 > [MB]: It's quite similar actually, so I've added a statement=20 > to that effect > in this section. I think the only difference being the=20 > dependency on the > Index written by the previous hop to generate the index for=20 > the current hop. > I do think the general M2M and M2E security solution would also be > applicable to Via if TLS were not deemed to be sufficient=20 > (i.e if there were > some reason why you would not want some intermediaries to be=20 > able to see the > Via added by an "untrusted" intermediary). =20 >=20 > Nits: > Section 2.5, first paragraph, last sentence: > this would like be a local > this would likely be a local > ^^ > [MB]: Fixed.=20 >=20 > Appendix B, message F8, extra space before last angle-bracket in the > History-Info line. >=20 > [MB]: Fixed. >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 20:44:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07471 for ; Sun, 15 Feb 2004 20:44:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXo1-0006Rd-4Q for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 20:44:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G1iHH0024711 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 20:44:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXnm-0006MC-IE; Sun, 15 Feb 2004 20:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXne-0006L6-GZ for sip@optimus.ietf.org; Sun, 15 Feb 2004 20:43:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07465 for ; Sun, 15 Feb 2004 20:43:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXnc-00000W-00 for sip@ietf.org; Sun, 15 Feb 2004 20:43:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXmn-0007lr-00 for sip@ietf.org; Sun, 15 Feb 2004 20:43:02 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsXmZ-0007if-00 for sip@ietf.org; Sun, 15 Feb 2004 20:42:47 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1G1gONr004824 for ; Sun, 15 Feb 2004 20:42:25 -0500 (EST) Message-ID: <40301FF8.40201@dynamicsoft.com> Date: Sun, 15 Feb 2004 20:42:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Updated gruu I-D Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to the GRUU specification. Until it appears in the archives, you can find it at: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-01.txt The differences are: * removed requirement that the gruu be constructed in such a way that the contact and/or AOR can be determined from it * indicate that a gruu can be obtained by the register mechanisms in the specification, but that other mechanisms are also possible * The gruu is now associated with the instance ID of the UA. The instance ID is defined as a callee capability parameter. The specification now includes a UML diagram showing the relationships between GRUU, AOR, Contact URI and instance ID. * Added registration of the sip.instance media feature tag The biggest change is the third. Indeed, it seems like we have three drafts this round that discuss instance identifiers in SIP: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-01.txt http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt all three are similar. Mine uses a contact header field parameter, and uses the callee capabilities framework to enable caller preferences routing based on instance iDs. Cullen also uses a contact parameter, but not within the callee caps framework. Brian defines a header field. I'll post a separate not starting a thread on the pros and cons of the various approaches. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 15 20:50:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07668 for ; Sun, 15 Feb 2004 20:50:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXts-0006y9-88 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 20:50:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G1oKTt026727 for sip-archive@odin.ietf.org; Sun, 15 Feb 2004 20:50:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXtb-0006oI-K7; Sun, 15 Feb 2004 20:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXtU-0006nM-As for sip@optimus.ietf.org; Sun, 15 Feb 2004 20:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07645 for ; Sun, 15 Feb 2004 20:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXtR-0000Yx-00 for sip@ietf.org; Sun, 15 Feb 2004 20:49:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXsg-0000VP-00 for sip@ietf.org; Sun, 15 Feb 2004 20:49:07 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsXrt-0000Jl-00 for sip@ietf.org; Sun, 15 Feb 2004 20:48:17 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1G1ltNr004827 for ; Sun, 15 Feb 2004 20:47:55 -0500 (EST) Message-ID: <40302143.9080000@dynamicsoft.com> Date: Sun, 15 Feb 2004 20:47:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP instance identifiers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, We have three drafts this round that all propose a way to define an instance identifier for a UA: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-01.txt http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt all three are similar. Mine uses a contact header field parameter, and uses the callee capabilities framework to enable caller preferences routing based on instance iDs. Cullen also uses a contact parameter, but not within the callee caps framework. Brian defines a header field. I think we generally understand the requirement here, though it would probably be good to obtain use cases to be sure. The design choice is where to include this parameter, and this represents the difference between the three approaches. I tend to prefer a Contact URI parameter over a header. My main reason for that is REGISTER requests. If a register request has multiple contacts, which contact does the instance identifier apply to? As a header field, it would be hard to know. If you make it a contact header field parameter, its no problem. Those header field parameters could also then be used in the Contact in INVITE/200 SUB/NOT, etc. Then, the question is whether to use a regular Contact header field parameter as Cullen has done, or a callee cap parameter as I have done? The callee cap approach allows for caller preferences to be applied to routing to a specific instance. Now, a good question is whether such a thing is needed or even a good idea, if we have GRUU as the ideal way to route to a UA instance. I can go either way, but welcome thoughts on the topic. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 04:10:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07144 for ; Mon, 16 Feb 2004 04:10:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aseln-0006e9-N8 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 04:10:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G9ARl7025486 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 04:10:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AselO-0006bA-Rk; Mon, 16 Feb 2004 04:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsekU-0006Wd-NN for sip@optimus.ietf.org; Mon, 16 Feb 2004 04:09:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07030 for ; Mon, 16 Feb 2004 04:09:04 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsekR-0004H8-00 for sip@ietf.org; Mon, 16 Feb 2004 04:09:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aseja-0004EM-00 for sip@ietf.org; Mon, 16 Feb 2004 04:08:10 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aseif-0004BO-00 for sip@ietf.org; Mon, 16 Feb 2004 04:07:14 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1G97E306664 for ; Mon, 16 Feb 2004 11:07:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Feb 2004 11:07:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 11:07:13 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-khartabil-sip-policy-uri-call-info-purpose-00 Date: Mon, 16 Feb 2004 11:07:13 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797753@esebe019.ntc.nokia.com> Thread-Topic: [Sip] draft-khartabil-sip-policy-uri-call-info-purpose-00 Thread-Index: AcPzH3fIPDfDOvw4T9KyTkpXL5ZUOQBTKJRw To: , X-OriginalArrivalTime: 16 Feb 2004 09:07:13.0591 (UTC) FILETIME=[444AE470:01C3F46C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks. Do you think that it will only be limited to conferences? /Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Cullen Jennings > Sent: 13.February.2004 18:49 > To: sip@ietf.org > Subject: [Sip] draft-khartabil-sip-policy-uri-call-info-purpose-00 >=20 >=20 > =20 > I like this draft, just one little NIT, I think it would be=20 > better to call > the tag conf-policy-info instead of just policy-info >=20 > Cullen >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 09:34:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20155 for ; Mon, 16 Feb 2004 09:34:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asjp6-0002IQ-73 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 09:34:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GEYCqf008764 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 09:34:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asjow-0002GD-FO; Mon, 16 Feb 2004 09:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsjoH-0002Ew-9y for sip@optimus.ietf.org; Mon, 16 Feb 2004 09:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20146 for ; Mon, 16 Feb 2004 09:33:18 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsjoF-000028-00 for sip@ietf.org; Mon, 16 Feb 2004 09:33:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsjnM-0007nd-00 for sip@ietf.org; Mon, 16 Feb 2004 09:32:25 -0500 Received: from imo-r07.mx.aol.com ([152.163.225.103]) by ietf-mx with esmtp (Exim 4.12) id 1Asjmz-0007kE-00 for sip@ietf.org; Mon, 16 Feb 2004 09:32:01 -0500 Received: from Mpierce1@aol.com by imo-r07.mx.aol.com (mail_out_v36_r4.14.) id 7.75.227a69ea (4552); Mon, 16 Feb 2004 09:31:23 -0500 (EST) Message-ID: <75.227a69ea.2d622e3b@aol.com> Date: Mon, 16 Feb 2004 09:31:23 EST Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 To: hgs@cs.columbia.edu, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_75.227a69ea.2d622e3b_boundary" X-Mailer: 6.0 for Windows XP sub 51 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_75.227a69ea.2d622e3b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/15/2004 5:57:50 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > This may be partially due to confusion in versioning; since the last > IETF, there were no more 'default' values. (Indeed, the word does not > appear in the document.) [Mike Pierce] > I don't know what the confusion is. Looking at the -01 version contained on the IETF-58 CD I just received, there is the following statement in Section 12: "The registration MUST indicate the default level to be assumed in the absence of the priority value ..." Was there another unumbered update that I missed? Mike --part1_75.227a69ea.2d622e3b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/15/2004 5:57:50 PM Eastern Standard Time, hgs@cs.columbia.edu writes= :


This may be partially due t= o confusion in versioning; since the last=20
IETF, there were no more 'default' values. (Indeed, the word does not=20
appear in the document.) [Mike Pierce]


I don't know what the confusion is. Looking at the -01 version contained= on the IETF-58 CD I just received, there is the following statement in Sect= ion 12:

"The registration MUST indicate the default level to be assumed in the a= bsence of the priority value ..."

Was there another unumbered update that I missed?

Mike

--part1_75.227a69ea.2d622e3b_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 exim@www1.ietf.org Mon Feb 16 09:44:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20455 for ; Mon, 16 Feb 2004 09:44:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asjyg-00037U-97 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 09:44:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GEi6uo011956 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 09:44:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asjyc-00035d-9P; Mon, 16 Feb 2004 09:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asjxs-00034c-GY for sip@optimus.ietf.org; Mon, 16 Feb 2004 09:43:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20394 for ; Mon, 16 Feb 2004 09:43:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asjxq-0000aD-00 for sip@ietf.org; Mon, 16 Feb 2004 09:43:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asjwu-0000XN-00 for sip@ietf.org; Mon, 16 Feb 2004 09:42:16 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Asjw2-0000VP-00 for sip@ietf.org; Mon, 16 Feb 2004 09:41:22 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1GEfLR4013628; Mon, 16 Feb 2004 09:41:21 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1GEfLH15620; Mon, 16 Feb 2004 09:41:21 -0500 Message-ID: <4030D690.1040707@cs.columbia.edu> Date: Mon, 16 Feb 2004 09:41:20 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 References: <75.227a69ea.2d622e3b@aol.com> In-Reply-To: <75.227a69ea.2d622e3b@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I don't know what the confusion is. Looking at the -01 version contained > on the IETF-58 CD I just received, there is the following statement in > Section 12: > > "The registration MUST indicate the default level to be assumed in the > absence of the priority value ..." > > Was there another unumbered update that I missed? > There was an early -02 that I only announced to the mailing list, but never got around to submitting. In any event, the notion of defaults is gone since it makes no sense in the current setup. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 09:56:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20893 for ; Mon, 16 Feb 2004 09:56:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskAL-00040g-T1 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 09:56:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GEu9x0015351 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 09:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskAE-0003yP-P7; Mon, 16 Feb 2004 09:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ask9V-0003wE-Lm for sip@optimus.ietf.org; Mon, 16 Feb 2004 09:55:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20842 for ; Mon, 16 Feb 2004 09:55:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ask9T-0001Go-00 for sip@ietf.org; Mon, 16 Feb 2004 09:55:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ask8U-0001BA-00 for sip@ietf.org; Mon, 16 Feb 2004 09:54:15 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1Ask7W-00015y-00 for sip@ietf.org; Mon, 16 Feb 2004 09:53:14 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1GEqF812383; Mon, 16 Feb 2004 08:52:15 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV8CSX>; Mon, 16 Feb 2004 08:52:01 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF579011@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Aders, David I'" , sip@ietf.org Cc: "'john.elwell@siemens.com'" Subject: RE: [Sip] Updated History-Info draft submitted Date: Mon, 16 Feb 2004 08:51:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F49C.6A29ACDC" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F49C.6A29ACDC Content-Type: text/plain; charset="iso-8859-1" No, this draft will not address ISUP interworking. The draft provides some example applications in order to highlight how the History-Info header could be used, but there's nothing normative about any of those examples. John Elwell had put out a draft on how to do diversion for QSIG interworking, which does make use of History-Info that you might find useful (note the draft itself has expired and I'll let John address how or whether he plans to progress that; my understanding is that this work is being done in ECMA). So, I would think the functionality you're describing might be something the ITU or another SDO would want to define. Regards, Mary. -----Original Message----- From: Aders, David I [mailto:David.I.Aders@team.telstra.com] Sent: Sunday, February 15, 2004 4:51 PM To: sip@ietf.org Subject: RE: [Sip] Updated History-Info draft submitted Will interworking with and maintaining ISUP diversion information when making a PSTN to SIP call be part of the scope of any future work for the history-info draft? -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] Sent: Monday, 16 February 2004 5:27 AM To: 'sip@ietf.org' Subject: [Sip] Updated History-Info draft submitted I have submitted an updated version of the History-Info draft. Until it becomes available in the respository, you can pick it up at: http://home.comcast.net/~mary.barnes/IETF/draft-ietf-sip-history-info-02.txt The primary changes are as follows: o Merged the SIPPING WG requirements draft into this document. Also, removed redirect server from ISSUER-req since the solution identified this as not being required (or desirable). o Added an explicit privacy requirement (PRIV-req-3) for the proxy's role in recognizing and maintaining privacy associated with a Request-URI being captured in History-Info due to local policy. (Note, that the text was already there, it just wasn't highlighted as an explicit requirement). o Removed the compact form for the header since unknown headers with multiple entries would not be recognized. o Added a summary of Application Considerations to address concerns about the optional usage of History-Info. There are 2 open issues identified in the draft: o Issue 1 is around the privacy issue that has been discussed recently on the list: http://www.ietf.org/mail-archive/working-groups/sip/current/msg09401.html http://www.ietf.org/mail-archive/working-groups/sip/current/msg09371.html It has been suggested that adding an additional field to the History-Info header (or extending the priv-values defined in RFC 3323) would facilitate the implementation of a local privacy policy associated with specific Request-URIs. o Issue 2 is around whether there needs to be some bounds on the size or number of History-Info entries. And if so, what's the mechanism for defining the bounds (e.g. limit the depth and breadth of the tree by putting upper limits on the Index? ) Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 ------_=_NextPart_001_01C3F49C.6A29ACDC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Updated History-Info draft submitted

No, this draft will not address ISUP = interworking.  The draft provides some example applications in = order to highlight how the History-Info header could be used, but = there's nothing normative about any of those examples.   John = Elwell had put out a draft on how to do diversion for QSIG = interworking, which does make use of History-Info that you might find = useful (note the draft itself has expired and I'll let John address how = or whether he plans to progress that; my understanding is that this = work is being done in ECMA).  So, I would think the functionality = you're describing might be something the ITU or another SDO would want = to define. 

Regards,
Mary.

-----Original Message-----
From: Aders, David I [mailto:David.I.Aders@team= .telstra.com]
Sent: Sunday, February 15, 2004 4:51 PM
To: sip@ietf.org
Subject: RE: [Sip] Updated History-Info draft = submitted


Will interworking with and maintaining ISUP diversion = information when making a PSTN to SIP call be part of the scope of any = future work for the history-info draft?

-----Original Message-----
From: Mary Barnes [mailto:mary.barnes@nortel= networks.com]
Sent: Monday, 16 February 2004 5:27 AM
To: 'sip@ietf.org'
Subject: [Sip] Updated History-Info draft = submitted


I have submitted an updated version of the = History-Info draft.  Until it becomes available in the = respository, you can pick it up at:

http://home.comcast.net/~mary.barnes/IETF/draft-ietf-s= ip-history-info-02.txt
The primary changes are as follows:
o Merged the SIPPING WG requirements draft into this = document.
   Also, removed redirect server from = ISSUER-req since the
   solution identified this as not being = required (or desirable).
 
o Added an explicit privacy requirement (PRIV-req-3) = for the
  proxy's role in recognizing and maintaining = privacy associated
  with a Request-URI being captured in = History-Info due to local
  policy. (Note, that the text was already = there, it just wasn't
  highlighted as an explicit = requirement). 
o Removed the compact form for the header since = unknown headers
  with multiple entries would not be = recognized.
o Added a summary of Application Considerations to = address
  concerns about the optional usage of = History-Info.
There are 2 open issues identified in the draft: =
o Issue 1 is around the privacy issue that has been = discussed
  recently on the list:
http://www.ietf.org/mail-archive/working-groups/sip/cu= rrent/msg09401.html
http://www.ietf.org/mail-archive/working-groups/sip/cu= rrent/msg09371.html
  It has been suggested that adding an = additional field to the
  History-Info header (or extending the = priv-values defined in
  RFC 3323) would facilitate the implementation = of a local privacy
  policy associated with specific Request-URIs. =
o Issue 2 is around whether there needs to be some = bounds on the size
  or number of History-Info entries.  And = if so, what's the mechanism
  for defining the bounds (e.g. limit the depth = and breadth of the
  tree by putting upper limits on the Index? = ) 
Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com
972-684-5432

------_=_NextPart_001_01C3F49C.6A29ACDC-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 10:01:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21406 for ; Mon, 16 Feb 2004 10:01:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskFU-0005HG-QO for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 10:01:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GF1SxH020214 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 10:01:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskF5-0004sQ-Hy; Mon, 16 Feb 2004 10:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskEV-0004a2-Ur for sip@optimus.ietf.org; Mon, 16 Feb 2004 10:00:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21294 for ; Mon, 16 Feb 2004 10:00:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AskET-0001pX-00 for sip@ietf.org; Mon, 16 Feb 2004 10:00:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskDq-0001mA-00 for sip@ietf.org; Mon, 16 Feb 2004 09:59:47 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1AskDJ-0001dV-00 for sip@ietf.org; Mon, 16 Feb 2004 09:59:13 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1GEwF812743; Mon, 16 Feb 2004 08:58:15 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV8CX9>; Mon, 16 Feb 2004 08:58:01 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF579012@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Eric Burger'" , "SIP List (E-mail)" Subject: RE: [Sip] Comments on history-info Date: Mon, 16 Feb 2004 08:57:50 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Eric, History-Info is a bit different than the SMTP (at least as best as I understand SMTP not being an expert in that area), since the retargeting in SIP is more complicated that SMTP due to forking, etc. In order to be able to accurately reflecting the forking, we've added the index. The index is used to generate subsequent History-Info entries. In addition, there's the Reason that gets added to the targeted-to URIs to reflect the reason for the retargeting. So, yes History-Info does change History in the sense that we embellish the Request-URIs that are "visited" with additional information that seems to be useful to a variety of end applications. So, I think what you're proposing would only provide a subset of the functionality that we're after. Mary. -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Sunday, February 15, 2004 5:00 PM To: Barnes, Mary [NGC:B622:EXCH]; SIP List (E-mail) Subject: RE: [Sip] Comments on history-info Excellent. Thinking about it a bit more, is there any reason to ALLOW stuffing multiple history info info's on a single line? The idea going back to SMTP was that you are only allowed to add history, not change it. Putting multiple history info's in a single history-info header, by definition, changes history. > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] > Sent: Sunday, February 15, 2004 3:18 PM > To: Eric Burger; SIP List (E-mail) > Subject: RE: [Sip] Comments on history-info > > > Eric, > > Although Rohan responded to your "Big question:" part of this email: > http://www1.ietf.org/mail-archive/working-groups/sip/current/m > sg08998.html > it doesn't appear that I ever responded to the remaining > points on the list. > Thank you for reviewing the draft and providing detailed > comments. In > updating the draft, I considered your comments as indicated > below [MB]. > > Regards, > Mary. > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Thursday, November 06, 2003 3:44 AM > To: SIP List (E-mail) > Subject: [Sip] Comments on history-info > > > Big question: > Why don't we use multiple History-Info headers, instead of a > (potentially > VERY long) single header? > > I would argue for multiple headers on two grounds. > > First, the idea of a proxy modifying history information doesn't sound > smart. If it screws up, it is hard to figure out who screwed up. > > Second, the index parameter frees us from worrying about > header order, which > is a VERY good thing. > > > > Overview: > While the motivation for History-Info is for the initiator of > a request to > know what happened to a request, it is also of great use to > the recipient > (End of Section 2 overview paragraph). > > [MB]: I've clarified this. > > Section 1.2: > How is History-Info any different than Via w.r.t. security? > > [MB]: It's quite similar actually, so I've added a statement > to that effect > in this section. I think the only difference being the > dependency on the > Index written by the previous hop to generate the index for > the current hop. > I do think the general M2M and M2E security solution would also be > applicable to Via if TLS were not deemed to be sufficient > (i.e if there were > some reason why you would not want some intermediaries to be > able to see the > Via added by an "untrusted" intermediary). > > Nits: > Section 2.5, first paragraph, last sentence: > this would like be a local > this would likely be a local > ^^ > [MB]: Fixed. > > Appendix B, message F8, extra space before last angle-bracket in the > History-Info line. > > [MB]: Fixed. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 10:35:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25557 for ; Mon, 16 Feb 2004 10:35:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askld-0005Of-Na for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 10:34:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GFYfkp020683 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 10:34:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askl1-00051y-21; Mon, 16 Feb 2004 10:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskkL-0004ij-3c for sip@optimus.ietf.org; Mon, 16 Feb 2004 10:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25205 for ; Mon, 16 Feb 2004 10:33:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AskkI-0004Xs-00 for sip@ietf.org; Mon, 16 Feb 2004 10:33:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskjI-0004T7-00 for sip@ietf.org; Mon, 16 Feb 2004 10:32:16 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AskiJ-0004N4-00; Mon, 16 Feb 2004 10:31:15 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1GFUqR4025212; Mon, 16 Feb 2004 10:30:52 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1GFUqH20137; Mon, 16 Feb 2004 10:30:52 -0500 Message-ID: <4030E22B.60804@cs.columbia.edu> Date: Mon, 16 Feb 2004 10:30:51 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: schatterjee@hss.hns.com CC: sipping@ietf.org, sip@ietf.org, jmpolk@cisco.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Question regarding resource-priority header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Last night, I announced http://www.cs.columbia.edu/sip/draft/resource-priority/draft-ietf-sip-resource-priority-02.html Please address your comments to that draft, to avoid confusion and fixing old bugs. schatterjee@hss.hns.com wrote: > > Hi, > > In draft-ietf-sip-resource-priority-01.txt, it looks like there is a > printing mistake in the grammar defined for Resource-Priority header . > Its given as > Resource-Priority = "Resource-Priority" HCOLON > (*COMMA Resource-value) > > But I guess, no header can start with a COMMA . It should actually be > Resource-Priority = "Resource-Priority" HCOLON > Resource-value(*COMMA Resource-value) > > This is the way the grammar is given for Accept-Resource-Priority. > Can anyone confirm on this pls? > > thanks in advance... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 11:04:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28153 for ; Mon, 16 Feb 2004 11:04:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslEE-0000Yf-6V for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 11:04:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GG4E7K002145 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 11:04:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslE2-0000XD-1B; Mon, 16 Feb 2004 11:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslDS-0000Ux-CR for sip@optimus.ietf.org; Mon, 16 Feb 2004 11:03:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27982 for ; Mon, 16 Feb 2004 11:03:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslDP-00006I-00 for sip@ietf.org; Mon, 16 Feb 2004 11:03:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslBD-0007QC-00 for sip@ietf.org; Mon, 16 Feb 2004 11:01:11 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1Asl8t-0006st-00 for sip@ietf.org; Mon, 16 Feb 2004 10:58:44 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1GFvhg10327; Mon, 16 Feb 2004 07:57:43 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV81S6>; Mon, 16 Feb 2004 09:57:28 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304AB8D9D@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] SIP instance identifiers Date: Mon, 16 Feb 2004 09:57:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F4A5.8EEE731E" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F4A5.8EEE731E Content-Type: text/plain; charset="iso-8859-1" Johnathan, I'm not opposed to the client ID being transported in the registration contact, but seeing as there were two drafts that already discuss that, I didn't see much point in rehashing it again in my draft. =) I believe there are some important points that you're leaving out. Besides being client generated (which reduces the requirements for generating the ID) there are advantages to NOT mandating that the ID be expressed only as a parameter in the contact of a registration. The idea behind the GUID (and hence the lack of a specific usecase in the -00 version of the document) is that it can be used for other activities. I'm not opposed to communicating the ID in a contact parameter as well as a regular header, I just don't view transporting it in a contact header as being always necessary or desirable depending on what you want to do with it. Sending it as a header allows for some interesting behavior to occur on non-registration requests: - Can be used to eliminate duplicate subscriptions due to client's state being wiped out (ie. ignore the callid/tags of an existing subscription if the client ID matches the client ID of that subscription [and the other information about the subscription is the same]). - Can be used to identify the client sending a request across networks where no other identifier is easily obtainable (NATs and the such), or BBUAs are present in the network. - Can be used to identify the source of state information being pushed into the network (presence update, etc). This is one area where conveying the information in a contact seems a little cumbersome. The request may not be sent to the registrar, and a contact may otherwise be completely unnecessary. In the cases where registration behavior is controlled, it requires a change to the registrar in order to capture the appropriate behavior that should be taken wrt a client ID. Therefore, including the information as a header or in the contact seems moot to me as either mechanism can easily be made to work. Perhaps there's a usecase I'm not considering? Additionally, I believe that there needs to be some convergence on the approach taken by generating the identifier itself. The mechanism that is suggested in your draft seems to rely upon a server to generate the unique identifier, whereas in the other two drafts, it is the client that generates the unique identifier. I believe there are advantages to each. Regards, Brian -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Sunday, February 15, 2004 7:48 PM To: sip@ietf.org Subject: [Sip] SIP instance identifiers Folks, We have three drafts this round that all propose a way to define an instance identifier for a UA: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-01.txt http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.tx t http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt all three are similar. Mine uses a contact header field parameter, and uses the callee capabilities framework to enable caller preferences routing based on instance iDs. Cullen also uses a contact parameter, but not within the callee caps framework. Brian defines a header field. I think we generally understand the requirement here, though it would probably be good to obtain use cases to be sure. The design choice is where to include this parameter, and this represents the difference between the three approaches. I tend to prefer a Contact URI parameter over a header. My main reason for that is REGISTER requests. If a register request has multiple contacts, which contact does the instance identifier apply to? As a header field, it would be hard to know. If you make it a contact header field parameter, its no problem. Those header field parameters could also then be used in the Contact in INVITE/200 SUB/NOT, etc. Then, the question is whether to use a regular Contact header field parameter as Cullen has done, or a callee cap parameter as I have done? The callee cap approach allows for caller preferences to be applied to routing to a specific instance. Now, a good question is whether such a thing is needed or even a good idea, if we have GRUU as the ideal way to route to a UA instance. I can go either way, but welcome thoughts on the topic. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C3F4A5.8EEE731E Content-Type: text/html; charset="iso-8859-1" RE: [Sip] SIP instance identifiers

Johnathan,

I'm not opposed to the client ID being transported in the registration contact,
but seeing as there were two drafts that already discuss that, I didn't see
much point in rehashing it again in my draft. =)

I believe there are some important points that you're leaving out.

Besides being client generated (which reduces the requirements for generating
the ID) there are advantages to NOT mandating that the ID be expressed only
as a parameter in the contact of a registration.

The idea behind the GUID (and hence the lack of a specific usecase in the
-00 version of the document) is that it can be used for other activities.
I'm not opposed to communicating the ID in a contact parameter as well as
a regular header, I just don't view transporting it in a contact header
as being always necessary or desirable depending on what you want to do
with it.

Sending it as a header allows for some interesting behavior to occur on
non-registration requests:

- Can be used to eliminate duplicate subscriptions due to client's state
being wiped out (ie. ignore the callid/tags of an existing subscription
if the client ID matches the client ID of that subscription [and the other
information about the subscription is the same]).
- Can be used to identify the client sending a request across networks
where no other identifier is easily obtainable (NATs and the such), or
BBUAs are present in the network.
- Can be used to identify the source of state information being pushed
into the network (presence update, etc). This is one area where conveying
the information in a contact seems a little cumbersome. The request may
not be sent to the registrar, and a contact may otherwise be completely
unnecessary.

In the cases where registration behavior is controlled, it requires a change
to the registrar in order to capture the appropriate behavior that should be
taken wrt a client ID. Therefore, including the information as a header or
in the contact seems moot to me as either mechanism can easily be made to
work. Perhaps there's a usecase I'm not considering?

Additionally, I believe that there needs to be some convergence on the approach
taken by generating the identifier itself. The mechanism that is suggested
in your draft seems to rely upon a server to generate the unique identifier,
whereas in the other two drafts, it is the client that generates the
unique identifier. I believe there are advantages to each.

Regards,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Sunday, February 15, 2004 7:48 PM
To: sip@ietf.org
Subject: [Sip] SIP instance identifiers


Folks,

We have three drafts this round that all propose a way to define an
instance identifier for a UA:


http://www.jdrosen.net/papers/draft-ietf-sip-gruu-01.txt
http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt
http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt

all three are similar. Mine uses a contact header field parameter, and
uses the callee capabilities framework to enable caller preferences
routing based on instance iDs. Cullen also uses a contact parameter, but
not within the callee caps framework. Brian defines a header field.

I think we generally understand the requirement here, though it would
probably be good to obtain use cases to be sure. The design choice is
where to include this parameter, and this represents the difference
between the three approaches.

I tend to prefer a Contact URI parameter over a header. My main reason
for that is REGISTER requests. If a register request has multiple
contacts, which contact does the instance identifier apply to? As a
header field, it would be hard to know. If you make it a contact header
field parameter, its no problem. Those header field parameters could
also then be used in the Contact in INVITE/200 SUB/NOT, etc.

Then, the question is whether to use a regular Contact header field
parameter as Cullen has done, or a callee cap parameter as I have done?
The callee cap approach allows for caller preferences to be applied to
routing to a specific instance. Now, a good question is whether such a
thing is needed or even a good idea, if we have GRUU as the ideal way to
route to a UA instance. I can go either way, but welcome thoughts on the
topic.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


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

------_=_NextPart_001_01C3F4A5.8EEE731E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 14:38:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14139 for ; Mon, 16 Feb 2004 14:38:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsoZQ-0001nH-Cy for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 14:38:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GJcI4t006753 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 14:38:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsoZ9-0001gq-FC; Mon, 16 Feb 2004 14:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsoYd-0001SW-AC for sip@optimus.ietf.org; Mon, 16 Feb 2004 14:37:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14103 for ; Mon, 16 Feb 2004 14:37:28 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsoYa-0005MZ-00 for sip@ietf.org; Mon, 16 Feb 2004 14:37:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsoXf-0005Jt-00 for sip@ietf.org; Mon, 16 Feb 2004 14:36:32 -0500 Received: from imo-m02.mx.aol.com ([64.12.136.5]) by ietf-mx with esmtp (Exim 4.12) id 1AsoWw-0005D9-00 for sip@ietf.org; Mon, 16 Feb 2004 14:35:46 -0500 Received: from Mpierce1@aol.com by imo-m02.mx.aol.com (mail_out_v36_r4.14.) id 7.1db.1a1fce8b (3932); Mon, 16 Feb 2004 14:35:02 -0500 (EST) Message-ID: <1db.1a1fce8b.2d627566@aol.com> Date: Mon, 16 Feb 2004 14:35:02 EST Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 (template) To: hgs@cs.columbia.edu, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1db.1a1fce8b.2d627566_boundary" X-Mailer: 6.0 for Windows XP sub 51 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_1db.1a1fce8b.2d627566_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/15/2004 5:57:50 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > (4) Current behavior for DSN, Q.735 specified as non-preemptive. DRSN > left as implementation-defined. Not sure what other behavior one can > specify for priorities. [Rohan] > It is unclear what this note means, since Section 9.5 does not reflect what it says. The -02 draft (Section 9.5) shows "Preemption with rejection" for dsn and drsn and "Precedence" for q735. All three of these cases are services which are titled "Precedence and Preemption". In fact, q735 (and I.255.3 on which it is based) is the same as dsn/drsn, so there should be no difference. It continues to be unclear what this item ("Preemption or precedence") on the template is intended to mean. There is no IANA function related to this type of information, and the contents of this part of the template have no effect on the operation of any device which uses the R-P header. They will do whatever they need to with it depending on the application. For the dsn application, this includes "preemption", "precedence", and probably other treatments that aren't included in either of those terms. In fact, this item seems to be defined differently in Section 9.4 which says "there are many possible behaviors that cannot be exhaustively anticipated" and lists 3 "common" ones. I would still like to see this item deleted from the template, since it can only lead to confusion. If it not deleted, the item on the template should be titled "Behavior" (as in 9.4) and all three namespaces included in the document should indicate "Implementation-defined". Mike --part1_1db.1a1fce8b.2d627566_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/15/2004 5:57:50 PM Eastern Standard Time, hgs@cs.columbia.edu writes= :


(4) Current behavior for DS= N, Q.735 specified as non-preemptive. DRSN=20
left as implementation-defined. Not sure what other behavior one can=20
specify for priorities. [Rohan]


It is unclear what this note means, since Section 9.5 does not reflect w= hat it says. The -02 draft (Section 9.5) shows "Preemption with rejection" f= or dsn and drsn and "Precedence" for q735. All three of these cases are serv= ices which are titled "Precedence and Preemption". In fact, q735 (and I.255.= 3 on which it is based) is the same as dsn/drsn, so there should be no diffe= rence.

It continues to be unclear what this item ("Preemption or precedence") o= n the template is intended to mean. There is no IANA function related to thi= s type of information, and the contents of this part of the template have no= effect on the operation of any device which uses the R-P header. They will=20= do whatever they need to with it depending on the application. For the dsn a= pplication, this includes "preemption", "precedence", and probably other tre= atments that aren't included in either of those terms.  In fact, this i= tem seems to be defined differently in Section 9.4 which says "there are man= y possible behaviors that cannot be exhaustively anticipated" and lists 3 "c= ommon" ones.

I would still like to see this item deleted from the template, since it=20= can only lead to confusion.

If it not deleted, the item on the template should be titled "Behavior"=20= (as in 9.4) and all three namespaces included in the document should indicat= e "Implementation-defined".

Mike --part1_1db.1a1fce8b.2d627566_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 exim@www1.ietf.org Mon Feb 16 14:49:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15092 for ; Mon, 16 Feb 2004 14:49:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asojv-0003X6-8g for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 14:49:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GJnBvC013577 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 14:49:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asojl-0003V8-Py; Mon, 16 Feb 2004 14:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asoji-0003Ul-Iu for sip@optimus.ietf.org; Mon, 16 Feb 2004 14:48:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14989 for ; Mon, 16 Feb 2004 14:48:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asojf-0006YC-00 for sip@ietf.org; Mon, 16 Feb 2004 14:48:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asoik-0006Pa-00 for sip@ietf.org; Mon, 16 Feb 2004 14:47:58 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Asohj-0006Gk-00 for sip@ietf.org; Mon, 16 Feb 2004 14:46:55 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1GJke4w016243; Mon, 16 Feb 2004 14:46:40 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1GJkeH12332; Mon, 16 Feb 2004 14:46:40 -0500 Message-ID: <40311E1F.2070700@cs.columbia.edu> Date: Mon, 16 Feb 2004 14:46:39 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 (template) References: <1db.1a1fce8b.2d627566@aol.com> In-Reply-To: <1db.1a1fce8b.2d627566@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The change note pre-dated my last-minute updates; pardon the rush. My general notion is that IANA registrations should be as useful as possible to the implementor, not just bare-bones information needed to preserve uniqueness. Changing to 'Behavior' is fine by me, with implementation-defined clearly being a viable option, as there are likely to be priority namespaces that simply don't spell out exactly what you're supposed to do, as long as priority X gets better treatment than Y, if prio(X) > prio(Y). Mpierce1@aol.com wrote: > In a message dated 2/15/2004 5:57:50 PM Eastern Standard Time, > hgs@cs.columbia.edu writes: > > >> (4) Current behavior for DSN, Q.735 specified as non-preemptive. DRSN >> left as implementation-defined. Not sure what other behavior one can >> specify for priorities. [Rohan] > > > > It is unclear what this note means, since Section 9.5 does not reflect > what it says. The -02 draft (Section 9.5) shows "Preemption with > rejection" for dsn and drsn and "Precedence" for q735. All three of > these cases are services which are titled "Precedence and Preemption". > In fact, q735 (and I.255.3 on which it is based) is the same as > dsn/drsn, so there should be no difference. > > It continues to be unclear what this item ("Preemption or precedence") > on the template is intended to mean. There is no IANA function related > to this type of information, and the contents of this part of the > template have no effect on the operation of any device which uses the > R-P header. They will do whatever they need to with it depending on the > application. For the dsn application, this includes "preemption", > "precedence", and probably other treatments that aren't included in > either of those terms. In fact, this item seems to be defined > differently in Section 9.4 which says "there are many possible behaviors > that cannot be exhaustively anticipated" and lists 3 "common" ones. > > I would still like to see this item deleted from the template, since it > can only lead to confusion. > > If it not deleted, the item on the template should be titled "Behavior" > (as in 9.4) and all three namespaces included in the document should > indicate "Implementation-defined". > > 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 exim@www1.ietf.org Mon Feb 16 15:12:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16947 for ; Mon, 16 Feb 2004 15:12:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asp69-0003nJ-EA for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 15:12:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKC958014523 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 15:12:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asp60-0003iy-F9; Mon, 16 Feb 2004 15:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asp5Z-0003cL-E0 for sip@optimus.ietf.org; Mon, 16 Feb 2004 15:11:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16801 for ; Mon, 16 Feb 2004 15:11:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asp5W-0000Vi-00 for sip@ietf.org; Mon, 16 Feb 2004 15:11:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asp4b-0000SV-00 for sip@ietf.org; Mon, 16 Feb 2004 15:10:34 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1Asp3m-0000PW-00 for sip@ietf.org; Mon, 16 Feb 2004 15:09:42 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id i1GK9Zp30327; Mon, 16 Feb 2004 15:09:39 -0500 Subject: Re: [Sip] FW: I-D ACTION:draft-khartabil-sip-auth-analysis-00.txt From: Scott Lawrence To: hisham.khartabil@nokia.com Cc: sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797703@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797703@esebe019.ntc.nokia.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Message-Id: <1076953338.3857.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 16 Feb 2004 15:09:37 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2004-02-06 at 02:48, hisham.khartabil@nokia.com wrote: > Having tried to implement HTTP Authentication for SIP, we faced > a few problems. This draft tries to highlight those problems and > in some cases suggests a solution. Comments on draft-khartabil-sip-auth-analysis-00 > 2. Use of 401 and 407 Responses, www-authenticate and > proxy-authenticate headers > [...] > The use of 401 and 407 must be more normative. Text should read: A > UAS that require authentication MUST use 401 in a response and MUST > challenge with a www-authenticate header. Registrars and redirect > servers MUST use 401 and www-authenticate header. Proxies MUST use > 407 and proxy-authenticate header. That would be a clear improvement, I think. > 3. Rendering to user It's not clear to me what it is you're objecting to in this section, except perhaps that the user interface guideline is poorly rendered. The real requirement, I think, is that if the user is being asked for credentials, they should be shown the realm value at that time; a fact that is made clear in RFC 2617 (sec 3.2.1): realm A string to be displayed to users so they know which username and password to use. > 4. Rejected or not > > Section 22.1 of RFC 3261 says: "A UAC MUST NOT re-attempt requests > with the credentials that have just been rejected (though the request > may be retried if the nonce was stale)". > > The problem with this is that how do you know if the request has been > rejected or it is just the next hop proxy challenging with the same > realm? This case couldn't come up in HTTP, since proxy authentication in HTTP is hop-by-hop, and 407 challenges are never passed back to the user agent by a proxy. However, the reset of the description of realm is good advice: ... This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_users@gotham.news.com". > 5. Use of To-header vs. Remote URI (Request-URI) > > Section 22.2 of RFC 3261 says: "The UAC may require input from the > originating user before proceeding. Once authentication credentials > have been supplied (either directly by the user, or discovered in an > internal key-ring), UAs SHOULD cache the credentials for a given > value of the To header field and "realm" and attempt to re-use these > values on the next request for that destination". > > It is more appropriate to cache request-URI, and not rely on what is > in the To-header. Agreed - the To header value is not protected by the hash, so associating it is not appropriate. In addition, this paragraph encourages the existing confusion between these two values (admittedly, they are often the same, but it is the Request URI that is used in authentication). > 7. Caching outbound proxy credentials > > Section 22.3 of RFC 3261 says: "if a UA is configured with the realm > of its local outbound proxy, when one exists, then the UA MAY cache > credentials for that realm across dialogs". > > It cannot be assumed that the domain name of a configured outbound > proxy is its realm. Therefore a terminal configured with only the > outbound proxy URI cannot and MUST NOT cache credentials or any proxy > challenge across dialogs. > > This introduces the problem of multiple proxies in a chain > challenging with the same realm. How does a UAC know that the > challenge was from the outbound proxy and not from a downstream proxy > with the same realm as the outbound proxy? Can we mandate that the > outbound proxy must have a unique realm? As a practical matter, if you have the same username and password in both domains it doesn't matter - if you don't, then it's an impossibly clumsy situation (this problem is part of the reason that we defined proxy authentication to by hop-by-hop in HTTP in the first place). > 9. The realm Issue > > Section 22.3 of RFC 3261 says: "When multiple proxies are used in a > chain, a Proxy-Authorization header field value MUST NOT be consumed > by any proxy whose realm does not match the "realm" parameter > specified in that value". > > Another question: Is it possible that multiple proxies with the same > realm are placed in a chain? I.e. the first proxy challenges, user > provide correct authentication. That proxy authenticates and forwards > the request to a down stream proxy. That down stream proxy has the > same realm as first proxy. There are a few issues here: > examining the nonce is the only solution. Essentially, I think that putting two proxies in a row with the same realm is a difficult configuration to diagnose. If administrators do this, they are asking for trouble. But there is another approach I don't think you examined. > Another issue is at the UAC side. If 2 proxies are in a chain and > share a realm, how does the UAC know, when the second proxy > challenges, that it is not the first proxy re-challenging because the > credentials provided to it were wrong? If the proxy is using the 2617 version of Digest (with the qop attribute) as opposed to the 1867 version, then the UA can tell the difference. The message flow looks like this: UA P1 P2 a +------REQ 1--------->| | b |<----407(1)----------+ | c +------REQ 2 -------->+----REQ 2--------->| e |<---407(2)-----------+<-----407(2)-------| +------REQ 3--------->+----REQ 3--------->| a) initial request b) challenge from P1, with the qop parameter specified c) retried request, with a qop parameter, and therefor also a cnonce chosen by the UA; it is passed on (now without authentication) to P2 d) P2 challenges, also specifying a qop parameter P2 challenge is forwarded by P1, with the WWW-Authenticate header as provided by P2, but also with an Authentication-Info provided by P1. The UA can recognize that authentication to P1 was successful, because P1 returned an Authentication-Info header that contained the cnonce and nc values from message c (REQ 2), and a correct response hash to show that P1 knows the authentication secret. > 10. Authentication-Info > > RFC 3261 allows the usage of Authentication-Info header. The BNF in > RFC 3261 allows multiple authentication-info headers where RFC 2617 > allows only one. Is it only the terminating UAS that is allowed to > insert this header. If so, why allow multiples to be present. If not, > how does the UAC know which proxy added this header? It cannot know > since there is no parameter indicating so, not even nonce. As I noted earlier, 2617 allows only one because proxy authentication is hop-by-hop, but the cnonce value allows the UA to disambiguate them (if they are carefully constructed, but then they should be anyway). All this is even more reason to use qop (which was the intent of 2617 in the first place). -- Scott Lawrence Pingtel Corp. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 15:24:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14136 for ; Mon, 16 Feb 2004 14:38:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsoZQ-0001nG-30 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 14:38:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GJcIPQ006755 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 14:38:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsoZB-0001hI-Ii; Mon, 16 Feb 2004 14:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsoYe-0001TV-Jg for sip@optimus.ietf.org; Mon, 16 Feb 2004 14:37:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14109 for ; Mon, 16 Feb 2004 14:37:29 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsoYb-0005Mj-00 for sip@ietf.org; Mon, 16 Feb 2004 14:37:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsoXj-0005K9-00 for sip@ietf.org; Mon, 16 Feb 2004 14:36:35 -0500 Received: from imo-r04.mx.aol.com ([152.163.225.100]) by ietf-mx with esmtp (Exim 4.12) id 1AsoX4-0005Eg-00 for sip@ietf.org; Mon, 16 Feb 2004 14:35:54 -0500 Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v36_r4.14.) id 7.c0.56078ce (3932); Mon, 16 Feb 2004 14:35:01 -0500 (EST) Message-ID: Date: Mon, 16 Feb 2004 14:35:00 EST Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 To: hgs@cs.columbia.edu CC: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_c0.56078ce.2d627564_boundary" X-Mailer: 6.0 for Windows XP sub 51 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_c0.56078ce.2d627564_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/16/2004 9:41:28 AM Eastern Standard Time, hgs@cs.columbia.edu writes: > There was an early -02 that I only announced to the mailing list, but > never got around to submitting. In any event, the notion of defaults is > gone since it makes no sense in the current setup. > Okay, guess I missed that change. Deleting registration of the default makes sense anyway. It would be part of the procedural details for a specific use of the R-P header instead. Mike --part1_c0.56078ce.2d627564_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/16/2004 9:41:28 AM Eastern Standard Time, hgs@cs.columbia.edu writes= :


There was an early -02 that= I only announced to the mailing list, but=20
never got around to submitting. In any event, the notion of defaults is=20
gone since it makes no sense in the current setup.


Okay, guess I missed that change. Deleting registration of the default m= akes sense anyway. It would be part of the procedural details for a specific= use of the R-P header instead.

Mike
--part1_c0.56078ce.2d627564_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 exim@www1.ietf.org Mon Feb 16 15:42:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20451 for ; Mon, 16 Feb 2004 15:42:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZF-000385-KQ for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKgDWR011941 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZ3-00030K-BU; Mon, 16 Feb 2004 15:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspY7-0002WY-Si for sip@optimus.ietf.org; Mon, 16 Feb 2004 15:41:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20081; Mon, 16 Feb 2004 15:41:01 -0500 (EST) Message-Id: <200402162041.PAA20081@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: Mon, 16 Feb 2004 15:41:00 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-publish-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol (SIP) Extension for Event State Publication Author(s) : A. Niemi Filename : draft-ietf-sip-publish-03.txt Pages : 40 Date : 2004-2-16 This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the framework for SIP Event Notification. The first application of this extension is targeted at the publication of presence information. The mechanism described in this document can be extended to support publication of any event state, for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose (FTP, HTTP, etc.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-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-publish-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-publish-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: <2004-2-16123306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-publish-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-publish-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16123306.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 15:58:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23206 for ; Mon, 16 Feb 2004 15:58:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aspoc-0004vy-Jf for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 15:58:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKw6xM018949 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 15:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspoX-0004uN-8R; Mon, 16 Feb 2004 15:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aspng-0004t9-3m for sip@optimus.ietf.org; Mon, 16 Feb 2004 15:57:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22997 for ; Mon, 16 Feb 2004 15:57:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aspnb-0005H6-00 for sip@ietf.org; Mon, 16 Feb 2004 15:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspmI-00053E-00 for sip@ietf.org; Mon, 16 Feb 2004 15:55:43 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsplF-0004lU-00 for sip@ietf.org; Mon, 16 Feb 2004 15:54:42 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1GKs7Nr005252; Mon, 16 Feb 2004 15:54:08 -0500 (EST) Message-ID: <40312DE4.3050804@dynamicsoft.com> Date: Mon, 16 Feb 2004 15:53:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Stucker CC: sip@ietf.org Subject: Re: [Sip] SIP instance identifiers References: <161AA64DA85DFC4BA4D2EB5629B5975304AB8D9D@zrc2c012.us.nortel.com> In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B5975304AB8D9D@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Brian Stucker wrote: > Johnathan, > > I'm not opposed to the client ID being transported in the registration > contact, > but seeing as there were two drafts that already discuss that, I didn't see > much point in rehashing it again in my draft. =) > > I believe there are some important points that you're leaving out. > > Besides being client generated (which reduces the requirements for > generating > the ID) there are advantages to NOT mandating that the ID be expressed only > as a parameter in the contact of a registration. > > The idea behind the GUID (and hence the lack of a specific usecase in the > -00 version of the document) is that it can be used for other activities. > I'm not opposed to communicating the ID in a contact parameter as well as > a regular header, I just don't view transporting it in a contact header > as being always necessary or desirable depending on what you want to do > with it. I think the key thing we need to do first is figure out what it is we want to do with it (i.e., requirements!). I am principally interested in its usage with GRUU. In that usage, it is necessary to be carried in the contact header. > > Sending it as a header allows for some interesting behavior to occur on > non-registration requests: > > - Can be used to eliminate duplicate subscriptions due to client's state > being wiped out (ie. ignore the callid/tags of an existing subscription > if the client ID matches the client ID of that subscription [and the other > information about the subscription is the same]). I'm not sure this is good behavior though. Its perfectly fine to have two subscriptions to the same thing from the same UA instance. If the state is wiped out and the client sends a second subscription, the first will either time out, or if the server sends a NOTIFY, the NOTIFY will time out or generatea a 481, both of which terminate the first subscription. This behavior seems fine. > - Can be used to identify the client sending a request across networks > where no other identifier is easily obtainable (NATs and the such), or > BBUAs are present in the network. OK, but whats the use case? > - Can be used to identify the source of state information being pushed > into the network (presence update, etc). This is one area where conveying > the information in a contact seems a little cumbersome. The request may > not be sent to the registrar, and a contact may otherwise be completely > unnecessary. OK, this is a fair point. There does appear to be a need in PUBLISH (more in pidf I think) for having a unique identifier of the source of the publication. > > In the cases where registration behavior is controlled, it requires a > change > to the registrar in order to capture the appropriate behavior that > should be > taken wrt a client ID. Therefore, including the information as a header or > in the contact seems moot to me as either mechanism can easily be made to > work. Perhaps there's a usecase I'm not considering? If you put it in a header, you would need to include additional parameters to correlate it to the specific Contact in a registration that it applies to. This can work, but its messy and unnecessary if you include the guid in the contact directly. > > Additionally, I believe that there needs to be some convergence on the > approach > taken by generating the identifier itself. The mechanism that is suggested > in your draft seems to rely upon a server to generate the unique > identifier, No, the instance ID is generated by the client. I just don't say how. I think there are specs that give guidance on generating unique IDs. I couldnt find an rfc reference, maybe it was somewhere else, but this is well-trod territory. I dont think our requirements for unique identifiers are different than anyone elses. > whereas in the other two drafts, it is the client that generates the > unique identifier. I believe there are advantages to each. I think the client has to generate it always. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 16:00:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23565 for ; Mon, 16 Feb 2004 16:00:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aspqg-0005Lk-NH for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 16:00:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GL0E4B020502 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 16:00:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspqX-0005FC-Ed; Mon, 16 Feb 2004 16:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspqH-0005Da-Kd for sip@optimus.ietf.org; Mon, 16 Feb 2004 15:59:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23443 for ; Mon, 16 Feb 2004 15:59:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspqG-0005lw-00 for sip@ietf.org; Mon, 16 Feb 2004 15:59:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsppH-0005aq-00 for sip@ietf.org; Mon, 16 Feb 2004 15:58:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aspo6-0005H8-00 for sip@ietf.org; Mon, 16 Feb 2004 15:57:34 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1GKulNr005261; Mon, 16 Feb 2004 15:56:51 -0500 (EST) Message-ID: <40312E87.1020003@dynamicsoft.com> Date: Mon, 16 Feb 2004 15:56:39 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: fluffy@cisco.com, sip@ietf.org Subject: Re: [Sip] draft-khartabil-sip-policy-uri-call-info-purpose-00 References: <2038BCC78B1AD641891A0D1AE133DBB701797753@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797753@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think one could provide links to other policy documents, but this is best done via other purpose tags. "policy" is pretty general, and I think you want to be as specific as possible here. -Jonathan R. hisham.khartabil@nokia.com wrote: > Thanks. > > Do you think that it will only be limited to conferences? > > /Hisham > > >>-----Original Message----- >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext >>Cullen Jennings >>Sent: 13.February.2004 18:49 >>To: sip@ietf.org >>Subject: [Sip] draft-khartabil-sip-policy-uri-call-info-purpose-00 >> >> >> >>I like this draft, just one little NIT, I think it would be >>better to call >>the tag conf-policy-info instead of just policy-info >> >>Cullen >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 16:19:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26543 for ; Mon, 16 Feb 2004 16:19:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asq94-0007LN-VX for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 16:19:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GLJE8N028167 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 16:19:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asq8r-0007H1-F7; Mon, 16 Feb 2004 16:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asq7u-000764-02 for sip@optimus.ietf.org; Mon, 16 Feb 2004 16:18:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26042 for ; Mon, 16 Feb 2004 16:17:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asq7s-0001C9-00 for sip@ietf.org; Mon, 16 Feb 2004 16:18:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asq5s-0000mf-00 for sip@ietf.org; Mon, 16 Feb 2004 16:16:01 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1Asq3t-0000Ei-00 for sip@ietf.org; Mon, 16 Feb 2004 16:13:53 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1GLD9806427; Mon, 16 Feb 2004 15:13:09 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV8NAQ>; Mon, 16 Feb 2004 15:13:10 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304AB960F@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] SIP instance identifiers Date: Mon, 16 Feb 2004 15:13:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F4D1.ABDD86F0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F4D1.ABDD86F0 Content-Type: text/plain; charset="iso-8859-1" inline some more. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, February 16, 2004 2:54 PM > To: Stucker, Brian [NGC:B617:EXCH] > Cc: sip@ietf.org > Subject: Re: [Sip] SIP instance identifiers > > > inline. > > Brian Stucker wrote: > > > Johnathan, > > > > I'm not opposed to the client ID being transported in the > registration > > contact, > > but seeing as there were two drafts that already discuss > that, I didn't see > > much point in rehashing it again in my draft. =) > > > > I believe there are some important points that you're leaving out. > > > > Besides being client generated (which reduces the requirements for > > generating > > the ID) there are advantages to NOT mandating that the ID > be expressed only > > as a parameter in the contact of a registration. > > > > The idea behind the GUID (and hence the lack of a specific > usecase in the > > -00 version of the document) is that it can be used for > other activities. > > I'm not opposed to communicating the ID in a contact > parameter as well as > > a regular header, I just don't view transporting it in a > contact header > > as being always necessary or desirable depending on what > you want to do > > with it. > > I think the key thing we need to do first is figure out what it is we > want to do with it (i.e., requirements!). I am principally > interested in > its usage with GRUU. In that usage, it is necessary to be > carried in the > contact header. > I'm open to a number of requirements, but simply constraining the set of things we ought to try to tackle simple to what's in GRUU seems to miss the opportunity to kill multiple birds with one stone. I'd like to see a solution that encapsulates as many usecases as possible, and I'm not adverse to the idea of carrying the ID in the contact header itself. I just don't think that's the ONLY place it makes sense to send it. > > > > Sending it as a header allows for some interesting behavior > to occur on > > non-registration requests: > > > > - Can be used to eliminate duplicate subscriptions due to > client's state > > being wiped out (ie. ignore the callid/tags of an existing > subscription > > if the client ID matches the client ID of that subscription > [and the other > > information about the subscription is the same]). > > I'm not sure this is good behavior though. Its perfectly fine to have > two subscriptions to the same thing from the same UA instance. If the > state is wiped out and the client sends a second > subscription, the first > will either time out, or if the server sends a NOTIFY, the > NOTIFY will > time out or generatea a 481, both of which terminate the first > subscription. This behavior seems fine. Sometimes it's OK, sometimes it's not. Let's give ourselves the option to choose when we want this type of behavior (which I would think would generally be rare considering we'd be sending an extra NOTIFY and holding onto a subscription for no apparent reason). Using an ID to uniquely identify the client can help to reduce unwanted traffic. Is it the only way it can be done? No. But it is a handy way to do it if we're not adverse to including this type of information in requests. > > > - Can be used to identify the client sending a request > across networks > > where no other identifier is easily obtainable (NATs and > the such), or > > BBUAs are present in the network. > > OK, but whats the use case? Can be used to correlate requests from the same client where IP addresses may not be available at all nodes, and the context-matching information may have been jumbled by a BBUA. Can use useful for matching up calls to other non-call transactions, etc. > > > > - Can be used to identify the source of state information > being pushed > > into the network (presence update, etc). This is one area > where conveying > > the information in a contact seems a little cumbersome. The > request may > > not be sent to the registrar, and a contact may otherwise > be completely > > unnecessary. > > OK, this is a fair point. There does appear to be a need in PUBLISH > (more in pidf I think) for having a unique identifier of the > source of > the publication. > Glad we agree on something. =) > > > > In the cases where registration behavior is controlled, it > requires a > > change > > to the registrar in order to capture the appropriate behavior that > > should be > > taken wrt a client ID. Therefore, including the information > as a header or > > in the contact seems moot to me as either mechanism can > easily be made to > > work. Perhaps there's a usecase I'm not considering? > > If you put it in a header, you would need to include additional > parameters to correlate it to the specific Contact in a registration > that it applies to. This can work, but its messy and > unnecessary if you > include the guid in the contact directly. > This is a good point. In that case it makes sense to put it into the contacts for the registration, but once again, I'm not trying to exclude this option in my draft. It was already discussed elsewhere, so there seemed no need to go back over it. > > > > Additionally, I believe that there needs to be some > convergence on the > > approach > > taken by generating the identifier itself. The mechanism > that is suggested > > in your draft seems to rely upon a server to generate the unique > > identifier, > > No, the instance ID is generated by the client. I just don't > say how. I > think there are specs that give guidance on generating unique IDs. I > couldnt find an rfc reference, maybe it was somewhere else, > but this is > well-trod territory. I dont think our requirements for unique > identifiers are different than anyone elses. > True enough. I just wanted to put in some ground-rules so we avoid some of the troubles that you find in poor implementations of callid/tag generators for the SIP stack. Sometimes it's helpful to put a baseline out there so people are at a minimum cognizant of what they're getting themselves into that may not otherwise be obvious to the implementor. > > whereas in the other two drafts, it is the client that generates the > > unique identifier. I believe there are advantages to each. > > I think the client has to generate it always. Sometimes it makes sense for the server to generate it, especially if the server is a trusted third-party and the ID is used for some sort of non-repudiation tactic. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > ------_=_NextPart_001_01C3F4D1.ABDD86F0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] SIP instance identifiers

inline some more.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, February 16, 2004 2:54 PM
> To: Stucker, Brian [NGC:B617:EXCH]
> Cc: sip@ietf.org
> Subject: Re: [Sip] SIP instance identifiers
>
>
> inline.
>
> Brian Stucker wrote:
>
> > Johnathan,
> >
> > I'm not opposed to the client ID being transported in the
> registration
> > contact,
> > but seeing as there were two drafts that already discuss
> that, I didn't see
> > much point in rehashing it again in my draft. =)
> >
> > I believe there are some important points that you're leaving out.
> >
> > Besides being client generated (which reduces the requirements for
> > generating
> > the ID) there are advantages to NOT mandating that the ID
> be expressed only
> > as a parameter in the contact of a registration.
> >
> > The idea behind the GUID (and hence the lack of a specific
> usecase in the
> > -00 version of the document) is that it can be used for
> other activities.
> > I'm not opposed to communicating the ID in a contact
> parameter as well as
> > a regular header, I just don't view transporting it in a
> contact header
> > as being always necessary or desirable depending on what
> you want to do
> > with it.
>
> I think the key thing we need to do first is figure out what it is we
> want to do with it (i.e., requirements!). I am principally
> interested in
> its usage with GRUU. In that usage, it is necessary to be
> carried in the
> contact header.
>

I'm open to a number of requirements, but simply constraining the set of
things we ought to try to tackle simple to what's in GRUU seems to miss
the opportunity to kill multiple birds with one stone. I'd like to see
a solution that encapsulates as many usecases as possible, and I'm not
adverse to the idea of carrying the ID in the contact header itself. I
just don't think that's the ONLY place it makes sense to send it.

> >
> > Sending it as a header allows for some interesting behavior
> to occur on
> > non-registration requests:
> >
> > - Can be used to eliminate duplicate subscriptions due to
> client's state
> > being wiped out (ie. ignore the callid/tags of an existing
> subscription
> > if the client ID matches the client ID of that subscription
> [and the other
> > information about the subscription is the same]).
>
> I'm not sure this is good behavior though. Its perfectly fine to have
> two subscriptions to the same thing from the same UA instance. If the
> state is wiped out and the client sends a second
> subscription, the first
> will either time out, or if the server sends a NOTIFY, the
> NOTIFY will
> time out or generatea a 481, both of which terminate the first
> subscription. This behavior seems fine.

Sometimes it's OK, sometimes it's not. Let's give ourselves the option
to choose when we want this type of behavior (which I would think would
generally be rare considering we'd be sending an extra NOTIFY and holding
onto a subscription for no apparent reason). Using an ID to uniquely
identify the client can help to reduce unwanted traffic. Is it the only
way it can be done? No. But it is a handy way to do it if we're not
adverse to including this type of information in requests.

>
> > - Can be used to identify the client sending a request
> across networks
> > where no other identifier is easily obtainable (NATs and
> the such), or
> > BBUAs are present in the network.
>
> OK, but whats the use case?

Can be used to correlate requests from the same client where IP
addresses may not be available at all nodes, and the context-matching
information may have been jumbled by a BBUA. Can use useful for matching
up calls to other non-call transactions, etc.

>
>
> > - Can be used to identify the source of state information
> being pushed
> > into the network (presence update, etc). This is one area
> where conveying
> > the information in a contact seems a little cumbersome. The
> request may
> > not be sent to the registrar, and a contact may otherwise
> be completely
> > unnecessary.
>
> OK, this is a fair point. There does appear to be a need in PUBLISH
> (more in pidf I think) for having a unique identifier of the
> source of
> the publication.
>

Glad we agree on something. =)

> >
> > In the cases where registration behavior is controlled, it
> requires a
> > change
> > to the registrar in order to capture the appropriate behavior that
> > should be
> > taken wrt a client ID. Therefore, including the information
> as a header or
> > in the contact seems moot to me as either mechanism can
> easily be made to
> > work. Perhaps there's a usecase I'm not considering?
>
> If you put it in a header, you would need to include additional
> parameters to correlate it to the specific Contact in a registration
> that it applies to. This can work, but its messy and
> unnecessary if you
> include the guid in the contact directly.
>

This is a good point. In that case it makes sense to put it into the
contacts for the registration, but once again, I'm not trying to exclude
this option in my draft. It was already discussed elsewhere, so there seemed
no need to go back over it.

> >
> > Additionally, I believe that there needs to be some
> convergence on the
> > approach
> > taken by generating the identifier itself. The mechanism
> that is suggested
> > in your draft seems to rely upon a server to generate the unique
> > identifier,
>
> No, the instance ID is generated by the client. I just don't
> say how. I
> think there are specs that give guidance on generating unique IDs. I
> couldnt find an rfc reference, maybe it was somewhere else,
> but this is
> well-trod territory. I dont think our requirements for unique
> identifiers are different than anyone elses.
>

True enough. I just wanted to put in some ground-rules so we avoid some
of the troubles that you find in poor implementations of callid/tag generators
for the SIP stack. Sometimes it's helpful to put a baseline out there so people
are at a minimum cognizant of what they're getting themselves into that may
not otherwise be obvious to the implementor.

> > whereas in the other two drafts, it is the client that generates the
> > unique identifier. I believe there are advantages to each.
>
> I think the client has to generate it always.

Sometimes it makes sense for the server to generate it, especially if the
server is a trusted third-party and the ID is used for some sort of non-repudiation
tactic.

>
> -Jonathan R.
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

------_=_NextPart_001_01C3F4D1.ABDD86F0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 16 18:54:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13324 for ; Mon, 16 Feb 2004 18:54:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssZ1-0000Ts-Fv for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 18:54:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GNsB8h001786 for sip-archive@odin.ietf.org; Mon, 16 Feb 2004 18:54:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssYr-0000Rf-F3; Mon, 16 Feb 2004 18:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssYS-0000Q2-CQ for sip@optimus.ietf.org; Mon, 16 Feb 2004 18:53:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13185 for ; Mon, 16 Feb 2004 18:53:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssYP-0005jT-00 for sip@ietf.org; Mon, 16 Feb 2004 18:53:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AssX4-0005U4-00 for sip@ietf.org; Mon, 16 Feb 2004 18:52:11 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AssVX-00052a-00 for sip@ietf.org; Mon, 16 Feb 2004 18:50:35 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 16576; Mon, 16 Feb 2004 18:50:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on history-info Date: Mon, 16 Feb 2004 18:49:59 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A194@zoe.office.snowshore.com> Thread-Topic: [Sip] Comments on history-info Thread-Index: AcP0nVvv5H5tdxfTRFqHJsqonTp2AwAQXKyA From: "Eric Burger" To: "Mary Barnes" , "SIP List (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I'm not changing any of the functionality. As Rohan says, it is already = in the spec. I'm suggesting we do not allow a proxy to *modify* an = existing history-info header. A proxy can (and should) *insert* new = history-info headers. It is because we have the index tag that the = modification restriction should not be a problem. > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] > Sent: Monday, February 16, 2004 9:58 AM > To: Eric Burger; SIP List (E-mail) > Subject: RE: [Sip] Comments on history-info >=20 >=20 > Eric, >=20 > History-Info is a bit different than the SMTP (at least as best as I > understand SMTP not being an expert in that area), since the=20 > retargeting in > SIP is more complicated that SMTP due to forking, etc. In=20 > order to be able > to accurately reflecting the forking, we've added the index. =20 > The index is > used to generate subsequent History-Info entries. In=20 > addition, there's the > Reason that gets added to the targeted-to URIs to reflect the=20 > reason for the > retargeting. So, yes History-Info does change History in the=20 > sense that we > embellish the Request-URIs that are "visited" with additional=20 > information > that seems to be useful to a variety of end applications. =20 > So, I think what > you're proposing would only provide a subset of the=20 > functionality that we're > after. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Sunday, February 15, 2004 5:00 PM > To: Barnes, Mary [NGC:B622:EXCH]; SIP List (E-mail) > Subject: RE: [Sip] Comments on history-info >=20 >=20 > Excellent. >=20 > Thinking about it a bit more, is there any reason to ALLOW=20 > stuffing multiple > history info info's on a single line? The idea going back to=20 > SMTP was that > you are only allowed to add history, not change it. Putting multiple > history info's in a single history-info header, by definition, changes > history. >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortelnetworks.com] > > Sent: Sunday, February 15, 2004 3:18 PM > > To: Eric Burger; SIP List (E-mail) > > Subject: RE: [Sip] Comments on history-info > >=20 > >=20 > > Eric, > >=20 > > Although Rohan responded to your "Big question:" part of this email: > > http://www1.ietf.org/mail-archive/working-groups/sip/current/m > > sg08998.html > > it doesn't appear that I ever responded to the remaining=20 > > points on the list. > > Thank you for reviewing the draft and providing detailed=20 > > comments. In > > updating the draft, I considered your comments as indicated=20 > > below [MB]. > >=20 > > Regards, > > Mary.=20 > >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Thursday, November 06, 2003 3:44 AM > > To: SIP List (E-mail) > > Subject: [Sip] Comments on history-info > >=20 > >=20 > > Big question: > > Why don't we use multiple History-Info headers, instead of a=20 > > (potentially > > VERY long) single header? > >=20 > > I would argue for multiple headers on two grounds. > >=20 > > First, the idea of a proxy modifying history information=20 > doesn't sound > > smart. If it screws up, it is hard to figure out who screwed up. > >=20 > > Second, the index parameter frees us from worrying about=20 > > header order, which > > is a VERY good thing. > >=20 > >=20 > >=20 > > Overview: > > While the motivation for History-Info is for the initiator of=20 > > a request to > > know what happened to a request, it is also of great use to=20 > > the recipient > > (End of Section 2 overview paragraph). > >=20 > > [MB]: I've clarified this.=20 > >=20 > > Section 1.2: > > How is History-Info any different than Via w.r.t. security? > >=20 > > [MB]: It's quite similar actually, so I've added a statement=20 > > to that effect > > in this section. I think the only difference being the=20 > > dependency on the > > Index written by the previous hop to generate the index for=20 > > the current hop. > > I do think the general M2M and M2E security solution would also be > > applicable to Via if TLS were not deemed to be sufficient=20 > > (i.e if there were > > some reason why you would not want some intermediaries to be=20 > > able to see the > > Via added by an "untrusted" intermediary). =20 > >=20 > > Nits: > > Section 2.5, first paragraph, last sentence: > > this would like be a local > > this would likely be a local > > ^^ > > [MB]: Fixed.=20 > >=20 > > Appendix B, message F8, extra space before last angle-bracket in the > > History-Info line. > >=20 > > [MB]: Fixed. > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 02:52:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15238 for ; Tue, 17 Feb 2004 02:52:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At01i-0001kR-2w for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 02:52:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H7qHWX006716 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 02:52:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At01T-0001j3-Dm; Tue, 17 Feb 2004 02:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsjHR-0007p0-3c for sip@optimus.ietf.org; Mon, 16 Feb 2004 08:59:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18475 for ; Mon, 16 Feb 2004 08:59:22 -0500 (EST) From: schatterjee@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsjHO-0005t0-00 for sip@ietf.org; Mon, 16 Feb 2004 08:59:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsjGT-0005kX-00 for sip@ietf.org; Mon, 16 Feb 2004 08:58:26 -0500 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1AsjFQ-0005dM-00; Mon, 16 Feb 2004 08:57:21 -0500 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i1GDtrD20441; Mon, 16 Feb 2004 19:26:03 +0530 To: sipping@ietf.org, sip@ietf.org, schulzrinne@cs.columbia.edu, jmpolk@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Mon, 16 Feb 2004 19:26:30 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 02/16/2004 07:26:56 PM, Serialize complete at 02/16/2004 07:26:56 PM Content-Type: multipart/alternative; boundary="=_alternative 004C9F4365256E3C_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] Question regarding resource-priority header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 004C9F4365256E3C_= Content-Type: text/plain; charset="US-ASCII" Hi, In draft-ietf-sip-resource-priority-01.txt, it looks like there is a printing mistake in the grammar defined for Resource-Priority header . Its given as Resource-Priority = "Resource-Priority" HCOLON (*COMMA Resource-value) But I guess, no header can start with a COMMA . It should actually be Resource-Priority = "Resource-Priority" HCOLON Resource-value(*COMMA Resource-value) This is the way the grammar is given for Accept-Resource-Priority. Can anyone confirm on this pls? thanks in advance... --=_alternative 004C9F4365256E3C_= Content-Type: text/html; charset="US-ASCII"
Hi,

In draft-ietf-sip-resource-priority-01.txt, it looks like there is a printing mistake in the grammar defined for Resource-Priority header . Its given as
       Resource-Priority  =  "Resource-Priority" HCOLON
                              (*COMMA Resource-value)
 
But I guess, no header can start with a COMMA . It should actually be
       Resource-Priority  =  "Resource-Priority" HCOLON
                              Resource-value(*COMMA Resource-value)

This is the way the grammar is given for Accept-Resource-Priority.
Can anyone confirm on this pls?

thanks in advance...
--=_alternative 004C9F4365256E3C_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 09:31:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29767 for ; Tue, 17 Feb 2004 09:31:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Fi-0003tR-FW for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 09:31:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HEVABk014964 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 09:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Fb-0003qY-8X; Tue, 17 Feb 2004 09:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Ef-0003p6-QQ for sip@optimus.ietf.org; Tue, 17 Feb 2004 09:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29687 for ; Tue, 17 Feb 2004 09:30:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6Ee-00035l-00 for sip@ietf.org; Tue, 17 Feb 2004 09:30:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6Dj-00032p-00 for sip@ietf.org; Tue, 17 Feb 2004 09:29:08 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1At6Cy-0002xQ-00 for sip@ietf.org; Tue, 17 Feb 2004 09:28:20 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2004 06:27:49 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1HERmhu019474; Tue, 17 Feb 2004 09:27:48 -0500 (EST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC31025; Tue, 17 Feb 2004 09:27:47 -0500 (EST) Message-ID: <403224E2.5070401@cisco.com> Date: Tue, 17 Feb 2004 09:27:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org Subject: Re: [Sip] Binary Encoding for SIP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen, This is an attractive proposal because it has potential to make sip implementations simpler. But before I can answer I need clarification on one thing: Does this apply to content referenced and fetched via content-indirection? This proposal only has value if my mime processor *never* needs to deal with any content-transfer-encoding other than binary. If content referenced by content indirection still might use other encodings, then that value is lost. Unfortunately, given the potential range of transports that might be used with content indirection, I don't know if requiring binary can be done in general. Paul Cullen Jennings wrote: > > I submitted a draft on binary encoding for SIP. This improves > interoperability, improves speed, decreases sizes of messages, and generally > makes life better for SIP which will no doubt eventually help with World > Hunger. I need feedback, please let me know: > > a) Yah, lets do it > > b) No this is a stupid ideas and here are the reasons why > > c) There has not been many list comments, this draft involves some very > complex issues. I need a year or two to develop an opinion on the single > sentence inside it. > > d) I agree with Cowboy Willis > > Until it arrives in the archives, you can find it at > > http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html > > or, if you prefer ASCII encodings of everything, > > www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt > > Thanks, Cullen > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 10:00:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01123 for ; Tue, 17 Feb 2004 10:00:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6hx-0006pH-P7 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 10:00:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HF0L3r026238 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 10:00:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6hi-0006gN-Ft; Tue, 17 Feb 2004 10:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6gt-0006bd-AP for sip@optimus.ietf.org; Tue, 17 Feb 2004 09:59:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01005 for ; Tue, 17 Feb 2004 09:59:12 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6gr-0005GC-00 for sip@ietf.org; Tue, 17 Feb 2004 09:59:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6g0-0005C7-00 for sip@ietf.org; Tue, 17 Feb 2004 09:58:21 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1At6fS-00057y-00 for sip@ietf.org; Tue, 17 Feb 2004 09:57:46 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HEvgT28553; Tue, 17 Feb 2004 16:57:42 +0200 (EET) X-Scanned: Tue, 17 Feb 2004 16:57:34 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1HEvYYD027922; Tue, 17 Feb 2004 16:57:34 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00oVSAD4; Tue, 17 Feb 2004 16:57:33 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HEvWO11027; Tue, 17 Feb 2004 16:57:33 +0200 (EET) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 17 Feb 2004 16:57:18 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] FW: I-D ACTION:draft-khartabil-sip-auth-analysis-00.txt Date: Tue, 17 Feb 2004 16:57:17 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179776C@esebe019.ntc.nokia.com> Thread-Topic: [Sip] FW: I-D ACTION:draft-khartabil-sip-auth-analysis-00.txt Thread-Index: AcP0yND+jHVCFuqYQGmlihPZhcllAAAmsGvw To: Cc: X-OriginalArrivalTime: 17 Feb 2004 14:57:18.0023 (UTC) FILETIME=[56529D70:01C3F566] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Scott, Thanks for the comments. Responses inline... > -----Original Message----- > From: ext Scott Lawrence [mailto:slawrence@pingtel.com] > Sent: 16.February.2004 22:10 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: sip@ietf.org > Subject: Re: [Sip] FW: I-D > ACTION:draft-khartabil-sip-auth-analysis-00.txt >=20 >=20 > On Fri, 2004-02-06 at 02:48, hisham.khartabil@nokia.com wrote: > > Having tried to implement HTTP Authentication for SIP, we faced=20 > > a few problems. This draft tries to highlight those problems and=20 > > in some cases suggests a solution. >=20 > Comments on draft-khartabil-sip-auth-analysis-00 >=20 > > 2. Use of 401 and 407 Responses, www-authenticate and > > proxy-authenticate headers > > [...] > > The use of 401 and 407 must be more normative. Text should read: A > > UAS that require authentication MUST use 401 in a response and MUST > > challenge with a www-authenticate header. Registrars and redirect > > servers MUST use 401 and www-authenticate header. Proxies MUST use > > 407 and proxy-authenticate header. >=20 > That would be a clear improvement, I think. >=20 > > 3. Rendering to user >=20 > It's not clear to me what it is you're objecting to in this section, > except perhaps that the user interface guideline is poorly rendered. Yes, this is the point I was trying to make. The fact that a username = and password for a realm is preconfigured does not mean that the user = does not get to re-enter those credentials if the server rejected the = ones sent earlier. >=20 > The real requirement, I think, is that if the user is being asked for > credentials, they should be shown the realm value at that time; a fact > that is made clear in RFC 2617 (sec 3.2.1): >=20 > realm > A string to be displayed to users so they know which username and > password to use. I don't think this takes into consideration pre-configuration. >=20 > > 4. Rejected or not > > > > Section 22.1 of RFC 3261 says: "A UAC MUST NOT re-attempt requests > > with the credentials that have just been rejected (though=20 > the request > > may be retried if the nonce was stale)". > > > > The problem with this is that how do you know if the=20 > request has been > > rejected or it is just the next hop proxy challenging with the same > > realm? >=20 > This case couldn't come up in HTTP, since proxy authentication in HTTP > is hop-by-hop, and 407 challenges are never passed back to the user > agent by a proxy. =20 In SIP, unfortunately it is possible. > However, the reset of the description of realm is > good advice: >=20 > ... This string should contain at least the name of > the host performing the authentication and might additionally > indicate the collection of users who might have access. An example > might be "registered_users@gotham.news.com". Can we mandate that for SIP?? >=20 > > 5. Use of To-header vs. Remote URI (Request-URI) > > > > Section 22.2 of RFC 3261 says: "The UAC may require input from the > > originating user before proceeding. Once authentication=20 > credentials > > have been supplied (either directly by the user, or=20 > discovered in an > > internal key-ring), UAs SHOULD cache the credentials for a given > > value of the To header field and "realm" and attempt to=20 > re-use these > > values on the next request for that destination". > > > > It is more appropriate to cache request-URI, and not rely=20 > on what is > > in the To-header. >=20 > Agreed - the To header value is not protected by the hash, so > associating it is not appropriate. In addition, this paragraph > encourages the existing confusion between these two values > (admittedly, they are often the same, but it is the Request URI that > is used in authentication). >=20 > > 7. Caching outbound proxy credentials > > > > Section 22.3 of RFC 3261 says: "if a UA is configured with=20 > the realm > > of its local outbound proxy, when one exists, then the UA MAY cache > > credentials for that realm across dialogs". > > > > It cannot be assumed that the domain name of a configured outbound > > proxy is its realm. Therefore a terminal configured with only the > > outbound proxy URI cannot and MUST NOT cache credentials=20 > or any proxy > > challenge across dialogs. > > > > This introduces the problem of multiple proxies in a chain > > challenging with the same realm. How does a UAC know that the > > challenge was from the outbound proxy and not from a=20 > downstream proxy > > with the same realm as the outbound proxy? Can we mandate that the > > outbound proxy must have a unique realm? >=20 > As a practical matter, if you have the same username and password in > both domains it doesn't matter - if you don't, then it's an impossibly > clumsy situation (this problem is part of the reason that we defined > proxy authentication to by hop-by-hop in HTTP in the first place). Perhaps I was not clear in my text. Imagine this scenario: I have cached = my credentials for an outbound proxy with realm proxy.nokia.com from an = earlier transaction. Now I send a new INVITE routed through the outbound = proxy that gets a 407 from a second proxy with the same realm. How do I = know if the 407 came from the outbound proxy (the username password = might have changed in the meantime) or from the next hop proxy? >=20 > > 9. The realm Issue > > > > Section 22.3 of RFC 3261 says: "When multiple proxies are used in a > > chain, a Proxy-Authorization header field value MUST NOT=20 > be consumed > > by any proxy whose realm does not match the "realm" parameter > > specified in that value". > > > > Another question: Is it possible that multiple proxies=20 > with the same > > realm are placed in a chain? I.e. the first proxy challenges, user > > provide correct authentication. That proxy authenticates=20 > and forwards > > the request to a down stream proxy. That down stream proxy has the > > same realm as first proxy. There are a few issues here: >=20 > > examining the nonce is the only solution. >=20 > Essentially, I think that putting two proxies in a row with the same > realm is a difficult configuration to diagnose. If administrators do > this, they are asking for trouble. But there is another approach I > don't think you examined. >=20 > > Another issue is at the UAC side. If 2 proxies are in a chain and > > share a realm, how does the UAC know, when the second proxy > > challenges, that it is not the first proxy re-challenging=20 > because the > > credentials provided to it were wrong? >=20 > If the proxy is using the 2617 version of Digest (with the qop > attribute) as opposed to the 1867 version, then the UA can tell > the difference. The message flow looks like this: >=20 > UA P1 P2 > a +------REQ 1--------->| | > b |<----407(1)----------+ | > c +------REQ 2 -------->+----REQ 2--------->| > e |<---407(2)-----------+<-----407(2)-------| > +------REQ 3--------->+----REQ 3--------->| >=20 > a) initial request > b) challenge from P1, with the qop parameter specified > c) retried request, with a qop parameter, and therefor also a cnonce > chosen by the UA; it is passed on (now without=20 > authentication) to P2 > d) P2 challenges, also specifying a qop parameter > P2 challenge is forwarded by P1, with the WWW-Authenticate > header as provided by P2, but also with an Authentication-Info > provided by P1. >=20 > The UA can recognize that authentication to P1 was successful, because > P1 returned an Authentication-Info header that contained the cnonce > and nc values from message c (REQ 2), and a correct response hash to > show that P1 knows the authentication secret. This is not mandated for SIP entities, maybe it aught to be. >=20 > > 10. Authentication-Info > > > > RFC 3261 allows the usage of Authentication-Info header. The BNF in > > RFC 3261 allows multiple authentication-info headers where RFC 2617 > > allows only one. Is it only the terminating UAS that is allowed to > > insert this header. If so, why allow multiples to be=20 > present. If not, > > how does the UAC know which proxy added this header? It cannot know > > since there is no parameter indicating so, not even nonce. >=20 > As I noted earlier, 2617 allows only one because proxy authentication > is hop-by-hop, but the cnonce value allows the UA to disambiguate them > (if they are carefully constructed, but then they should be anyway). SIP BNF allows multiples of those headers. Is this a BNF bug? If not, = then some Authentication-Info parameters need to be mandated. /Hisham >=20 > All this is even more reason to use qop (which was the intent of 2617 > in the first place). >=20 > --=20 > Scott Lawrence =20 > Pingtel Corp. =20 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 10:34:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05295 for ; Tue, 17 Feb 2004 10:34:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Ed-0000ed-QV for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 10:34:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFY7O8002515 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 10:34:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7EY-0000ct-9U; Tue, 17 Feb 2004 10:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Dt-0000YQ-30 for sip@optimus.ietf.org; Tue, 17 Feb 2004 10:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05003 for ; Tue, 17 Feb 2004 10:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7Dp-0000mw-00 for sip@ietf.org; Tue, 17 Feb 2004 10:33:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7Cz-0000j9-00 for sip@ietf.org; Tue, 17 Feb 2004 10:32:26 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1At7Cd-0000eM-00 for sip@ietf.org; Tue, 17 Feb 2004 10:32:03 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 17 Feb 2004 07:32:01 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1HFVU1m004902; Tue, 17 Feb 2004 07:31:30 -0800 (PST) Received: from [192.168.1.101] (sjc-vpn4-345.cisco.com [10.21.81.89]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMK28379; Tue, 17 Feb 2004 07:31:29 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 17 Feb 2004 07:31:28 -0800 Subject: Re: [Sip] SIP instance identifiers From: Cullen Jennings To: Brian Stucker , Jonathan Rosenberg , Message-ID: In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B5975304AB8D9D@zrc2c012.us.nortel.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3159847888_1111971" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3159847888_1111971 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I can imagine cases where we might want to be able to route by the instance ID. I think the +sip.instance approach is a better than the general contact header I proposed. It provides more options for routing and has no disadvantages. Cullen On 2/16/04 7:57 AM, Jonathan Rosenberg wrote: > Then, the question is whether to use a regular Contact header field > parameter as Cullen has done, or a callee cap parameter as I have done? > The callee cap approach allows for caller preferences to be applied to > routing to a specific instance. Now, a good question is whether such a > thing is needed or even a good idea, if we have GRUU as the ideal way to > route to a UA instance. I can go either way, but welcome thoughts on the > topic. --B_3159847888_1111971 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Sip] SIP instance identifiers
I can imagine cases where we might want to be able to route by the instance= ID. I think the +sip.instance approach is a better than the general contact= header I proposed. It provides more options for routing and has no disadvan= tages.

Cullen

On 2/16/04 7:57 AM, Jonathan Rosenberg wrote:

Then, the question is whether to use a regular Contact header field
parameter as Cullen has done, or a callee cap parameter as I have done? The callee cap approach allows for caller preferences to be applied to
routing to a specific instance. Now, a good question is whether such a
thing is needed or even a good idea, if we have GRUU as the ideal way to route to a UA instance. I can go either way, but welcome thoughts on the topic.

--B_3159847888_1111971-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 13:15:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23445 for ; Tue, 17 Feb 2004 13:15:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9kb-0003Y9-Rw for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 13:15:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIFHI6013581 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 13:15:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9kO-0003VX-6d; Tue, 17 Feb 2004 13:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9jc-0003Uc-51 for sip@optimus.ietf.org; Tue, 17 Feb 2004 13:14:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23303 for ; Tue, 17 Feb 2004 13:14:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9ja-00066D-00 for sip@ietf.org; Tue, 17 Feb 2004 13:14:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9ia-0005zw-00 for sip@ietf.org; Tue, 17 Feb 2004 13:13:12 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1At9hh-0005si-00 for sip@ietf.org; Tue, 17 Feb 2004 13:12:18 -0500 Received: from softarmor.com (bdsl.66.12.12.239.gte.net [66.12.12.239]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1HIDasb005894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2004 12:13:36 -0600 Message-ID: <40325949.10908@softarmor.com> Date: Tue, 17 Feb 2004 12:11:21 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Brian Stucker , Jonathan Rosenberg , sip@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Abstraction: SIP instance identifiers requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Based on the discussion of "routing" based on instance identifiers, I think we may be getting involved in triggerwork that may become more complex than is actually required, because we're all reasoning from secondary positions. So I'd like to take a step back and consider how we got here, and what we think we're trying to accomplish. I see four high-level cases around request routing that illustrate different aspects of this discussion. 1) General case: We wish to address a request to an AOR, such that any contact at that AOR might respond. This is basic 2543-type routing behavior. 2) Capability case: We wish to address a request to an AOR, such that any contact capable of satisfying the request in a way that we like might respond. This behavior is brought out in callee-caps and caller-preferences and the accept/supported/required syntax of 3261. 3) Followups to a specific instance: We have previously done something (such as case 1 or 2) such that the operation of interest has resolved to a specific contact instance associated with an AoR, and we wish subsequent operations (for example, a transfer) to reach that same specific contact instance, even if that specific contact instance is hidden behind an indirection layer (firewall, anonymizer, etc.). As I understand it, this is the heart of the GRUU concept. 4) Selection of a specific instance in an initial request: We have a request that we wish to reach one specific instance of a contact associated with an AoR. It has been proposed that we accomplish this by binding some sort of instance tag to the AoR. It has been proposed that we use some sort of URI convention (like the msuri), +based subaddressing, or that we use a header convention for binding the instance tag to the AoR. To my knowledge, we haven't really described the requirement or use case for reaching a specific instance on an initial request, but I can think of several offhand (including diagnostics). It seems evident that there is a huge overlap between the requirements of 3 and 4. Indeed, I think #3 (GRUU) came out of early ideas I had on using a REGISTER-response extension to assign an instance-AoR to a Contact. It would appear that IF each contact for an AoR were to have an associated GRUU, and that knowledge of those GRUU assigments were available to a requestor, that the requester could use the target-specific GRUU to achieve the use cases I currently imagine for #4. What am I missing here? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 13:20:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24150 for ; Tue, 17 Feb 2004 13:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9pM-0004ze-MC for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 13:20:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIKCxM019129 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 13:20:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9pF-0004pK-0K; Tue, 17 Feb 2004 13:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9oY-0004jh-1J for sip@optimus.ietf.org; Tue, 17 Feb 2004 13:19:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23868 for ; Tue, 17 Feb 2004 13:19:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9oW-0006om-00 for sip@ietf.org; Tue, 17 Feb 2004 13:19:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9nY-0006eG-00 for sip@ietf.org; Tue, 17 Feb 2004 13:18:20 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1At9mZ-0006QN-00 for sip@ietf.org; Tue, 17 Feb 2004 13:17:19 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 17 Feb 2004 10:18:10 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1HIGihu002940; Tue, 17 Feb 2004 13:16:44 -0500 (EST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC54565; Tue, 17 Feb 2004 13:16:43 -0500 (EST) Message-ID: <40325A8A.6050509@cisco.com> Date: Tue, 17 Feb 2004 13:16:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org References: <402FF85F.4020202@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-resource-priority-02 - syntax Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning, (Splitting comments by subject.) There are still problems with the ABNF, around the usage of "*" to indicate repetition. As it stands, it accepts: Resource-Priority: f.1,,,-.- Resource-Priority: 9.a f.- but it doesn't accept: Resource-Priority: foo.bar, foo-1.bar-1, foo-1.bar-2 Assuming the intent is to permit more than two values, separation of values by exactly one comma, and namespaces and priorities that can include multiple dashes and alphanums, then I think the following is what you want: Resource-Priority = "Resource-Priority" HCOLON Resource-value *(COMMA Resource-value) ... namespace = *(alphanum / "-") r-priority = *(alphanum / "-") ABNF for Accept-Resource-Priority is similarly flawed. It should be: Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON [Resource-value *(COMMA Resource-value)] Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 13:23:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24443 for ; Tue, 17 Feb 2004 13:23:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9s7-0005Vy-7i for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 13:23:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIN3WV021164 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 13:23:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9s5-0005UF-FA; Tue, 17 Feb 2004 13:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9ra-0005SU-2N for sip@optimus.ietf.org; Tue, 17 Feb 2004 13:22:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24345 for ; Tue, 17 Feb 2004 13:22:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9rY-0007H0-00 for sip@ietf.org; Tue, 17 Feb 2004 13:22:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9qW-00077V-00 for sip@ietf.org; Tue, 17 Feb 2004 13:21:25 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1At9pU-0006sX-00 for sip@ietf.org; Tue, 17 Feb 2004 13:20:20 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2004 10:28:35 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1HIJluA008050; Tue, 17 Feb 2004 10:19:47 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC55007; Tue, 17 Feb 2004 13:19:46 -0500 (EST) Message-ID: <40325B42.8000608@cisco.com> Date: Tue, 17 Feb 2004 13:19:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 - OPTIONS References: <402FF85F.4020202@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning, OPTIONS handling: there is good explanation of options processing in a UAS, but it is very UAS specific. There isn't any discussion of options processing in proxies that support this extension. It is possible to get a proxy to respond to an options request (using Max-Forwards). This might be used in testing, just a strict mode might. I think what a proxy should return is pretty much the same as what a UAS returns. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 13:41:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25815 for ; Tue, 17 Feb 2004 13:41:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA9p-0007KB-K5 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 13:41:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIfL2p028090 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 13:41:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA9c-0007EI-Mb; Tue, 17 Feb 2004 13:41:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA9R-0007Am-49 for sip@optimus.ietf.org; Tue, 17 Feb 2004 13:40:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25745 for ; Tue, 17 Feb 2004 13:40:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtA9P-0001JF-00 for sip@ietf.org; Tue, 17 Feb 2004 13:40:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtA8I-00017O-00 for sip@ietf.org; Tue, 17 Feb 2004 13:39:48 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AtA6r-0000oH-00 for sip@ietf.org; Tue, 17 Feb 2004 13:38:17 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1HIbRN14978; Tue, 17 Feb 2004 10:37:28 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV86KS>; Tue, 17 Feb 2004 12:37:27 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304B2164F@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Dean Willis , Cullen Jennings Cc: Jonathan Rosenberg , sip@ietf.org Date: Tue, 17 Feb 2004 12:37:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F585.14010514" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] RE: Abstraction: SIP instance identifiers requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F585.14010514 Content-Type: text/plain; charset="iso-8859-1" I think that your list is missing the opportunity to define this instance ID in such a way that it can be used to identify a particular endpoint for other operations beyond simply routing. The reuse potential seems very good if we don't lock the instance identifier down to simply routing operations, and instead open it up for other general-purpose operations. That is at the heart of my draft. Don't limit yourself to one application when with a small amount of work we can use this to solve other problems both current and future. Likewise, don't exclude routing operations from making use of the instance identifier either. Are you concerned that opening this up to having the instance identifier transported (in addition to the registered contact) outside of the registered contact is really going to be that complex? Regards, Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, February 17, 2004 12:11 PM > To: Cullen Jennings > Cc: Stucker, Brian [NGC:B617:EXCH]; Jonathan Rosenberg; sip@ietf.org > Subject: Abstraction: SIP instance identifiers requirements > > > > Based on the discussion of "routing" based on instance identifiers, I > think we may be getting involved in triggerwork that may become more > complex than is actually required, because we're all reasoning from > secondary positions. So I'd like to take a step back and > consider how we > got here, and what we think we're trying to accomplish. > > I see four high-level cases around request routing that illustrate > different aspects of this discussion. > > 1) General case: We wish to address a request to an AOR, such > that any > contact at that AOR might respond. This is basic 2543-type > routing behavior. > > 2) Capability case: We wish to address a request to an AOR, such that > any contact capable of satisfying the request in a way that we like > might respond. This behavior is brought out in callee-caps and > caller-preferences and the accept/supported/required syntax of 3261. > > 3) Followups to a specific instance: We have previously done > something > (such as case 1 or 2) such that the operation of interest has > resolved > to a specific contact instance associated with an AoR, and we wish > subsequent operations (for example, a transfer) to reach that same > specific contact instance, even if that specific contact instance is > hidden behind an indirection layer (firewall, anonymizer, etc.). As I > understand it, this is the heart of the GRUU concept. > > 4) Selection of a specific instance in an initial request: We have a > request that we wish to reach one specific instance of a contact > associated with an AoR. It has been proposed that we > accomplish this by > binding some sort of instance tag to the AoR. It has been > proposed that > we use some sort of URI convention (like the msuri), +based > subaddressing, or that we use a header convention for binding the > instance tag to the AoR. To my knowledge, we haven't really described > the requirement or use case for reaching a specific instance on an > initial request, but I can think of several offhand > (including diagnostics). > > It seems evident that there is a huge overlap between the > requirements > of 3 and 4. Indeed, I think #3 (GRUU) came out of early ideas > I had on > using a REGISTER-response extension to assign an instance-AoR to a > Contact. It would appear that IF each contact for an AoR were > to have an > associated GRUU, and that knowledge of those GRUU assigments were > available to a requestor, that the requester could use the > target-specific GRUU to achieve the use cases I currently > imagine for #4. > > > What am I missing here? > > -- > Dean > ------_=_NextPart_001_01C3F585.14010514 Content-Type: text/html; charset="iso-8859-1" RE: Abstraction: SIP instance identifiers requirements

I think that your list is missing the opportunity to define this instance
ID in such a way that it can be used to identify a particular endpoint
for other operations beyond simply routing. The reuse potential seems
very good if we don't lock the instance identifier down to simply
routing operations, and instead open it up for other general-purpose
operations.

That is at the heart of my draft. Don't limit yourself to one application
when with a small amount of work we can use this to solve other problems
both current and future. Likewise, don't exclude routing operations from
making use of the instance identifier either.

Are you concerned that opening this up to having the instance identifier
transported (in addition to the registered contact) outside of the
registered contact is really going to be that complex?

Regards,

Brian



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Tuesday, February 17, 2004 12:11 PM
> To: Cullen Jennings
> Cc: Stucker, Brian [NGC:B617:EXCH]; Jonathan Rosenberg; sip@ietf.org
> Subject: Abstraction: SIP instance identifiers requirements
>
>
>
> Based on the discussion of "routing" based on instance identifiers, I
> think we may be getting involved in triggerwork that may become more
> complex than is actually required, because we're all reasoning from
> secondary positions. So I'd like to take a step back and
> consider how we
> got here, and what we think we're trying to accomplish.
>
> I see four high-level cases around request routing that illustrate
> different aspects of this discussion.
>
> 1) General case: We wish to address a request to an AOR, such
> that any
> contact at that AOR might respond. This is basic 2543-type
> routing behavior.
>
> 2) Capability case: We wish to address a request to an AOR, such that
> any contact capable of satisfying the request in a way that we like
> might respond. This behavior is brought out in callee-caps and
> caller-preferences and the accept/supported/required syntax of 3261.
>
> 3) Followups to a specific instance: We have previously done
> something
> (such as case 1 or 2) such that the operation of interest has
> resolved
> to a specific contact instance associated with an AoR, and we wish
> subsequent operations (for example, a transfer) to reach that same
> specific contact instance, even if that specific contact instance is
> hidden behind an indirection layer (firewall, anonymizer, etc.). As I
> understand it, this is the heart of the GRUU concept.
>
> 4) Selection of a specific instance in an initial request: We have a
> request that we wish to reach one specific instance of a contact
> associated with an AoR. It has been proposed that we
> accomplish this by
> binding some sort of instance tag to the AoR. It has been
> proposed that
> we use some sort of URI convention (like the msuri), +based
> subaddressing, or that we use a header convention for binding the
> instance tag to the AoR. To my knowledge, we haven't really described
> the requirement or use case for reaching a specific instance on an
> initial request, but I can think of several offhand
> (including diagnostics).
>
> It seems evident that there is a huge overlap between the
> requirements
> of 3 and 4. Indeed, I think #3 (GRUU) came out of early ideas
> I had on
> using a REGISTER-response extension to assign an instance-AoR to a
> Contact. It would appear that IF each contact for an AoR were
> to have an
> associated GRUU, and that knowledge of those GRUU assigments were
> available to a requestor, that the requester could use the
> target-specific GRUU to achieve the use cases I currently
> imagine for #4.
>
>
> What am I missing here?
>
> --
> Dean
>

------_=_NextPart_001_01C3F585.14010514-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 14:20:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28182 for ; Tue, 17 Feb 2004 14:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAlU-0002xd-8R for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 14:20:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJKGTi011319 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 14:20:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAlK-0002u1-06; Tue, 17 Feb 2004 14:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAkf-0002s4-6K for sip@optimus.ietf.org; Tue, 17 Feb 2004 14:19:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28069 for ; Tue, 17 Feb 2004 14:19:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAkc-0004I7-00 for sip@ietf.org; Tue, 17 Feb 2004 14:19:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAjk-0004E8-00 for sip@ietf.org; Tue, 17 Feb 2004 14:18:28 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AtAjH-00049l-00 for sip@ietf.org; Tue, 17 Feb 2004 14:17:59 -0500 Received: from softarmor.com (bdsl.66.12.12.239.gte.net [66.12.12.239]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1HJIpsb006240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2004 13:18:51 -0600 Message-ID: <40326894.7010809@softarmor.com> Date: Tue, 17 Feb 2004 13:16:36 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Stucker CC: Cullen Jennings , Jonathan Rosenberg , sip@ietf.org References: <161AA64DA85DFC4BA4D2EB5629B5975304B2164F@zrc2c012.us.nortel.com> In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B5975304B2164F@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Abstraction: SIP instance identifiers requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian Stucker wrote: > I think that your list is missing the opportunity to define this instance > ID in such a way that it can be used to identify a particular endpoint > for other operations beyond simply routing. The reuse potential seems > very good if we don't lock the instance identifier down to simply > routing operations, and instead open it up for other general-purpose > operations. So you see a requirement to uniquely identify a specific SIP endpoint OUTSIDE of the domain of SIP routing, such that this identification can support further applications? Use cases here might include: 1) billing -- "Alice called Bob from phone ID000001 through gateway ID3344555 on Tuesday, March 1, 2011" 2) Debugging -- "This request was responded to by node IDYIYIOHIHIUH, which is a Barfia model 9995 phone running Finux 21.05A and the Vocal user agent release 89.6" This begs the question of identity namespace. > Are you concerned that opening this up to having the instance identifier > transported (in addition to the registered contact) outside of the > registered contact is really going to be that complex? No, I'm concerned that solving the general device-identity-representation problem, including such aspects as nonrepudiability, may be outside the scope of SIP/SIPPING. At what point does this become HIP (Host Identity Payload)? One way to bound this to a manageable scope is to consider the "identity" being represented as simply informational and not-to-be-relied upon, except to the extent supported by basic SIP security constructs. Like "To:" and "From:" . . . Another approach is to limit the expression of identity herein to that subset of identify which is expressly describable using SIP, which makes it analogous to the SIP routing mechanisms underlying the concepts of AoR, asserted identity, and verified/vouchsafed identity in the various documents that touch on those concepts. In other words, we restrict ourselves to the namspace of SIP AoRs. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 15:48:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04498 for ; Tue, 17 Feb 2004 15:48:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC8j-0005XI-VK for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 15:48:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKmLmq021218 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 15:48:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC8P-0005L1-7U; Tue, 17 Feb 2004 15:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC7o-0005KK-Sz for sip@optimus.ietf.org; Tue, 17 Feb 2004 15:47:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04423 for ; Tue, 17 Feb 2004 15:47:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtC7n-0003bF-00 for sip@ietf.org; Tue, 17 Feb 2004 15:47:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtC6x-0003XS-00 for sip@ietf.org; Tue, 17 Feb 2004 15:46:32 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtC6C-0003Pp-00 for sip@ietf.org; Tue, 17 Feb 2004 15:45:44 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2004 12:54:01 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1HKjC1m028641; Tue, 17 Feb 2004 12:45:12 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA07123; Tue, 17 Feb 2004 12:45:11 -0800 (PST) Message-Id: <4.3.2.7.2.20040217143918.04d24630@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Feb 2004 14:40:00 -0600 To: Paul Kyzivat , Henning Schulzrinne From: "James M. Polk" Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 - OPTIONS Cc: sip@ietf.org In-Reply-To: <40325B42.8000608@cisco.com> References: <402FF85F.4020202@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 01:19 PM 2/17/2004 -0500, Paul Kyzivat wrote: >Henning, > >OPTIONS handling: there is good explanation of options processing in a >UAS, but it is very UAS specific. There isn't any discussion of options >processing in proxies that support this extension. It is possible to get >a proxy to respond to an options request (using Max-Forwards). This >might be used in testing, just a strict mode might. > >I think what a proxy should return is pretty much the same as what a UAS >returns. I agree with this point > Paul > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 17:31:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13014 for ; Tue, 17 Feb 2004 17:31:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDkK-0007LQ-3y for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 17:31:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HMVGoB028232 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 17:31:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDk6-0007HN-T9; Tue, 17 Feb 2004 17:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDjh-0007FO-Hm for sip@optimus.ietf.org; Tue, 17 Feb 2004 17:30:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12934 for ; Tue, 17 Feb 2004 17:30:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDjf-0006ZP-00 for sip@ietf.org; Tue, 17 Feb 2004 17:30:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDim-0006Tw-00 for sip@ietf.org; Tue, 17 Feb 2004 17:29:41 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtDiI-0006Nu-00 for sip@ietf.org; Tue, 17 Feb 2004 17:29:10 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2004 14:38:08 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1HMSZuC008023; Tue, 17 Feb 2004 14:28:37 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC81489; Tue, 17 Feb 2004 17:28:34 -0500 (EST) Message-ID: <40329592.1080001@cisco.com> Date: Tue, 17 Feb 2004 17:28:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] SIP instance identifiers References: <40302143.9080000@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan, I like using a callee-cap feature tag in a registration. OTOH, I can see validity in Brian's desire to have it in a header of its own, potentially in any message. I don't see those usages as conflicting. The only potential conflict would be in REGISTER, but that isn't a real conflict - a Guid header would describe the entity sending the REGISTER message, while the +sip.instance tag on a contact would describe the endpoint being registered. Often they would be the same, but not necessarily. Regarding the form of guids, I don't think any single scheme works in all cases. My preference is to: - represent the instance id as a URI - make it the responsibility of the endpoint to select a URI that is unique - Recommend that a URN be used. - Define a couple of new URN namespaces that are especially suitable for this purpose. (I have in mind urn:mac:xxx for mac addresses, and possibly urn:random:xxx for random numbers in some large range.) A couple of other comments: Section 7.1 says: The combination of a UA instance ID and an AOR is referred to as an instance ID/AOR pair. There is a one-to-one mapping between such a pair and a GRUU; ... And figure 2 shows the corresponding 1:1 relationship. But it isn't necessarily 1:1. It should be 1:0..1 because it is possible to have an instance ID/AOR Pair that doesn't have a GRUU. (Instance IDs are valuable in their own right.) This 1:0..1 relationship imposes another error condition on registrars. If an attempt is made to register a contact with an instance id in use by some other contact of the same AOR, the registrar will have to refuse it. This needs to be spelled out somewhere, and a suitable error identified. (I don't know if any of the existing responses works for this. At the least, a new Reason code is likely to be needed.) Paul Jonathan Rosenberg wrote: > Folks, > > We have three drafts this round that all propose a way to define an > instance identifier for a UA: > > > http://www.jdrosen.net/papers/draft-ietf-sip-gruu-01.txt > http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt > > http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt > > all three are similar. Mine uses a contact header field parameter, and > uses the callee capabilities framework to enable caller preferences > routing based on instance iDs. Cullen also uses a contact parameter, but > not within the callee caps framework. Brian defines a header field. > > I think we generally understand the requirement here, though it would > probably be good to obtain use cases to be sure. The design choice is > where to include this parameter, and this represents the difference > between the three approaches. > > I tend to prefer a Contact URI parameter over a header. My main reason > for that is REGISTER requests. If a register request has multiple > contacts, which contact does the instance identifier apply to? As a > header field, it would be hard to know. If you make it a contact header > field parameter, its no problem. Those header field parameters could > also then be used in the Contact in INVITE/200 SUB/NOT, etc. > > Then, the question is whether to use a regular Contact header field > parameter as Cullen has done, or a callee cap parameter as I have done? > The callee cap approach allows for caller preferences to be applied to > routing to a specific instance. Now, a good question is whether such a > thing is needed or even a good idea, if we have GRUU as the ideal way to > route to a UA instance. I can go either way, but welcome thoughts on the > topic. > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 18:16:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15756 for ; Tue, 17 Feb 2004 18:16:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtERk-0007iW-Mz for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 18:16:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HNG89O029633 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 18:16:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtERf-0007gA-CU; Tue, 17 Feb 2004 18:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtER0-0007SB-TP for sip@optimus.ietf.org; Tue, 17 Feb 2004 18:15:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15288 for ; Tue, 17 Feb 2004 18:15:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEQx-0001UU-00 for sip@ietf.org; Tue, 17 Feb 2004 18:15:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEQ0-0001O5-00 for sip@ietf.org; Tue, 17 Feb 2004 18:14:21 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AtEPG-0001LH-00 for sip@ietf.org; Tue, 17 Feb 2004 18:13:34 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1HNCo5d019170; Tue, 17 Feb 2004 18:12:50 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1HNCoH17676; Tue, 17 Feb 2004 18:12:50 -0500 Message-ID: <40329FF1.4090006@cs.columbia.edu> Date: Tue, 17 Feb 2004 18:12:49 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 - OPTIONS References: <402FF85F.4020202@cs.columbia.edu> <40325B42.8000608@cisco.com> In-Reply-To: <40325B42.8000608@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree in general, but the details are a bit tricky. If I address an OPTIONS request to pkyzivat@cisco.com, should the cisco.com proxy respond with its Accept-R-P version or should it let it go through and have your end system speak for itself? The two lists may obviously not be the same. Paul Kyzivat wrote: > Henning, > > OPTIONS handling: there is good explanation of options processing in a > UAS, but it is very UAS specific. There isn't any discussion of options > processing in proxies that support this extension. It is possible to get > a proxy to respond to an options request (using Max-Forwards). This > might be used in testing, just a strict mode might. > > I think what a proxy should return is pretty much the same as what a UAS > returns. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 18:18:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15981 for ; Tue, 17 Feb 2004 18:18:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtETb-0000VQ-PP for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 18:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HNI31n001928 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 18:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtETZ-0000Sc-ID; Tue, 17 Feb 2004 18:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtET4-0008T6-TW for sip@optimus.ietf.org; Tue, 17 Feb 2004 18:17:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15860 for ; Tue, 17 Feb 2004 18:17:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtET1-0001gN-00 for sip@ietf.org; Tue, 17 Feb 2004 18:17:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtESF-0001ct-00 for sip@ietf.org; Tue, 17 Feb 2004 18:16:40 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AtERh-0001Z2-00 for sip@ietf.org; Tue, 17 Feb 2004 18:16:05 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1HNG35d019501; Tue, 17 Feb 2004 18:16:03 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1HNG2H18151; Tue, 17 Feb 2004 18:16:02 -0500 Message-ID: <4032A0B2.50504@cs.columbia.edu> Date: Tue, 17 Feb 2004 18:16:02 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: sip@ietf.org References: <402FF85F.4020202@cs.columbia.edu> <40325ADF.30508@cisco.com> In-Reply-To: <40325ADF.30508@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-resource-priority-02 - Table 2 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > - Now that Resource-Priority is optional in all requests, shouldn't > Accept-Resource-Priority be permitted in 420 responses to all the same > messages? Agreed; except for ACK... > > - Shouldn't the R-P be optional in responses to any request where it was > permitted? Same quick cut-and-paste error; yes. > > - If A-R-P is mandatory in 417 responses to SUB, NOT, and MSG, shouldn't > it also be mandatory (rather than optional) in 417 response to INVITE? > And by logic just above, shouldn't it be mandatory in responses to any > message where R-P is optional? > > - So I think the table probably ought to look like: > > Header field where proxy INV ACK CAN BYE REG OPT PRA > ---------------------------------------------------------------- > Resource-Priority R amd o o o o o o o > Resource-Priority 200 - o o o o o o o > Accept-Resource-Priority 200 - o o o o o o o > Accept-Resource-Priority 417 - m m m m m m m > Accept-Resource-Priority 420 - o o o o o o o > > Header field where proxy SUB NOT UPD MSG REF INF PUB > ---------------------------------------------------------------- > Resource-Priority R amd o o o o o o o > Resource-Priority 200 - o o o o o o o > Accept-Resource-Priority 200 - o o o o o o o > Accept-Resource-Priority 417 - m m m m m m m > Accept-Resource-Priority 420 - o o o o o o o Yup, minus the responses for ACK. > > In section 4.1, why do you single out INVITE, MESSAGE, UPDATE, SUBSCRIBE > and NOTIFY, but omit ACK and PRACK? If INVITE is important, then ACK and > PRACK must be important too. This probably isn't an issue in a UAS, > because it considers those to be part of the INVITE. But it could make a > difference in a proxy. > > Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 18:43:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17287 for ; Tue, 17 Feb 2004 18:43:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEry-0003el-Bg for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 18:43:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HNhEM3013991 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 18:43:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtErm-0003Yd-He; Tue, 17 Feb 2004 18:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtErC-0003WI-VR for sip@optimus.ietf.org; Tue, 17 Feb 2004 18:42:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17204 for ; Tue, 17 Feb 2004 18:42:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEr9-0003Ni-00 for sip@ietf.org; Tue, 17 Feb 2004 18:42:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEqG-0003Ju-00 for sip@ietf.org; Tue, 17 Feb 2004 18:41:28 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtEpQ-0003Ca-00 for sip@ietf.org; Tue, 17 Feb 2004 18:40:36 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2004 15:49:34 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1HNe2uA028540; Tue, 17 Feb 2004 15:40:03 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC86670; Tue, 17 Feb 2004 18:40:01 -0500 (EST) Message-ID: <4032A651.3090407@cisco.com> Date: Tue, 17 Feb 2004 18:40:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 - OPTIONS References: <402FF85F.4020202@cs.columbia.edu> <40325B42.8000608@cisco.com> <40329FF1.4090006@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I thought this was clear in the definition of OPTIONS. If Max-Forwards is zero when it gets to the proxy, then the proxy is supposed to generate its own response to the OPTIONS. Otherwise it is supposed to proxy the request on. Paul Henning Schulzrinne wrote: > I agree in general, but the details are a bit tricky. If I address an > OPTIONS request to pkyzivat@cisco.com, should the cisco.com proxy > respond with its Accept-R-P version or should it let it go through and > have your end system speak for itself? The two lists may obviously not > be the same. > > Paul Kyzivat wrote: > >> Henning, >> >> OPTIONS handling: there is good explanation of options processing in a >> UAS, but it is very UAS specific. There isn't any discussion of options >> processing in proxies that support this extension. It is possible to get >> a proxy to respond to an options request (using Max-Forwards). This >> might be used in testing, just a strict mode might. >> >> I think what a proxy should return is pretty much the same as what a >> UAS returns. >> >> Paul >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 18:45:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17379 for ; Tue, 17 Feb 2004 18:45:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEtn-0004AB-3O for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 18:45:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HNj70o015955 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 18:45:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEtl-00046s-6g; Tue, 17 Feb 2004 18:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEtB-0003pw-B7 for sip@optimus.ietf.org; Tue, 17 Feb 2004 18:44:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17312 for ; Tue, 17 Feb 2004 18:44:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEt8-0003XD-00 for sip@ietf.org; Tue, 17 Feb 2004 18:44:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEsK-0003Tm-00 for sip@ietf.org; Tue, 17 Feb 2004 18:43:37 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtErU-0003Lf-00 for sip@ietf.org; Tue, 17 Feb 2004 18:42:44 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2004 15:51:02 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1HNgC4U009848; Tue, 17 Feb 2004 15:42:12 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC86830; Tue, 17 Feb 2004 18:42:10 -0500 (EST) Message-ID: <4032A6D3.5060308@cisco.com> Date: Tue, 17 Feb 2004 18:42:11 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org References: <402FF85F.4020202@cs.columbia.edu> <40325ADF.30508@cisco.com> <4032A0B2.50504@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-resource-priority-02 - Table 2 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > >> - Now that Resource-Priority is optional in all requests, shouldn't >> Accept-Resource-Priority be permitted in 420 responses to all the same >> messages? > > > Agreed; except for ACK... Duh! Sorry about that one. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 17 23:34:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28062 for ; Tue, 17 Feb 2004 23:34:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJPW-0000yq-OK for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 23:34:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I4YA1q003767 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 23:34:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJPN-0000xc-R4; Tue, 17 Feb 2004 23:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJOy-0000t1-Nm for sip@optimus.ietf.org; Tue, 17 Feb 2004 23:33:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28036 for ; Tue, 17 Feb 2004 23:33:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtJOw-0000ej-00 for sip@ietf.org; Tue, 17 Feb 2004 23:33:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtJO3-0000cJ-00 for sip@ietf.org; Tue, 17 Feb 2004 23:32:40 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AtJNo-0000ZD-00 for sip@ietf.org; Tue, 17 Feb 2004 23:32:24 -0500 Received: from dynamicsoft.com ([63.113.46.6]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1I4VuNr005955; Tue, 17 Feb 2004 23:31:56 -0500 (EST) Message-ID: <4032EAB2.30000@dynamicsoft.com> Date: Tue, 17 Feb 2004 23:31:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: sip@ietf.org Subject: Re: [Sip] SIP instance identifiers References: <40302143.9080000@dynamicsoft.com> <40329592.1080001@cisco.com> In-Reply-To: <40329592.1080001@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Jonathan, > > I like using a callee-cap feature tag in a registration. OTOH, I can see > validity in Brian's desire to have it in a header of its own, > potentially in any message. I don't see those usages as conflicting. No, but it represents additional work. > > The only potential conflict would be in REGISTER, but that isn't a real > conflict - a Guid header would describe the entity sending the REGISTER > message, while the +sip.instance tag on a contact would describe the > endpoint being registered. Often they would be the same, but not > necessarily. This makes sense. > > Regarding the form of guids, I don't think any single scheme works in > all cases. My preference is to: > > - represent the instance id as a URI > > - make it the responsibility of the endpoint to select a URI > that is unique > > - Recommend that a URN be used. > > - Define a couple of new URN namespaces that are especially > suitable for this purpose. (I have in mind urn:mac:xxx for > mac addresses, and possibly urn:random:xxx for random numbers > in some large range.) This is a well trod area, and I think it would behoove us to look at work in other groups. Dean has mentioned HIP as one obvious candidate; generally speaking this exact issue - of endpoint identifiers that work better than IP address, is the subject of much other work at this moment, including MAST. I'm not familiar enough with it to know if its relevant... its on my reading list for this ietf. > > A couple of other comments: > > Section 7.1 says: > > The combination of a UA instance ID and an AOR is referred to as an > instance ID/AOR pair. There is a one-to-one mapping between such a > pair and a GRUU; ... > > And figure 2 shows the corresponding 1:1 relationship. But it isn't > necessarily 1:1. It should be 1:0..1 because it is possible to have an > instance ID/AOR Pair that doesn't have a GRUU. (Instance IDs are > valuable in their own right.) OK, I'll update the diagram. > > This 1:0..1 relationship imposes another error condition on registrars. > If an attempt is made to register a contact with an instance id in use > by some other contact of the same AOR, the registrar will have to refuse > it. Well, thats one option. This needs to be spelled out somewhere, and a suitable error > identified. (I don't know if any of the existing responses works for > this. At the least, a new Reason code is likely to be needed.) Here is the use case for this. The use case is when a UA crashes, recovers, obtains a new IP, and re-registers. In this case, several things could possibly happen: 1. The registrar accepts the second registration, as per normal registration procedures. An INVITE to the gruu bound to that id/aor pair gets translated into BOTH contacts, causing the request to fork. There is never any response from the old IP. Within one refresh interval, the old contact is removed and all is well. 2. The registrar accepts the second registration, and automatically deletes the old one. I believe Brian proposed this behavior. 3. The registrar returns an error. The client fetches the current list of contacts, finds the old one listed, and unregisters it. Approach 1 is problematic, as it will introduce herfp; any non-2xx from the new contact will wait for the 2nd branch to timeout. Its not clear to me whether 2 or 3 is more right. It depends a lot on who owns the policy for how to resolve the conflict - is it the server or the client? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 00:01:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28990 for ; Wed, 18 Feb 2004 00:01:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJpc-0002xE-9r for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 00:01:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I5185O011339 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 00:01:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJpW-0002vR-F7; Wed, 18 Feb 2004 00:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJp2-0002tU-3v for sip@optimus.ietf.org; Wed, 18 Feb 2004 00:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28949 for ; Wed, 18 Feb 2004 00:00:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtJoz-0002Bs-00 for sip@ietf.org; Wed, 18 Feb 2004 00:00:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtJo7-00028g-00 for sip@ietf.org; Tue, 17 Feb 2004 23:59:36 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AtJnD-00020x-00 for sip@ietf.org; Tue, 17 Feb 2004 23:58:39 -0500 Received: from dynamicsoft.com ([63.113.46.6]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1I4wBNr005972; Tue, 17 Feb 2004 23:58:11 -0500 (EST) Message-ID: <4032F0D9.204@dynamicsoft.com> Date: Tue, 17 Feb 2004 23:58:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: Cullen Jennings , Brian Stucker , sip@ietf.org References: <40325949.10908@softarmor.com> In-Reply-To: <40325949.10908@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Abstraction: SIP instance identifiers requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Dean Willis wrote: > > Based on the discussion of "routing" based on instance identifiers, I > think we may be getting involved in triggerwork that may become more > complex than is actually required, because we're all reasoning from > secondary positions. So I'd like to take a step back and consider how > we got here, and what we think we're trying to accomplish. > > I see four high-level cases around request routing that illustrate > different aspects of this discussion. > > 1) General case: We wish to address a request to an AOR, such that > any contact at that AOR might respond. This is basic 2543-type > routing behavior. Well, I prefer 3261-style, but yes. > > 2) Capability case: We wish to address a request to an AOR, such that > any contact capable of satisfying the request in a way that we like > might respond. This behavior is brought out in callee-caps and > caller-preferences and the accept/supported/required syntax of 3261. Right. > > 3) Followups to a specific instance: We have previously done > something (such as case 1 or 2) such that the operation of interest > has resolved to a specific contact instance associated with an AoR, > and we wish subsequent operations (for example, a transfer) to reach > that same specific contact instance, even if that specific contact > instance is hidden behind an indirection layer (firewall, anonymizer, > etc.). As I understand it, this is the heart of the GRUU concept. Yes. > > 4) Selection of a specific instance in an initial request: We have a > request that we wish to reach one specific instance of a contact > associated with an AoR. My proposal of using a callee capabilities parameter for instance ID would accomplish that. However, I am not sure that its really useful, to be honest. How would the caller know the instance ID ahead of time? Any kind of mechanism that can transfer the instance ID could transfer the GRUU instead, and a GRUU will be much, much, much better. It has been proposed that we accomplish this by > binding some sort of instance tag to the AoR. It has been proposed > that we use some sort of URI convention (like the msuri), +based > subaddressing, I wasnt proposing that. The +sip.instance is the convention used by callee caps for identifying Contact header parameters that are subject to the specification. > It seems evident that there is a huge overlap between the > requirements of 3 and 4. Yes. > Indeed, I think #3 (GRUU) came out of early ideas I had on using a > REGISTER-response extension to assign an instance-AoR to a Contact. > It would appear that IF each contact for an AoR were to have an > associated GRUU, and that knowledge of those GRUU assigments were > available to a requestor, that the requester could use the > target-specific GRUU to achieve the use cases I currently imagine for > #4. Right, this is exactly what I am saying above as well. Dean later writes, in response to Brian: > So you see a requirement to uniquely identify a specific SIP endpoint > OUTSIDE of the domain of SIP routing, such that this identification > can support further applications? > > Use cases here might include: > > 1) billing -- "Alice called Bob from phone ID000001 through gateway > ID3344555 on Tuesday, March 1, 2011" I do not understand the need for a globally unique instance ID to support billing, and would be very scared of fraud issues. > > 2) Debugging -- "This request was responded to by node IDYIYIOHIHIUH, > which is a Barfia model 9995 phone running Finux 21.05A and the > Vocal user agent release 89.6" I'm not sure I understand the specific value gleaned from the instance ID in this case. > Another approach is to limit the expression of identity herein to > that subset of identify which is expressly describable using SIP, > which makes it analogous to the SIP routing mechanisms underlying the > concepts of AoR, asserted identity, and verified/vouchsafed identity > in the various documents that touch on those concepts. In other > words, we restrict ourselves to the namspace of SIP AoRs. Well said. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 02:31:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29424 for ; Wed, 18 Feb 2004 02:31:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtMAC-0002h8-En for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 02:30:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I7UWWG010345 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 02:30:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtM9l-0002cF-OZ; Wed, 18 Feb 2004 02:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtM9K-0002V9-V9 for sip@optimus.ietf.org; Wed, 18 Feb 2004 02:29:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28373 for ; Wed, 18 Feb 2004 02:29:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtM9H-0002g9-00 for sip@ietf.org; Wed, 18 Feb 2004 02:29:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtM8J-0002dp-00 for sip@ietf.org; Wed, 18 Feb 2004 02:28:37 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1AtM7S-0002Zo-00 for sip@ietf.org; Wed, 18 Feb 2004 02:27:42 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1I7Qqw02217; Wed, 18 Feb 2004 01:26:52 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV9151>; Wed, 18 Feb 2004 01:26:52 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304B81C63@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , Paul Kyzivat Cc: sip@ietf.org Subject: RE: [Sip] SIP instance identifiers Date: Wed, 18 Feb 2004 01:26:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F5F0.941C6692" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F5F0.941C6692 Content-Type: text/plain; charset="iso-8859-1" Inline... > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, February 17, 2004 10:32 PM > To: Paul Kyzivat > Cc: sip@ietf.org > Subject: Re: [Sip] SIP instance identifiers > > > > > Paul Kyzivat wrote: > > > Jonathan, > > > > I like using a callee-cap feature tag in a registration. > OTOH, I can see > > validity in Brian's desire to have it in a header of its own, > > potentially in any message. I don't see those usages as conflicting. > > No, but it represents additional work. A very small amount of additional work, and I believe the majority of it has already been handled in my draft (specifically defining the header). We've agreed that there's a need for a mechanism like this for PUBLISH. There's an obvious hole in generating meaningful instance identifiers for PIDF documents and the such. Other state aggregation mechanisms in the future are easily envisionable that would need to know which unique client sent a request, where it would be useful to have that information transported in a request in a handy mechanism. Why not take care of both problems in one shot, define the (minimal) interactions and then follow things up in the various drafts like PUBLISH and any others that see a need for this where they define the appropriate policy for using the instance identifier they've been given ala RFC-3265. Define the basic mechanism (in that case SUBSCRIBE/NOTIFY) and let others define the usages. > > > > > The only potential conflict would be in REGISTER, but that > isn't a real > > conflict - a Guid header would describe the entity sending > the REGISTER > > message, while the +sip.instance tag on a contact would > describe the > > endpoint being registered. Often they would be the same, but not > > necessarily. > > This makes sense. Agreed. The two mechanisms can easily live together much like an expires header in the registration does along side one in the contact. > > > > > Regarding the form of guids, I don't think any single > scheme works in > > all cases. My preference is to: > > > > - represent the instance id as a URI > > > > - make it the responsibility of the endpoint to select a URI > > that is unique > > > > - Recommend that a URN be used. > > > > - Define a couple of new URN namespaces that are especially > > suitable for this purpose. (I have in mind urn:mac:xxx for > > mac addresses, and possibly urn:random:xxx for random numbers > > in some large range.) > > This is a well trod area, and I think it would behoove us to look at > work in other groups. Dean has mentioned HIP as one obvious > candidate; > generally speaking this exact issue - of endpoint identifiers > that work > better than IP address, is the subject of much other work at this > moment, including MAST. I'm not familiar enough with it to > know if its > relevant... its on my reading list for this ietf. > > This represents additional work as well. =) I think we're limiting ourselves to just MACs and random numbers. Having looked around a bit, I've seen material (I want to say it's from WebDAV but I could be remembering incorrectly) that the MAC address isn't always a good thing to pass around because you can figure out that the UA is running on a particular piece of hardware without otherwise having access to their MAC (because you're on the other side of the world many routers away). That can be used to determine a method of attack because you can inferr what operating systems, etc might be running if you know what kind of hardware that box is plugged into the network with. That said, if you want to use a MAC, fine. Buyer beware. If you want to use a random number, fine. If you want to use the GPS coordinates of the box to some ridiculous level of precision (and that's good enough for your application) fine. I don't see why we necessarily need to put any restrictions on this instance ID to make it a URN or anything else when it really need not be any more complex than a VIA branch. I also don't see a reason why we should expect other nodes in the network to be able to use the instance identifier for anything other than a token (ie. if it's a mac address, and two UA instances do something because it's a MAC address, that's OK, but other's may not take that tact). There's no guarantee others are going to be able to take whatever action might be denoted by the contents of the instance identifier itself, so it becomes entirely proprietary at that point. > > > > A couple of other comments: > > > > Section 7.1 says: > > > > The combination of a UA instance ID and an AOR is > referred to as an > > instance ID/AOR pair. There is a one-to-one mapping > between such a > > pair and a GRUU; ... > > > > And figure 2 shows the corresponding 1:1 relationship. But it isn't > > necessarily 1:1. It should be 1:0..1 because it is possible > to have an > > instance ID/AOR Pair that doesn't have a GRUU. (Instance IDs are > > valuable in their own right.) > > OK, I'll update the diagram. > > > > > This 1:0..1 relationship imposes another error condition on > registrars. > > If an attempt is made to register a contact with an > instance id in use > > by some other contact of the same AOR, the registrar will > have to refuse > > it. > > Well, thats one option. This is why I put some boundaries on the length of the GUID and some basic guidelines, to make this very unlikely to occur for reasonably well behaved implementations. > > This needs to be spelled out somewhere, and a suitable error > > identified. (I don't know if any of the existing responses > works for > > this. At the least, a new Reason code is likely to be needed.) > > Here is the use case for this. The use case is when a UA crashes, > recovers, obtains a new IP, and re-registers. In this case, several > things could possibly happen: > > 1. The registrar accepts the second registration, as per normal > registration procedures. An INVITE to the gruu bound to that > id/aor pair > gets translated into BOTH contacts, causing the request to > fork. There > is never any response from the old IP. Within one refresh > interval, the > old contact is removed and all is well. > > 2. The registrar accepts the second registration, and automatically > deletes the old one. I believe Brian proposed this behavior. > > 3. The registrar returns an error. The client fetches the > current list > of contacts, finds the old one listed, and unregisters it. > > > > Approach 1 is problematic, as it will introduce herfp; any > non-2xx from > the new contact will wait for the 2nd branch to timeout. Its > not clear > to me whether 2 or 3 is more right. It depends a lot on who owns the > policy for how to resolve the conflict - is it the server or > the client? Agree on 1 being bad. IMHO it's the server that owns the policy. If the client is too dumb to remember their previous contact address, then it's probably too stateless to make policy decisions about which contact should be removed too (otherwise it would have simply deregistered that contact in the first place). > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C3F5F0.941C6692 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] SIP instance identifiers

Inline...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, February 17, 2004 10:32 PM
> To: Paul Kyzivat
> Cc: sip@ietf.org
> Subject: Re: [Sip] SIP instance identifiers
>
>
>
>
> Paul Kyzivat wrote:
>
> > Jonathan,
> >
> > I like using a callee-cap feature tag in a registration.
> OTOH, I can see
> > validity in Brian's desire to have it in a header of its own,
> > potentially in any message. I don't see those usages as conflicting.
>
> No, but it represents additional work.

A very small amount of additional work, and I believe the majority of it
has already been handled in my draft (specifically defining the header).
We've agreed that there's a need for a mechanism like this
for PUBLISH. There's an obvious hole in generating meaningful instance
identifiers for PIDF documents and the such. Other state aggregation mechanisms
in the future are easily envisionable that would need to know which unique
client sent a request, where it would be useful to have that information
transported in a request in a handy mechanism.

Why not take care of both problems in one shot, define the (minimal) interactions
and then follow things up in the various drafts like PUBLISH and any others that
see a need for this where they define the appropriate policy for using the
instance identifier they've been given ala RFC-3265. Define the basic mechanism
(in that case SUBSCRIBE/NOTIFY) and let others define the usages.

>
> >
> > The only potential conflict would be in REGISTER, but that
> isn't a real
> > conflict - a Guid header would describe the entity sending
> the REGISTER
> > message, while the +sip.instance tag on a contact would
> describe the
> > endpoint being registered. Often they would be the same, but not
> > necessarily.
>
> This makes sense.

Agreed. The two mechanisms can easily live together much like an
expires header in the registration does along side one in the contact.

>
> >
> > Regarding the form of guids, I don't think any single
> scheme works in
> > all cases. My preference is to:
> >
> > - represent the instance id as a URI
> >
> > - make it the responsibility of the endpoint to select a URI
> >   that is unique
> >
> > - Recommend that a URN be used.
> >
> > - Define a couple of new URN namespaces that are especially
> >   suitable for this purpose. (I have in mind urn:mac:xxx for
> >   mac addresses, and possibly urn:random:xxx for random numbers
> >   in some large range.)
>
> This is a well trod area, and I think it would behoove us to look at
> work in other groups. Dean has mentioned HIP as one obvious
> candidate;
> generally speaking this exact issue - of endpoint identifiers
> that work
> better than IP address, is the subject of much other work at this
> moment, including MAST. I'm not familiar enough with it to
> know if its
> relevant... its on my reading list for this ietf.
>
>

This represents additional work as well. =)

I think we're limiting ourselves to just MACs and random numbers. Having
looked around a bit, I've seen material (I want to say it's from WebDAV
but I could be remembering incorrectly) that the MAC address isn't always
a good thing to pass around because you can figure out that the UA is
running on a particular piece of hardware without otherwise having access
to their MAC (because you're on the other side of the world many routers
away). That can be used to determine a method of attack because you can
inferr what operating systems, etc might be running if you know what kind
of hardware that box is plugged into the network with.

That said, if you want to use a MAC, fine. Buyer beware. If you want to use
a random number, fine. If you want to use the GPS coordinates of the box to
some ridiculous level of precision (and that's good enough for your application)
fine.

I don't see why we necessarily need to put any restrictions on this
instance ID to make it a URN or anything else when it really need not be any
more complex than a VIA branch. I also don't see a reason why we should expect
other nodes in the network to be able to use the instance identifier for anything
other than a token (ie. if it's a mac address, and two UA instances do something
because it's a MAC address, that's OK, but other's may not take that tact). There's
no guarantee others are going to be able to take whatever action might be denoted
by the contents of the instance identifier itself, so it becomes entirely
proprietary at that point.

> >
> > A couple of other comments:
> >
> > Section 7.1 says:
> >
> >    The combination of a UA instance ID and an AOR is
> referred to as an
> >    instance ID/AOR pair. There is a one-to-one mapping
> between such a
> >    pair and a GRUU; ...
> >
> > And figure 2 shows the corresponding 1:1 relationship. But it isn't
> > necessarily 1:1. It should be 1:0..1 because it is possible
> to have an
> > instance ID/AOR Pair that doesn't have a GRUU. (Instance IDs are
> > valuable in their own right.)
>
> OK, I'll update the diagram.
>
> >
> > This 1:0..1 relationship imposes another error condition on
> registrars.
> > If an attempt is made to register a contact with an
> instance id in use
> > by some other contact of the same AOR, the registrar will
> have to refuse
> > it.
>
> Well, thats one option.

This is why I put some boundaries on the length of the GUID and some
basic guidelines, to make this very unlikely to occur for reasonably
well behaved implementations.

>
> This needs to be spelled out somewhere, and a suitable error
> > identified. (I don't know if any of the existing responses
> works for
> > this. At the least, a new Reason code is likely to be needed.)
>
> Here is the use case for this. The use case is when a UA crashes,
> recovers, obtains a new IP, and re-registers. In this case, several
> things could possibly happen:
>
> 1. The registrar accepts the second registration, as per normal
> registration procedures. An INVITE to the gruu bound to that
> id/aor pair
> gets translated into BOTH contacts, causing the request to
> fork. There
> is never any response from the old IP. Within one refresh
> interval, the
> old contact is removed and all is well.
>
> 2. The registrar accepts the second registration, and automatically
> deletes the old one. I believe Brian proposed this behavior.
>
> 3. The registrar returns an error. The client fetches the
> current list
> of contacts, finds the old one listed, and unregisters it.
>
>
>
> Approach 1 is problematic, as it will introduce herfp; any
> non-2xx from
> the new contact will wait for the 2nd branch to timeout. Its
> not clear
> to me whether 2 or 3 is more right. It depends a lot on who owns the
> policy for how to resolve the conflict - is it the server or
> the client?

Agree on 1 being bad.

IMHO it's the server that owns the policy. If the client is too dumb to
remember their previous contact address, then it's probably too stateless
to make policy decisions about which contact should be removed too (otherwise
it would have simply deregistered that contact in the first place).

>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

------_=_NextPart_001_01C3F5F0.941C6692-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 02:47:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00966 for ; Wed, 18 Feb 2004 02:47:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtMQN-0005eH-Hh for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 02:47:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I7lFjR021712 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 02:47:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtMQA-0005cZ-FJ; Wed, 18 Feb 2004 02:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtMPv-0005bO-9i for sip@optimus.ietf.org; Wed, 18 Feb 2004 02:46:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00953 for ; Wed, 18 Feb 2004 02:46:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtMPr-0003ds-00 for sip@ietf.org; Wed, 18 Feb 2004 02:46:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtMOx-0003aq-00 for sip@ietf.org; Wed, 18 Feb 2004 02:45:48 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AtMO9-0003Sn-00 for sip@ietf.org; Wed, 18 Feb 2004 02:44:57 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1I7i5q04415; Tue, 17 Feb 2004 23:44:06 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV9150>; Wed, 18 Feb 2004 01:44:05 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304B81C68@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , Dean Willis Cc: Cullen Jennings , sip@ietf.org Date: Wed, 18 Feb 2004 01:44:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F5F2.FB90EF3A" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] RE: Abstraction: SIP instance identifiers requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F5F2.FB90EF3A Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- << SNIP >> > > > Dean later writes, in response to Brian: > > So you see a requirement to uniquely identify a specific > SIP endpoint > > OUTSIDE of the domain of SIP routing, such that this > identification > > can support further applications? > > > > Use cases here might include: > > > > 1) billing -- "Alice called Bob from phone ID000001 through gateway > > ID3344555 on Tuesday, March 1, 2011" > > I do not understand the need for a globally unique instance ID to > support billing, and would be very scared of fraud issues. If the particular network implementation only hands out the ID to trusted nodes, this is no less safe than our current authentication mechanisms IMHO. I don't forsee using the ID as a "bill to" number, but it could be used to help correlate billing records as a call goes through the system, in which case it does not matter what that value is, just that it's consistient from hop to hop. If you're scared of fraud issues, think about what happens when you send an INVITE into a system with a Referred-By of some unsuspecting third-party user of that system. =) Much worse problem that exists today. You probably won't get a free call, but you might make some interesting international calls before anyone figures out what's going on. > > > > > 2) Debugging -- "This request was responded to by node > IDYIYIOHIHIUH, > > which is a Barfia model 9995 phone running Finux 21.05A and the > > Vocal user agent release 89.6" > > I'm not sure I understand the specific value gleaned from the instance > ID in this case. It survives BBUAs for one. Probably not the best use case, but may be interesting for future thought. System admins will probably love to have a consistient identifier throughout the system identifying what a particular endpoint did throughout a request or requests. The specific use cases I had in mind were to recover from client crashes where it's undesirable, and network policy to limit resource usage. For instance, duplicate subscriptions to the same resource for the same event package from the same client instance. Sure, sometimes it might make sense (can't think of one, but let's assume that there is a case). That still represents network resources (ie. resources associated with storing that subscription and handling it on state changes for that event) and the network might not want to allow duplicates by its own policy (tough crapola client, you only get so much). An instance ID makes this very simple to deal with. Otherwise you're at the mercy of the client, or the server has to guess which subscriptions it has no more resources to handle and should eliminate. Same goes for registrations which was pointed out on another thread. If a client is stateless enough that it can't remember an old contact after crashing, it may still be able to come up with a GUID that the server can then use to figure out to eliminate the now defunct elder contact in favor of the newer one. > > > Another approach is to limit the expression of identity herein to > > that subset of identify which is expressly describable using SIP, > > which makes it analogous to the SIP routing mechanisms > underlying the > > concepts of AoR, asserted identity, and verified/vouchsafed identity > > in the various documents that touch on those concepts. In other > > words, we restrict ourselves to the namspace of SIP AoRs. > If we take that approach then how do we solve the problems I've stated above that exist today? How do we solve problems with generating meaningful identifiers for clients in the reginfo+xml message body, and cpim-pidf message bodies? How do I determine all PUBLISHes are from a particular user agent when it's contact information and other aspects of the PUBLISH may vary over long periods of time? We're going to have to solve these other issues. We're going to need to know which client is generating these requests. It's a similar problem space, and with or without GRUUs, these problems are still going to exist and will eventually need to be tackled. > > Well said. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > ------_=_NextPart_001_01C3F5F2.FB90EF3A Content-Type: text/html; charset="iso-8859-1" RE: Abstraction: SIP instance identifiers requirements

> -----Original Message-----

<< SNIP >>

>
>
> Dean later writes, in response to Brian:
> > So you see a requirement to uniquely identify a specific
> SIP endpoint
> >  OUTSIDE of the domain of SIP routing, such that this
> identification
> > can support further applications?
> >
> > Use cases here might include:
> >
> > 1) billing -- "Alice called Bob from phone ID000001 through gateway
> > ID3344555 on Tuesday, March 1, 2011"
>
> I do not understand the need for a globally unique instance ID to
> support billing, and would be very scared of fraud issues.

If the particular network implementation only hands out the ID to trusted
nodes, this is no less safe than our current authentication mechanisms IMHO.
I don't forsee using the ID as a "bill to" number, but it could be used to
help correlate billing records as a call goes through the system, in which
case it does not matter what that value is, just that it's consistient from
hop to hop.

If you're scared of fraud issues, think about what happens when you send an
INVITE into a system with a Referred-By of some unsuspecting third-party user
of that system. =) Much worse problem that exists today. You probably won't
get a free call, but you might make some interesting international calls
before anyone figures out what's going on.

>
> >
> > 2) Debugging -- "This request was responded to by node
> IDYIYIOHIHIUH,
> >  which is a Barfia model 9995 phone running Finux 21.05A and the
> > Vocal user agent release 89.6"
>
> I'm not sure I understand the specific value gleaned from the instance
> ID in this case.

It survives BBUAs for one. Probably not the best use case, but may be
interesting for future thought. System admins will probably love to have
a consistient identifier throughout the system identifying what a
particular endpoint did throughout a request or requests.

The specific use cases I had in mind were to recover from client crashes
where it's undesirable, and network policy to limit resource usage. For
instance, duplicate subscriptions to the same resource for the same
event package from the same client instance. Sure, sometimes it might
make sense (can't think of one, but let's assume that there is a case).
That still represents network resources (ie. resources associated with
storing that subscription and handling it on state changes for that
event) and the network might not want to allow duplicates by its own
policy (tough crapola client, you only get so much). An instance ID
makes this very simple to deal with. Otherwise you're at the mercy of
the client, or the server has to guess which subscriptions it has no more
resources to handle and should eliminate.

Same goes for registrations which was pointed out on another thread. If
a client is stateless enough that it can't remember an old contact after
crashing, it may still be able to come up with a GUID that the server can
then use to figure out to eliminate the now defunct elder contact in
favor of the newer one.

>
> > Another approach is to limit the expression of identity herein to
> > that subset of identify which is expressly describable using SIP,
> > which makes it analogous to the SIP routing mechanisms
> underlying the
> > concepts of AoR, asserted identity, and verified/vouchsafed identity
> > in the various documents that touch on those concepts. In other
> > words, we restrict ourselves to the namspace of SIP AoRs.
>

If we take that approach then how do we solve the problems I've stated
above that exist today? How do we solve problems with generating meaningful
identifiers for clients in the reginfo+xml message body, and cpim-pidf
message bodies? How do I determine all PUBLISHes are from a particular
user agent when it's contact information and other aspects of the PUBLISH
may vary over long periods of time?

We're going to have to solve these other issues. We're going to need to
know which client is generating these requests. It's a similar problem space,
and with or without GRUUs, these problems are still going to exist and will
eventually need to be tackled.

>
> Well said.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

------_=_NextPart_001_01C3F5F2.FB90EF3A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 04:19:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03192 for ; Wed, 18 Feb 2004 04:19:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtNrU-0004t7-Ua for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 04:19:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I9JKjM018784 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 04:19:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtNrC-0004of-Gu; Wed, 18 Feb 2004 04:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtNqr-0004ht-L9 for sip@optimus.ietf.org; Wed, 18 Feb 2004 04:18:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03163 for ; Wed, 18 Feb 2004 04:18:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtNqo-0000YQ-00 for sip@ietf.org; Wed, 18 Feb 2004 04:18:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtNpp-0000VB-00 for sip@ietf.org; Wed, 18 Feb 2004 04:17:38 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly06a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AtNoz-0000QL-00 for sip@ietf.org; Wed, 18 Feb 2004 04:16:45 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly06a.srv.mailcontrol.com (MailControl) with SMTP id i1I9FOPV010926; Wed, 18 Feb 2004 09:15:24 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Wed, 18 Feb 2004 09:15:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP instance identifiers Date: Wed, 18 Feb 2004 09:15:24 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF1DC@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] SIP instance identifiers Thread-Index: AcP12HmUph+8Xgs+T52h+bVM/hHKnQAJumPw From: "Chris Boulton" To: "Jonathan Rosenberg" , "Paul Kyzivat" Cc: X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > >This needs to be spelled out somewhere, and a suitable error >> identified. (I don't know if any of the existing responses works for >> this. At the least, a new Reason code is likely to be needed.) > >Here is the use case for this. The use case is when a UA crashes, >recovers, obtains a new IP, and re-registers. In this case, several >things could possibly happen: > >1. The registrar accepts the second registration, as per normal >registration procedures. An INVITE to the gruu bound to that id/aor pair >gets translated into BOTH contacts, causing the request to fork. There >is never any response from the old IP. Within one refresh interval, the >old contact is removed and all is well. > >2. The registrar accepts the second registration, and automatically >deletes the old one. I believe Brian proposed this behavior. > >3. The registrar returns an error. The client fetches the current list >of contacts, finds the old one listed, and unregisters it. > > > >Approach 1 is problematic, as it will introduce herfp; any non-2xx from >the new contact will wait for the 2nd branch to timeout. Its not clear >to me whether 2 or 3 is more right. It depends a lot on who owns the >policy for how to resolve the conflict - is it the server or the client? [Chris Boulton] My initial feeling here is that it should be the client's responsibility on receiving a 200 class response with two contacts + different GRUU's should de-register the one it doesn't recognize (The one with the unknown instance ID). Chris. > >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 07:35:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08061 for ; Wed, 18 Feb 2004 07:35:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtQv7-0000An-Kd for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 07:35:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ICZHJn000664 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 07:35:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtQus-00006q-Sg; Wed, 18 Feb 2004 07:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtQuc-000068-43 for sip@optimus.ietf.org; Wed, 18 Feb 2004 07:34:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08022 for ; Wed, 18 Feb 2004 07:34:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtQub-0002fr-00 for sip@ietf.org; Wed, 18 Feb 2004 07:34:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtQtd-0002cm-00 for sip@ietf.org; Wed, 18 Feb 2004 07:33:45 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtQsf-0002Yg-00 for sip@ietf.org; Wed, 18 Feb 2004 07:32:45 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1ICWCuA008215; Wed, 18 Feb 2004 04:32:12 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQJ61951; Wed, 18 Feb 2004 04:32:10 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/alternative; boundary=Apple-Mail-19-16110967 Message-Id: <89BBEFA4-620E-11D8-9B6B-0003938AF740@cisco.com> Cc: From: Rohan Mahy Subject: Re: [Sip] about call waiting using SUBSCRIBE/NOTIFY! Date: Wed, 18 Feb 2004 04:32:38 -0800 To: "jack zhao" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-19-16110967 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I don't think most folks on the list would describe this feature as=20 "call waiting", but a similar feature is described in=20 draft-ietf-sipping-dialog-package thanks, -rohan On Mar 24, 2003, at 6:12 PM, jack zhao wrote: > Dear all, > =A0 > What I expect is like this: > Assume: There are 2 UAs, A and B. > =A0 > 1. A is busy, (In IP2006, that means both=A02 lines has=A0a connection=20= > with somebody) > 2. B call A and got a=A0486 BUSY reply. > 3. B decide to wait for A.=A0B=A0send a=A0SUBSCRIBE to A=A0and hang = up.=A0 > 4. After certain period of time, A finally close one of it's=20 > connection and has a free > =A0=A0=A0 line. > 5. A send a NOTIFY to B indicate that he is free to accept = connection. > 6. B receive this NOTIFY and start to ring. B UNSUBSCRIBE the event=20 > also. > 7. After user pickup B, B send a INVITE to A try to establish a=20 > connection. > 8. A start ringing when it receive INVITE. =46rom now on, it is the = same=20 > as the > =A0=A0=A0 regular call out. > =A0 > If you have got the IETF draft or RFC about call-waiting please tell=20= > me or send it to me. > =A0 > Best Regards, > jack zhao --Apple-Mail-19-16110967 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I don't think most folks on the list would describe this feature as "call waiting", but a similar feature is described in draft-ietf-sipping-dialog-package thanks, -rohan On Mar 24, 2003, at 6:12 PM, jack zhao wrote: 0000,0000,FFFFDear = all, =A0 = Helvetica0000,0000,FFFFWhat I expect is like this: = Helvetica0000,0000,FFFFAssume: There are 2 UAs, A and B. =A0 = Helvetica0000,0000,FFFF1. A is busy, (In IP2006, that means both=A02 lines has=A0a connection with somebody) = Helvetica0000,0000,FFFF2. B call A and got a=A0486 BUSY reply. = Helvetica0000,0000,FFFF3. B decide to wait for A.=A0B=A0send a=A0SUBSCRIBE to A=A0and hang = up.=A0 = Helvetica0000,0000,FFFF4. After certain period of time, A finally close one of it's connection and has a free = Helvetica0000,0000,FFFF=A0=A0=A0 line. = Helvetica0000,0000,FFFF 5. A send a NOTIFY to B indicate that he is free to accept = connection. = Helvetica0000,0000,FFFF6. B receive this NOTIFY and start to ring. B UNSUBSCRIBE the event = also. = Helvetica0000,0000,FFFF7. After user pickup B, B send a INVITE to A try to establish a connection. = Helvetica0000,0000,FFFF8. A start ringing when it receive INVITE. =46rom now on, it is the same as the = Helvetica0000,0000,FFFF=A0=A0=A0 regular call out. =A0 = Helvetica0000,0000,FFFFIf you have got the IETF draft or RFC about call-waiting please tell me or send it to me. =A0 = Helvetica0000,0000,FFFFBest Regards, = Helvetica0000,0000,FFFFjack zhao = --Apple-Mail-19-16110967-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 07:49:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08586 for ; Wed, 18 Feb 2004 07:49:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtR8V-0002Hr-TI for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 07:49:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ICn7Hc008763 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 07:49:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtR8P-0002FW-IX; Wed, 18 Feb 2004 07:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtR7Q-0002EK-UV for sip@optimus.ietf.org; Wed, 18 Feb 2004 07:48:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08530 for ; Wed, 18 Feb 2004 07:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtR7Q-0003Qj-00 for sip@ietf.org; Wed, 18 Feb 2004 07:48:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtR6Y-0003Mj-00 for sip@ietf.org; Wed, 18 Feb 2004 07:47:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AtR5x-0003HB-00 for sip@ietf.org; Wed, 18 Feb 2004 07:46:30 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1ICjucw015626; Wed, 18 Feb 2004 04:45:57 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQJ62444; Wed, 18 Feb 2004 04:45:55 -0800 (PST) In-Reply-To: <017B1BB60535DF4285666089FA048AC20172EFE6@SONOMA.netscreen.com> References: <017B1BB60535DF4285666089FA048AC20172EFE6@SONOMA.netscreen.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/alternative; boundary=Apple-Mail-20-16935754 Message-Id: <75587981-6210-11D8-9B6B-0003938AF740@cisco.com> Cc: "'sip@ietf.org'" From: Rohan Mahy Subject: Re: [Sip] Changing Via In NAT Date: Wed, 18 Feb 2004 04:46:23 -0800 To: Anil Bollineni X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-20-16935754 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable On Feb 13, 2004, at 11:07 AM, Anil Bollineni wrote: > Dear All, > > In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT =20 > traversal. The received and rport parameter are used to send back the =20= > responses correctly. This is an extremely old reference. The name was changed to =20 draft-ietf-sip-symmetric-response, and is now published as RFC 3581. > However if we don't use these extensions, and change the via ip =20 > address and port with that of firewall/port then the SIP responses =20 > will come directly to firewall, in that case the firewall permits the =20= > responses. UA1 inside the network sends requests to firewall/NAT. > > > UA1 > > INVITE sip:user@domain.com SIP/2.0 --------------=E0 Firewall/NAT =20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ---------------------------------------------=E0UA2 > > Via: SIP/2.0/UDP 10.1.1.1:4540=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 INVITE =20 > sip:user@domain.com SIP/2.0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > > Via: SIP/2.0/UDP firewall_ip:5060 > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 > (Maintain mapping) > > > the UA2 will send the responses to firewall/NAT and firewall/NAT will =20= > write back the addresses in Via to original IP/port. I understand from = =20 > the draft, if there are no SIP ALG functionality in firewall, then the = =20 > extensions are used to make SIP traverse through NAT. However if we =20= > implement SIP ALG in firewall then we can make SIP traverse through =20= > NAT. Can anybody tell that this way is per SIP spec. The experience of the working group has shown that implementing a SIP =20= ALG in a firewall is "a bad thing". I have personal experience with =20 the failings of SIP ALGs at my own company, not the least of which is =20= that they don't work at all when SIP is integrity-protected using TLS. Many UAs now support RFC 3581 and can use the STUN protocol to get =20 valid public addresses and ports to advertise in SDP for their RTP =20 traffic. This has been relatively painless compared to working with the =20= shortcomings of ALGs. thanks, -rohan --Apple-Mail-20-16935754 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Feb 13, 2004, at 11:07 AM, Anil Bollineni wrote: ArialDear = All, ArialIn draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT traversal. The received and rport parameter are used to send back the responses correctly.=20 This is an extremely old reference. The name was changed to draft-ietf-sip-symmetric-response, and is now published as RFC 3581. ArialHowever if we don't use these extensions, and change the via ip address and port with that of firewall/port then the SIP responses will come directly to firewall, in that case the firewall permits the responses. UA1 inside the network sends requests to = firewall/NAT. = ArialUA1 Arial INVITE sip:user@domain.com SIP/2.0 = --------------=E0= Arial Firewall/NAT =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ---------------------------------------------<= x-tad-bigger>=E0ArialUA2 ArialVia: SIP/2.0/UDP 10.1.1.1:4540=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 INVITE sip:user@domain.com SIP/2.0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Arial Via: SIP/2.0/UDP firewall_ip:5060 = Arial=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (Maintain mapping) Arialthe UA2 will send the responses to firewall/NAT and firewall/NAT will write back the addresses in Via to original IP/port. I understand from the draft, if there are no SIP ALG functionality in firewall, then the extensions are used to make SIP traverse through NAT. However if we implement SIP ALG in firewall then we can make SIP traverse through NAT. Can anybody tell that this way is per SIP spec. The experience of the working group has shown that implementing a SIP ALG in a firewall is "a bad thing". I have personal experience with the failings of SIP ALGs at my own company, not the least of which is that they don't work at all when SIP is integrity-protected using TLS. Many UAs now support RFC 3581 and can use the STUN protocol to get valid public addresses and ports to advertise in SDP for their RTP traffic. This has been relatively painless compared to working with the shortcomings of ALGs. thanks, -rohan --Apple-Mail-20-16935754-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 07:55:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08827 for ; Wed, 18 Feb 2004 07:55:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtREJ-0002tS-EX for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 07:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ICt7bw011105 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 07:55:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtREE-0002s4-MC; Wed, 18 Feb 2004 07:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRE2-0002rQ-Jo for sip@optimus.ietf.org; Wed, 18 Feb 2004 07:54:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08823 for ; Wed, 18 Feb 2004 07:54:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtRE1-0003sn-00 for sip@ietf.org; Wed, 18 Feb 2004 07:54:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtRD9-0003qX-00 for sip@ietf.org; Wed, 18 Feb 2004 07:53:56 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtRCi-0003o2-00 for sip@ietf.org; Wed, 18 Feb 2004 07:53:28 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2004 05:01:53 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1ICqt4U026050; Wed, 18 Feb 2004 04:52:56 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQJ62714; Wed, 18 Feb 2004 04:52:46 -0800 (PST) In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F38101661A@MAILSERVER> References: <9A64A99CD3F2BD4582BE4FB63FC1F38101661A@MAILSERVER> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/alternative; boundary=Apple-Mail-21-17346777 Message-Id: <6A557CF2-6211-11D8-9B6B-0003938AF740@cisco.com> Cc: "'Cullen Jennings'" , sip@ietf.org From: Rohan Mahy Subject: Re: [Sip] Binary Encoding for SIP Date: Wed, 18 Feb 2004 04:53:14 -0800 To: Raphael Tryster X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-21-17346777 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Raphael, Just as an FYI: The "unpopular" encoding for H.248 is ASN.1 encoding=20 of the entire protocol. What Cullen is proposing is sending all *MIME=20= bodies* in SIP as a stream of raw binary data (like HTTP). This is=20 instead of sending SIP MIME bodes as a stream of base64-encoded data=20 for example, which is unnecessary in modern protocols, but was required=20= in email for backwards compatibility reasons. (btw: I vote for a) thanks, -rohan On Feb 15, 2004, at 12:13 AM, Raphael Tryster wrote: > Hello Cullen, > > Given that this is my first venture into the SIP email forum, and the=20= > first response to your posting, it is only fitting that I should vote=20= > for option c:). > > During the coming year or two, I hope to develop an opinion on whether=20= > the issues of backward compatibility and ease of debugging, which seem=20= > to make the binary option rather unpopular in Megaco, apply to SIP as=20= > well.=A0 If they do, it could have an adverse affect on World Hunger, = as=20 > those with the right tools to debug binary messages will eat more, at=20= > the expense of the rest. > > Raphael Tryster > > -----Original Message----- > From:=A0=A0 Cullen Jennings [SMTP:fluffy@cisco.com] > Sent:=A0=A0 Sunday, 15 February 2004 9:03 > To:=A0=A0=A0=A0 sip@ietf.org > Subject:=A0=A0=A0=A0=A0=A0=A0 [Sip] Binary Encoding for SIP > > =A0=A0=A0 > I submitted a draft on binary encoding for SIP. This improves > interoperability, improves speed, decreases sizes of messages, and=20 > generally > makes life better for SIP which will no doubt eventually help with=20 > World > Hunger. I need feedback, please let me know: > > a) Yah, lets do it > > b) No this is a stupid ideas and here are the reasons why > > c) There has not been many list comments, this draft involves some = very > complex issues. I need a year or two to develop an opinion on the=20 > single > sentence inside it. > > d) I agree with Cowboy Willis > > Until it arrives in the archives, you can find it at > > http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html > > or, if you prefer ASCII encodings of everything, > > www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt > > Thanks, Cullen > > > > > > > > > _______________________________________________ > Sip mailing list=A0 https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-21-17346777 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Raphael, Just as an FYI: The "unpopular" encoding for H.248 is ASN.1 encoding of the entire protocol. What Cullen is proposing is sending all *MIME bodies* in SIP as a stream of raw binary data (like HTTP). This is instead of sending SIP MIME bodes as a stream of base64-encoded data for example, which is unnecessary in modern protocols, but was required in email for backwards compatibility reasons. (btw: I vote for a) thanks, -rohan On Feb 15, 2004, at 12:13 AM, Raphael Tryster wrote: ArialHello Cullen,=20 ArialGiven that this is my first venture into the SIP email forum, and the first response to your posting, it is only fitting that I should vote for option = c:). ArialDuring the coming year or two, I hope to develop an opinion on whether the issues of backward compatibility and ease of debugging, which seem to make the binary option rather unpopular in Megaco, apply to SIP as well.=A0 If they do, it could have an adverse affect on World Hunger, as those with the right tools to debug binary messages will eat more, at the expense of the rest. TahomaRaphael Tryster=20 Arial-----Original Message-----=20 ArialFrom:=A0=A0 Cullen = Jennings [SMTP:fluffy@cisco.com]=20 = ArialSent:=A0=A0 ArialSunday, 15 February 2004 9:03=20 = ArialTo:=A0=A0=A0=A0 = Arialsip@ietf.org=20 = ArialSubject:=A0=A0=A0=A0=A0=A0=A0= Arial[Sip] Binary Encoding for SIP=20 Courier New=A0=A0=A0 = Courier NewI submitted a draft on binary encoding for SIP. This improves=20 Courier Newinteroperability, improves speed, decreases sizes of messages, and generally=20 Courier Newmakes life better for SIP which will no doubt eventually help with World=20 Courier NewHunger. I need feedback, please let me know:=20 Courier Newa) Yah, lets do it=20 Courier Newb) No this is a stupid ideas and here are the reasons why=20 Courier Newc) There has not been many list comments, this draft involves some very=20 Courier Newcomplex issues. I need a year or two to develop an opinion on the single=20 Courier Newsentence inside it.=20 Courier Newd) I agree with Cowboy Willis=20 Courier NewUntil it arrives in the archives, you can find it at=20 Courier = New0000,0000,EEEEhttp://www.employe= es.org/~fluffy/ietf/draft-jennings-sip-mime-01.html=20 Courier Newor, if you prefer ASCII encodings of everything,=20 Courier = Newwww.employees.org/~fluffy/ietf/draft-jennings-sip-mime= -01.txt=20 Courier NewThanks, Cullen=20 Courier = New_______________________________________________=20 Courier NewSip mailing list=A0 = 0000,0000,EEEEhttps://www1.ietf.org/mailman/listinfo= /sip=20 Courier NewThis list is for NEW development of the core SIP Protocol=20 Courier NewUse sip-implementors@cs.columbia.edu for questions on current sip=20 Courier NewUse sipping@ietf.org for new developments on the application of sip=20 = --Apple-Mail-21-17346777-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 08:22:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09670 for ; Wed, 18 Feb 2004 08:22:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtReU-0004Pl-4L for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 08:22:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IDM96b016872 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 08:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtReM-0004Na-BQ; Wed, 18 Feb 2004 08:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtReI-0004NA-4W for sip@optimus.ietf.org; Wed, 18 Feb 2004 08:21:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09666 for ; Wed, 18 Feb 2004 08:21:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtReH-0005QZ-00 for sip@ietf.org; Wed, 18 Feb 2004 08:21:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtRdT-0005NJ-00 for sip@ietf.org; Wed, 18 Feb 2004 08:21:08 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtRd1-0005Ik-00 for sip@ietf.org; Wed, 18 Feb 2004 08:20:39 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2004 05:29:45 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1IDK7uA008930; Wed, 18 Feb 2004 05:20:07 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQJ63979; Wed, 18 Feb 2004 05:20:05 -0800 (PST) In-Reply-To: <200402162041.PAA20081@ietf.org> References: <200402162041.PAA20081@ietf.org> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3B05A58F-6215-11D8-9B6B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: aki.niemi@nokia.com From: Rohan Mahy Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-publish-03.txt Date: Wed, 18 Feb 2004 05:20:33 -0800 To: "'sip@ietf.org'" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, I just noticed a minor problem with publish ; it defines a new response code: 412 Precondition Failed which is confusingly similar to the existing response code: 580 Precondition Failure I propose changing The reason phrase for 412 to "Publication Condition Failed" thanks, -rohan On Feb 16, 2004, at 12:41 PM, 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 : Session Initiation Protocol (SIP) Extension for Event State > Publication > Author(s) : A. Niemi > Filename : draft-ietf-sip-publish-03.txt > Pages : 40 > Date : 2004-2-16 > > This document describes an extension to the Session Initiation > Protocol (SIP) for publishing event state used within the framework > for SIP Event Notification. The first application of this extension > is targeted at the publication of presence information. > The mechanism described in this document can be extended to support > publication of any event state, for which there exists an appropriate > event package. It is not intended to be a general-purpose mechanism > for transport of arbitrary data, as there are better-suited > mechanisms for this purpose (FTP, HTTP, etc.) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-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-publish-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-publish-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. > Content-Type: text/plain > Content-ID: <2004-2-16123306.I-D@ietf.org> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 08:33:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10094 for ; Wed, 18 Feb 2004 08:33:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRpB-0005pV-4D for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 08:33:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IDXCcS022346 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 08:33:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRp0-0005nK-TG; Wed, 18 Feb 2004 08:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRo5-0005kR-PQ for sip@optimus.ietf.org; Wed, 18 Feb 2004 08:32:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10079 for ; Wed, 18 Feb 2004 08:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtRo4-00065o-00 for sip@ietf.org; Wed, 18 Feb 2004 08:32:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtRn7-00061x-00 for sip@ietf.org; Wed, 18 Feb 2004 08:31:07 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AtRmV-0005xD-00 for sip@ietf.org; Wed, 18 Feb 2004 08:30:28 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2004 05:30:00 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1IDTt4U022937; Wed, 18 Feb 2004 05:29:55 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQJ64562; Wed, 18 Feb 2004 05:29:53 -0800 (PST) In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B5975304B2164F@zrc2c012.us.nortel.com> References: <161AA64DA85DFC4BA4D2EB5629B5975304B2164F@zrc2c012.us.nortel.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/alternative; boundary=Apple-Mail-22-19573831 Message-Id: <99C31C1C-6216-11D8-9B6B-0003938AF740@cisco.com> Cc: Cullen Jennings , Dean Willis , Jonathan Rosenberg , sip@ietf.org From: Rohan Mahy Subject: Re: [Sip] RE: Abstraction: SIP instance identifiers requirements Date: Wed, 18 Feb 2004 05:30:21 -0800 To: "Brian Stucker" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-22-19573831 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Feb 17, 2004, at 10:37 AM, Brian Stucker wrote: > I think that your list is missing the opportunity to define this > instance > ID in such a way that it can be used to identify a particular endpoint > for other operations beyond simply routing. For example please? Your draft jumps straight into mechanism. thanks, -rohan > The reuse potential seems > very good if we don't lock the instance identifier down to simply > routing operations, and instead open it up for other general-purpose > operations. > > That is at the heart of my draft. Don't limit yourself to one > application > when with a small amount of work we can use this to solve other > problems > both current and future. Likewise, don't exclude routing operations > from > making use of the instance identifier either. > > Are you concerned that opening this up to having the instance > identifier > transported (in addition to the registered contact) outside of the > registered contact is really going to be that complex? > > Regards, > > Brian > > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, February 17, 2004 12:11 PM > > To: Cullen Jennings > > Cc: Stucker, Brian [NGC:B617:EXCH]; Jonathan Rosenberg; sip@ietf.org > > Subject: Abstraction: SIP instance identifiers requirements > > > > > > > > Based on the discussion of "routing" based on instance identifiers, I > > think we may be getting involved in triggerwork that may become more > > complex than is actually required, because we're all reasoning from > > secondary positions. So I'd like to take a step back and > > consider how we > > got here, and what we think we're trying to accomplish. > > > > I see four high-level cases around request routing that illustrate > > different aspects of this discussion. > > > > 1) General case: We wish to address a request to an AOR, such > > that any > > contact at that AOR might respond. This is basic 2543-type > > routing behavior. > > > > 2) Capability case: We wish to address a request to an AOR, such that > > any contact capable of satisfying the request in a way that we like > > might respond. This behavior is brought out in callee-caps and > > caller-preferences and the accept/supported/required syntax of 3261. > > > > 3) Followups to a specific instance: We have previously done > > something > > (such as case 1 or 2) such that the operation of interest has > > resolved > > to a specific contact instance associated with an AoR, and we wish > > subsequent operations (for example, a transfer) to reach that same > > specific contact instance, even if that specific contact instance is > > hidden behind an indirection layer (firewall, anonymizer, etc.). As I > > understand it, this is the heart of the GRUU concept. > > > > 4) Selection of a specific instance in an initial request: We have a > > request that we wish to reach one specific instance of a contact > > associated with an AoR. It has been proposed that we > > accomplish this by > > binding some sort of instance tag to the AoR. It has been > > proposed that > > we use some sort of URI convention (like the msuri), +based > > subaddressing, or that we use a header convention for binding the > > instance tag to the AoR. To my knowledge, we haven't really described > > the requirement or use case for reaching a specific instance on an > > initial request, but I can think of several offhand > > (including diagnostics). > > > > It seems evident that there is a huge overlap between the > > requirements > > of 3 and 4. Indeed, I think #3 (GRUU) came out of early ideas > > I had on > > using a REGISTER-response extension to assign an instance-AoR to a > > Contact. It would appear that IF each contact for an AoR were > > to have an > > associated GRUU, and that knowledge of those GRUU assigments were > > available to a requestor, that the requester could use the > > target-specific GRUU to achieve the use cases I currently > > imagine for #4. > > > > > > What am I missing here? > > > > -- > > Dean > > --Apple-Mail-22-19573831 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Feb 17, 2004, at 10:37 AM, Brian Stucker wrote: I think that your list is missing the opportunity to define this instance ID in such a way that it can be used to identify a particular endpoint for other operations beyond simply routing. For example please? Your draft jumps straight into mechanism. thanks, -rohan The reuse potential seems very good if we don't lock the instance identifier down to simply routing operations, and instead open it up for other general-purpose operations. That is at the heart of my draft. Don't limit yourself to one application when with a small amount of work we can use this to solve other problems both current and future. Likewise, don't exclude routing operations from making use of the instance identifier either. Are you concerned that opening this up to having the instance identifier transported (in addition to the registered contact) outside of the registered contact is really going to be that complex? Regards, Brian > -----Original Message----- > From: Dean Willis [0000,0000,EEEEmailto:dean.willis@softarmor.com] > Sent: Tuesday, February 17, 2004 12:11 PM > To: Cullen Jennings > Cc: Stucker, Brian [NGC:B617:EXCH]; Jonathan Rosenberg; sip@ietf.org > Subject: Abstraction: SIP instance identifiers requirements > > > > Based on the discussion of "routing" based on instance identifiers, I > think we may be getting involved in triggerwork that may become more > complex than is actually required, because we're all reasoning from > secondary positions. So I'd like to take a step back and > consider how we > got here, and what we think we're trying to accomplish. > > I see four high-level cases around request routing that illustrate > different aspects of this discussion. > > 1) General case: We wish to address a request to an AOR, such > that any > contact at that AOR might respond. This is basic 2543-type > routing behavior. > > 2) Capability case: We wish to address a request to an AOR, such that > any contact capable of satisfying the request in a way that we like > might respond. This behavior is brought out in callee-caps and > caller-preferences and the accept/supported/required syntax of 3261. > > 3) Followups to a specific instance: We have previously done > something > (such as case 1 or 2) such that the operation of interest has > resolved > to a specific contact instance associated with an AoR, and we wish > subsequent operations (for example, a transfer) to reach that same > specific contact instance, even if that specific contact instance is > hidden behind an indirection layer (firewall, anonymizer, etc.). As I > understand it, this is the heart of the GRUU concept. > > 4) Selection of a specific instance in an initial request: We have a > request that we wish to reach one specific instance of a contact > associated with an AoR. It has been proposed that we > accomplish this by > binding some sort of instance tag to the AoR. It has been > proposed that > we use some sort of URI convention (like the msuri), +based > subaddressing, or that we use a header convention for binding the > instance tag to the AoR. To my knowledge, we haven't really described > the requirement or use case for reaching a specific instance on an > initial request, but I can think of several offhand > (including diagnostics). > > It seems evident that there is a huge overlap between the > requirements > of 3 and 4. Indeed, I think #3 (GRUU) came out of early ideas > I had on > using a REGISTER-response extension to assign an instance-AoR to a > Contact. It would appear that IF each contact for an AoR were > to have an > associated GRUU, and that knowledge of those GRUU assigments were > available to a requestor, that the requester could use the > target-specific GRUU to achieve the use cases I currently > imagine for #4. > > > What am I missing here? > > -- > Dean > --Apple-Mail-22-19573831-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 08:46:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10583 for ; Wed, 18 Feb 2004 08:46:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS1l-00076Y-OH for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 08:46:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IDkDtc027248 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 08:46:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS1b-00074Q-6B; Wed, 18 Feb 2004 08:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS1R-00073s-Jx for sip@optimus.ietf.org; Wed, 18 Feb 2004 08:45:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10574 for ; Wed, 18 Feb 2004 08:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtS1Q-0006zR-00 for sip@ietf.org; Wed, 18 Feb 2004 08:45:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtS0X-0006xA-00 for sip@ietf.org; Wed, 18 Feb 2004 08:44:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AtS0G-0006uD-00 for sip@ietf.org; Wed, 18 Feb 2004 08:44:40 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2004 05:44:12 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1IDi7vV013316; Wed, 18 Feb 2004 05:44:08 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQJ65129; Wed, 18 Feb 2004 05:44:06 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <967CD2FA-6218-11D8-9B6B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: From: Rohan Mahy Subject: Re: [Sip] Proxy behavior Date: Wed, 18 Feb 2004 05:44:35 -0800 To: "Rajesh Khandewale" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Feb 4, 2004, at 2:00 PM, Rajesh Khandewale wrote: > I have a question about the proxy behavior under the following > scenario, > could someone please provide a clarification. > > 1. UAC sends an INVITE via proxy. > 2. Proxy responds back with 100 trying message to UAC and forwards > INVITE to > UAS. > 3. UAS sends 200 OK which is relayed by the proxy to UAC. > 4. UAC sends an ACK which is being processed by the proxy to be > forwarded to > the UAS. > ** Here ACK has sequence number 1 > 5. UAC sends another INVITE and incidentally this gets forwarded to > the UAS > before the ACK from previous INVITE by the proxy. > ** Here INVITE has sequence number 2 > 6. Since UAS did not receive the ACK for previous INVITE (nor did it > received CANCEL/BYE), but received another INVITE with same Call-ID > etc. it > throws a "500 Internal Server Error" error. > > According to RFC 3261, the UAS behavior to throw a "500 Internal Server > Error" is correct. But I am not sure about the proxy behavior here, > could > not be clearly figured out of 3261. > > Is proxy supposed to correlate all the messages based on the sequence > number > and call-id and essentially send an ACK before sending out second > INVITE. Or > they are completely different transactions and this is a normal proxy > behavior. They are completely different transactions. The proxy just forwards the 500 response normally. In future, please direct these kinds of requests to sip-implementors@cs.columbia.edu thanks, -rohan > Thanks, > > Rajesh. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 08:52:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10818 for ; Wed, 18 Feb 2004 08:52:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS7R-0007jG-2A for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 08:52:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IDq4db029683 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 08:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS7O-0007ht-E7; Wed, 18 Feb 2004 08:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS7C-0007h5-UX for sip@optimus.ietf.org; Wed, 18 Feb 2004 08:51:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10794 for ; Wed, 18 Feb 2004 08:51:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtS7B-0007NB-00 for sip@ietf.org; Wed, 18 Feb 2004 08:51:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtS6E-0007Iu-00 for sip@ietf.org; Wed, 18 Feb 2004 08:50:50 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtS5O-0007Dg-00 for sip@ietf.org; Wed, 18 Feb 2004 08:49:58 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2004 05:59:04 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1IDnP1m019878; Wed, 18 Feb 2004 05:49:25 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQJ65348; Wed, 18 Feb 2004 05:49:24 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <528E64B6-6219-11D8-9B6B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: From: Rohan Mahy Subject: Re: [Sip] Transport parameter in request URI Date: Wed, 18 Feb 2004 05:49:50 -0800 To: "Vijay Gaur" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, In future, please ask these types of "how to" questions on sip-implementors@cs.columbia.edu UA2 should send its BYE request to the address in the Contact from UA1. The transport parameter is optional, so if there is no transport parameter in its request URI, UA2 will use the default transport (UDP for sip: and TCP for sips: ). The response to the BYE will use the same transport as the request. If you have a followup question, please post it to sip-implementors. thanks, -rohan On Feb 5, 2004, at 6:52 AM, Vijay Gaur wrote: > Hi, > My setup is like this: > > UA1----->(TLS)----->Proxy------>(UDP)--->UA2 > > Here UA1 makes call and dialog gets established between UA1 and UA2. > Contact of UA2 contains transport parameter tls (Contact: > sip@ua1.com;transport=tls). Now when UA2 generates BYE it doesn't put > any transport parameter in request URI (BYE sip:ua1.com SIP/2.0). > Because of no transport parameter BYE doesn't get 200OK. > Now my question is which transport (TLS or UDP) UA2 should put in > request URI? > RFC 3261 says that in request message agent should put transport > parameter in request URI with transport which it is using. > If I put transport=udp in request URI UA2 BYE doesn't get 200OK, but > in case of transport=tls it works fine. > > I appreciate your help. > Thanks, > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 10:15:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18811 for ; Wed, 18 Feb 2004 10:15:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTPs-0004Vp-Jl for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:15:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFFCka017339 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTPk-0004S8-Rp; Wed, 18 Feb 2004 10:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTOi-0003yR-3Q for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:14:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18632 for ; Wed, 18 Feb 2004 10:13:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTOf-0007ZB-00 for sip@ietf.org; Wed, 18 Feb 2004 10:13:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTNj-0007R0-00 for sip@ietf.org; Wed, 18 Feb 2004 10:13:00 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtTMn-0007BT-00 for sip@ietf.org; Wed, 18 Feb 2004 10:12:01 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1IFBS1m027403; Wed, 18 Feb 2004 07:11:29 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGD17456; Wed, 18 Feb 2004 10:11:27 -0500 (EST) Message-ID: <4033809F.30401@cisco.com> Date: Wed, 18 Feb 2004 10:11:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Stucker CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] SIP instance identifiers References: <161AA64DA85DFC4BA4D2EB5629B5975304B81C63@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Responding to both Jonathan and Brian inline... Paul Brian Stucker wrote: > Inline... > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] ... > > > Regarding the form of guids, I don't think any single > > scheme works in > > > all cases. My preference is to: > > > > > > - represent the instance id as a URI > > > > > > - make it the responsibility of the endpoint to select a URI > > > that is unique > > > > > > - Recommend that a URN be used. > > > > > > - Define a couple of new URN namespaces that are especially > > > suitable for this purpose. (I have in mind urn:mac:xxx for > > > mac addresses, and possibly urn:random:xxx for random numbers > > > in some large range.) > > > > This is a well trod area, and I think it would behoove us to look at > > work in other groups. Dean has mentioned HIP as one obvious > > candidate; > > generally speaking this exact issue - of endpoint identifiers > > that work > > better than IP address, is the subject of much other work at this > > moment, including MAST. I'm not familiar enough with it to > > know if its > > relevant... its on my reading list for this ietf. I'm fine with reusing existing work. What is HIP? My primary point is to give the endpoint flexibility in the form of identifier it uses by representing the identifier as a URI. Beyond that, I wanted to ensure that we had a way to use a mac address as one of the options. I didn't find a way to do that in URI/URN form, which is why I suggest defining a new URN namespace for this. If there is some other standard that already achieves this, fine. I'm not at all attached to any particular way of using random numbers. I'm happy with pretty much anything that permits an instance of a software endpoint on a multi-user/multi-application box to come up with a guid. > This represents additional work as well. =) > > I think we're limiting ourselves to just MACs and random numbers. I'm not suggesting *limiting* to macs and random numbers. Just that tese be available options. > Having > looked around a bit, I've seen material (I want to say it's from WebDAV > but I could be remembering incorrectly) that the MAC address isn't always > a good thing to pass around because you can figure out that the UA is > running on a particular piece of hardware without otherwise having access > to their MAC (because you're on the other side of the world many routers > away). That can be used to determine a method of attack because you can > inferr what operating systems, etc might be running if you know what kind > of hardware that box is plugged into the network with. > > That said, if you want to use a MAC, fine. Buyer beware. If you want to use > a random number, fine. If you want to use the GPS coordinates of the box to > some ridiculous level of precision (and that's good enough for your > application) > fine. > > I don't see why we necessarily need to put any restrictions on this > instance ID to make it a URN or anything else when it really need not be > any > more complex than a VIA branch. I also don't see a reason why we should > expect > other nodes in the network to be able to use the instance identifier for > anything > other than a token (ie. if it's a mac address, and two UA instances do > something > because it's a MAC address, that's OK, but other's may not take that > tact). There's > no guarantee others are going to be able to take whatever action might > be denoted > by the contents of the instance identifier itself, so it becomes entirely > proprietary at that point. The reason to use URIs/URNs is to manage the namespaces. Your MAC-based id may collide with my timestamp-based id if there isn't something to distinguish that they come from different namespaces. For that matter, your mac-based id may conflict with my mac-based id if we choose to format them differently. By using URIs, there is always some specification that governs the format and defines uniqueness within that format, while the scheme name itself ensures uniqueness of ids generated based on different specifications. > > > This 1:0..1 relationship imposes another error condition on > > registrars. > > > If an attempt is made to register a contact with an > > instance id in use > > > by some other contact of the same AOR, the registrar will > > have to refuse > > > it. > > > > Well, thats one option. You are right - there are other options. > This is why I put some boundaries on the length of the GUID and some > basic guidelines, to make this very unlikely to occur for reasonably > well behaved implementations. That assumes it isn't done on purpose. In any case, the whole concept of GRUUs is based on the uniqueness, so the registrar is bound to enforce this uniqueness, one way or another. > > This needs to be spelled out somewhere, and a suitable error > > > identified. (I don't know if any of the existing responses > > works for > > > this. At the least, a new Reason code is likely to be needed.) > > > > Here is the use case for this. The use case is when a UA crashes, > > recovers, obtains a new IP, and re-registers. In this case, several > > things could possibly happen: > > > > 1. The registrar accepts the second registration, as per normal > > registration procedures. An INVITE to the gruu bound to that > > id/aor pair > > gets translated into BOTH contacts, causing the request to > > fork. There > > is never any response from the old IP. Within one refresh > > interval, the > > old contact is removed and all is well. > > > > 2. The registrar accepts the second registration, and automatically > > deletes the old one. I believe Brian proposed this behavior. > > > > 3. The registrar returns an error. The client fetches the > > current list > > of contacts, finds the old one listed, and unregisters it. > > > > Approach 1 is problematic, as it will introduce herfp; any > > non-2xx from > > the new contact will wait for the 2nd branch to timeout. This is also problematic because it violates the invariant on which GURR is based - that it always represents a single endpoint. > > Its not clear > > to me whether 2 or 3 is more right. It depends a lot on who owns the > > policy for how to resolve the conflict - is it the server or > > the client? I agree that the right choice here isn't immediately obvious. But having the registrar generate an error is a way to push the decision back on the endpoint. If it wants to prevail then it can send a new REGISTER that removes the old conflicting contact as well as adding its own new one. Or it can just give up. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 10:17:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19003 for ; Wed, 18 Feb 2004 10:17:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTRh-0005Da-Fk for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:17:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFH5o4020050 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTRe-0005BR-0y; Wed, 18 Feb 2004 10:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTRV-000595-E3 for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:16:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18955 for ; Wed, 18 Feb 2004 10:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTRT-00005l-00 for sip@ietf.org; Wed, 18 Feb 2004 10:16:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTQU-0007mj-00 for sip@ietf.org; Wed, 18 Feb 2004 10:15:50 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtTPV-0007bt-00 for sip@ietf.org; Wed, 18 Feb 2004 10:14:49 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1IFEFuA005622; Wed, 18 Feb 2004 07:14:15 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGD17660; Wed, 18 Feb 2004 10:14:14 -0500 (EST) Message-ID: <40338145.3040608@cisco.com> Date: Wed, 18 Feb 2004 10:14:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] SIP instance identifiers References: <45730E094814E44488F789C1CDED27AE02BDF1DC@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chris, See my prior response to Jonathan and Brian. I agree it is the endpoint's responsibility to fix this. But the registrar still needs to preserve uniqueness of the identifier. Your proposal has the potential of having a non-unique identifier. Paul Chris Boulton wrote: > >>This needs to be spelled out somewhere, and a suitable error >> >>>identified. (I don't know if any of the existing responses works for >>>this. At the least, a new Reason code is likely to be needed.) >> >>Here is the use case for this. The use case is when a UA crashes, >>recovers, obtains a new IP, and re-registers. In this case, several >>things could possibly happen: >> >>1. The registrar accepts the second registration, as per normal >>registration procedures. An INVITE to the gruu bound to that id/aor > > pair > >>gets translated into BOTH contacts, causing the request to fork. There >>is never any response from the old IP. Within one refresh interval, the >>old contact is removed and all is well. >> >>2. The registrar accepts the second registration, and automatically >>deletes the old one. I believe Brian proposed this behavior. >> >>3. The registrar returns an error. The client fetches the current list >>of contacts, finds the old one listed, and unregisters it. >> >> >> >>Approach 1 is problematic, as it will introduce herfp; any non-2xx from >>the new contact will wait for the 2nd branch to timeout. Its not clear >>to me whether 2 or 3 is more right. It depends a lot on who owns the >>policy for how to resolve the conflict - is it the server or the > > client? > > [Chris Boulton] My initial feeling here is that it should be the > client's responsibility on receiving a 200 class response with two > contacts + different GRUU's should de-register the one it doesn't > recognize (The one with the unknown instance ID). > > Chris. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 10:33:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21741 for ; Wed, 18 Feb 2004 10:33:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtThP-0002RL-5k for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:33:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFXJTf009378 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:33:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTh8-0002Ol-Vr; Wed, 18 Feb 2004 10:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTgn-0002Kg-LE for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21542 for ; Wed, 18 Feb 2004 10:32:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTgk-0002MZ-00 for sip@ietf.org; Wed, 18 Feb 2004 10:32:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTfi-0002CO-00 for sip@ietf.org; Wed, 18 Feb 2004 10:31:35 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AtTeZ-00020O-00 for sip@ietf.org; Wed, 18 Feb 2004 10:30:23 -0500 Received: from localhost (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id i1IFTTp24934; Wed, 18 Feb 2004 10:29:29 -0500 Subject: Re: [Sip] draft-khartabil-sip-auth-analysis-00.txt From: Scott Lawrence To: hisham.khartabil@nokia.com Cc: sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179776C@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179776C@esebe019.ntc.nokia.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Message-Id: <1077118172.3739.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 18 Feb 2004 10:29:32 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > realm > > A string to be displayed to users so they know which username and > > password to use. > > I don't think this takes into consideration pre-configuration. That's not really the point; the realm needs to provide enough of a hint for the UA to determine which credentials it should use. Setting up a configuration that requires different credentials for the same realm at different servers is dumb, and not something I think we need to spend much worry on. > > ... This string should contain at least the name of > > the host performing the authentication and might additionally > > indicate the collection of users who might have access. An example > > might be "registered_users@gotham.news.com". > > Can we mandate that for SIP?? I don't think that we can mandate anything that is by nature an administrative decision - we already provide good advice. However, 3261 does say (22.1): o Realm strings MUST be globally unique. It is RECOMMENDED that a realm string contain a hostname or domain name, following the recommendation in Section 3.2.1 of RFC 2617 [17]. > > As a practical matter, if you have the same username and password in > > both domains it doesn't matter - if you don't, then it's an impossibly > > clumsy situation (this problem is part of the reason that we defined > > proxy authentication to by hop-by-hop in HTTP in the first place). > > Perhaps I was not clear in my text. Imagine this scenario: I have cached my credentials for an outbound proxy with realm proxy.nokia.com from an earlier transaction. Now I send a new INVITE routed through the outbound proxy that gets a 407 from a second proxy with the same realm. How do I know if the 407 came from the outbound proxy (the username password might have changed in the meantime) or from the next hop proxy? What difference does it make? You just use the credentials you have in either case, or you fail... As I pointed out, you can tell the difference if the server is using qop. > > If the proxy is using the 2617 version of Digest (with the qop > > attribute) as opposed to the 1867 version, then the UA can tell > > the difference. The message flow looks like this: > > > > UA P1 P2 > > a +------REQ 1--------->| | > > b |<----407(1)----------+ | > > c +------REQ 2 -------->+----REQ 2--------->| > > e |<---407(2)-----------+<-----407(2)-------| > > +------REQ 3--------->+----REQ 3--------->| > > > > a) initial request > > b) challenge from P1, with the qop parameter specified > > c) retried request, with a qop parameter, and therefor also a cnonce > > chosen by the UA; it is passed on (now without > > authentication) to P2 > > d) P2 challenges, also specifying a qop parameter > > P2 challenge is forwarded by P1, with the WWW-Authenticate > > header as provided by P2, but also with an Authentication-Info > > provided by P1. > > > > The UA can recognize that authentication to P1 was successful, because > > P1 returned an Authentication-Info header that contained the cnonce > > and nc values from message c (REQ 2), and a correct response hash to > > show that P1 knows the authentication secret. > > This is not mandated for SIP entities, maybe it aught to be. Actually, it is, but it's the usual unfortunate incorrect intrepretation of SHOULD that is biting us again. RFC 2617 says: qop-options This directive is optional, but is made so only for backward compatibility with RFC 2069 [6]; it SHOULD be used by all implementations compliant with this version of the Digest scheme. Since SIP references only 2617, and backward compatibility with 1867 is not important, all SIP servers should be using qop-options. > > > 10. Authentication-Info > > > > > > RFC 3261 allows the usage of Authentication-Info header. The BNF in > > > RFC 3261 allows multiple authentication-info headers where RFC 2617 > > > allows only one. Is it only the terminating UAS that is allowed to > > > insert this header. If so, why allow multiples to be > > present. If not, > > > how does the UAC know which proxy added this header? It cannot know > > > since there is no parameter indicating so, not even nonce. > > > > As I noted earlier, 2617 allows only one because proxy authentication > > is hop-by-hop, but the cnonce value allows the UA to disambiguate them > > (if they are carefully constructed, but then they should be anyway). > > SIP BNF allows multiples of those headers. Is this a BNF bug? If not, then some Authentication-Info parameters need to be mandated. The BNF is never the last word - the text MUST be read too, and the requirement there is, I think, already clear. -- Scott Lawrence Pingtel Corp. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 10:47:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23216 for ; Wed, 18 Feb 2004 10:47:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTuw-0006Sv-9L for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:47:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFlIxh024843 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:47:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTul-0006Pj-9d; Wed, 18 Feb 2004 10:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTtv-0006Nm-Rc for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:46:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23178 for ; Wed, 18 Feb 2004 10:46:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTtt-0004If-00 for sip@ietf.org; Wed, 18 Feb 2004 10:46:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTtA-0004Dj-00 for sip@ietf.org; Wed, 18 Feb 2004 10:45:29 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AtTsV-00042w-00 for sip@ietf.org; Wed, 18 Feb 2004 10:44:47 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 25529; Wed, 18 Feb 2004 10:45:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F636.0CC72E19" Subject: RE: [Sip] Changing Via In NAT Date: Wed, 18 Feb 2004 10:44:09 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A19E@zoe.office.snowshore.com> Thread-Topic: [Sip] Changing Via In NAT Thread-Index: AcPyZTa8neWQdenzSwinQPVXF1WlrgDymeKg From: "Eric Burger" To: "Anil Bollineni" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F636.0CC72E19 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An ALG is an ALG: a B2BUA. =20 Do whatever you want. It is not subject to standardization. It is not = a good idea. Do so at your own peril. -----Original Message----- From: Anil Bollineni [mailto:ABollineni@netscreen.com] Sent: Friday, February 13, 2004 2:08 PM To: 'sip@ietf.org' Subject: [Sip] Changing Via In NAT Dear All, =20 In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT = traversal. The received and rport parameter are used to send back the = responses correctly. However if we don't use these extensions, and = change the via ip address and port with that of firewall/port then the = SIP responses will come directly to firewall, in that case the firewall = permits the responses. UA1 inside the network sends requests to = firewall/NAT. =20 UA1=20 INVITE sip:user@domain.com SIP/2.0 ----------------> Firewall/NAT = ----------------------------------------------->UA2 Via: SIP/2.0/UDP 10.1.1.1:4540 INVITE = sip:user@domain.com SIP/2.0 =20 Via: SIP/2.0/UDP firewall_ip:5060 = (Maintain mapping)=20 =20 the UA2 will send the responses to firewall/NAT and firewall/NAT will = write back the addresses in Via to original IP/port. I understand from = the draft, if there are no SIP ALG functionality in firewall, then the = extensions are used to make SIP traverse through NAT. However if we = implement SIP ALG in firewall then we can make SIP traverse through NAT. = Can anybody tell that this way is per SIP spec. =20 Thank you, Anil =20 This email contains material that is confidential. The content of this = email is for the sole use of the intended recipient(s). Any review or = distribution by persons other than the intended recipient(s) without the = express permission of NetScreen Technologies, Inc. is strictly = prohibited. If you are not the intended recipient, please contact the = sender and delete/destroy all copies of this email and any related = attachments. NetScreen does not guarantee the accuracy or completeness = of third party materials or information. =20 ------_=_NextPart_001_01C3F636.0CC72E19 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
An ALG=20 is an ALG: a B2BUA.
 
Do=20 whatever you want.  It is not subject to standardization.  It = is not a=20 good idea.  Do so at your own peril.
-----Original Message-----
From: Anil Bollineni=20 [mailto:ABollineni@netscreen.com]
Sent: Friday, February 13, = 2004=20 2:08 PM
To: 'sip@ietf.org'
Subject: [Sip] Changing = Via In=20 NAT

Dear = All,

 

In = draft-ietf-sip-nat-01.txt,=20 there are SIP extensions for NAT traversal. The received and rport = parameter=20 are used to send back the responses correctly. However if we don't use = these=20 extensions, and change the via ip address and port with that of = firewall/port=20 then the SIP responses will come directly to firewall, in that case = the=20 firewall permits the responses. UA1 inside the network sends requests = to=20 firewall/NAT.

 

UA1

INVITE = sip:user@domain.com SIP/2.0=20 --------------=E0=20 Firewall/NAT=20 =             &= nbsp;=20 ---------------------------------------------=E0UA2

Via: SIP/2.0/UDP=20 = 10.1.1.1:4540          =             &= nbsp;  =20 INVITE sip:user@domain.com SIP/2.0=20 =             &= nbsp;           &n= bsp;  =20

Via:=20 SIP/2.0/UDP firewall_ip:5060

           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           =20 (Maintain mapping)

 

the UA2 will send the = responses to=20 firewall/NAT and firewall/NAT will write back the addresses in Via to = original=20 IP/port. I understand from the draft, if there are no SIP ALG = functionality in=20 firewall, then the extensions are used to make SIP traverse through = NAT.=20 However if we implement SIP ALG in firewall then we can make SIP = traverse=20 through NAT. Can anybody tell that this way is per SIP = spec.

 

Thank = you,

Anil

 

This email contains = material that=20 is confidential. The content of this email is for the sole use of the = intended=20 recipient(s). Any review or distribution by persons other than the = intended=20 recipient(s) without the express permission of NetScreen Technologies, = Inc. is=20 strictly prohibited. If you are not the intended recipient, please = contact the=20 sender and delete/destroy all copies of this email and any related=20 attachments. NetScreen does not guarantee the accuracy or completeness = of=20 third party materials or information.

 

------_=_NextPart_001_01C3F636.0CC72E19-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 10:47:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23217 for ; Wed, 18 Feb 2004 10:47:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTuw-0006Su-92 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:47:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFlIdq024844 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:47:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTuj-0006PW-7i; Wed, 18 Feb 2004 10:47:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTtu-0006Nh-F3 for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:46:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23171 for ; Wed, 18 Feb 2004 10:46:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTts-0004IU-00 for sip@ietf.org; Wed, 18 Feb 2004 10:46:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTt8-0004DS-00 for sip@ietf.org; Wed, 18 Feb 2004 10:45:27 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AtTsT-00042w-00 for sip@ietf.org; Wed, 18 Feb 2004 10:44:46 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 25529; Wed, 18 Feb 2004 10:45:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] CallId question Date: Wed, 18 Feb 2004 10:44:09 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A19D@zoe.office.snowshore.com> Thread-Topic: [Sip] CallId question Thread-Index: AcPweESs+VPRa1k1S1mF69deO8TgPgFtkUHQ From: "Eric Burger" To: "Anil Bollineni" , Cc: "Cullen Jennings" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Upon reflection, this is an interesting theoretical problem that = statistically is not a problem. What is a Call-Id? It is an opaque, globally unique string generated by = the UAC. To promote uniqueness, 3261 requires a string identifying the = UAC, either IP address or hostname. Note that NOTHING in SIP places = semantics on the host part of the Call-Id. So, in reality, don't bother to mung the Call-Id. What is the = likelihood of two UAC's having the following properties AT THE SAME = TIME: same randomly generated LHS (unlikely, but possible) same IP address (possible) same destination (very unlikely) IIF all of these conditions are SIMULTANEOUSLY true, then there is a = problem, in that there will be two dialogs with the same dialog = identifier. You've got bigger problems then what to change an IP = address to :-) That said, if the reason you are munging the Call-Id host part is for = network hiding, then you really, really, really should be hacking the = user part, as well. I'll leave the security considerations section as = an exercise for the reader. P.S., this whole thing breaks lots of stuff. I'm sure Henry will revoke = my License to SIP for even explaining some of it :-) -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Tuesday, February 10, 2004 6:34 PM To: Anil Bollineni; sip@ietf.org Subject: Re: [Sip] CallId question The NAT/FW must not go changing this stuff. If it does, a S/MIME signed = sipfrag will fail. There is no need for the NAT to go change call IDs On 2/10/04 12:27 PM, "Anil Bollineni" wrote: Hello, =20 I have a question about CallId. Suppose two UA's generate = callid's putting theire hostnames and send to firewall/NAT. UA1:INVITE CallID: call1@192.10.10.10 UA2: INVITE CallId: call1@192.10.10.12 =20 Because those callid information contain IP addresses, the = firewall/NAT should translate these IP addresses by putting it's own IP = in callId. The callId's are changed to call1@firewall_ip, = call1@firewall_ip. When responses come back from their respective UAS's = the firewall/NAT translates the it's IP address in callId's to their = original IP's. My question is should I change the string "call1" to = something generated by firewall or Is it OK to leave like that. Even = though they have same CallId, the proxy should discriminate the calls by = from-tag, callid, and to-tag. According to Spec, any UA should have a different means of generating = callid's with those of other UA's.=20 =20 Anything to do correctly to the above procedure? =20 Thanks in advance, Anil This email contains material that is confidential. The content of this = email is for the sole use of the intended recipient(s). Any review or = distribution by persons other than the intended recipient(s) without the = express permission of NetScreen Technologies, Inc. is strictly = prohibited. If you are not the intended recipient, please contact the = sender and delete/destroy all copies of this email and any related = attachments. NetScreen does not guarantee the accuracy or completeness = of third party materials or information. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 11:01:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24097 for ; Wed, 18 Feb 2004 11:01:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtU8N-0007lH-BA for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 11:01:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IG1Bq3029834 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 11:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtU8E-0007jf-7u; Wed, 18 Feb 2004 11:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtU8B-0007j0-Av for sip@optimus.ietf.org; Wed, 18 Feb 2004 11:00:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24084 for ; Wed, 18 Feb 2004 11:00:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtU88-0005Ip-00 for sip@ietf.org; Wed, 18 Feb 2004 11:00:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtU7D-0005Fu-00 for sip@ietf.org; Wed, 18 Feb 2004 10:59:59 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AtU6e-0005CL-00 for sip@ietf.org; Wed, 18 Feb 2004 10:59:24 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2004 08:00:27 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1IFwqT4015304; Wed, 18 Feb 2004 10:58:52 -0500 (EST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGD22043; Wed, 18 Feb 2004 10:58:51 -0500 (EST) Message-ID: <40338BBB.4000002@cisco.com> Date: Wed, 18 Feb 2004 10:58:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: Anil Bollineni , sip@ietf.org, Cullen Jennings Subject: Re: [Sip] CallId question References: <4A3384433CE2AB46A63468CB207E209DB1A19D@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree that you shouldn't muck with the call-id, but for different reasons. From 3261: In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA. A UA behind a NAT can't use its IP address in its call-id because that won't be guaranteed to be unique. It might be able to use its DNS name. If it doesn't have one, then it is still obligated to come up with something unique. Otherwise it is just broken. Paul Eric Burger wrote: > Upon reflection, this is an interesting theoretical problem that statistically is not a problem. > > What is a Call-Id? It is an opaque, globally unique string generated by the UAC. To promote uniqueness, 3261 requires a string identifying the UAC, either IP address or hostname. Note that NOTHING in SIP places semantics on the host part of the Call-Id. > > So, in reality, don't bother to mung the Call-Id. What is the likelihood of two UAC's having the following properties AT THE SAME TIME: > same randomly generated LHS (unlikely, but possible) > same IP address (possible) > same destination (very unlikely) > > IIF all of these conditions are SIMULTANEOUSLY true, then there is a problem, in that there will be two dialogs with the same dialog identifier. You've got bigger problems then what to change an IP address to :-) > > > That said, if the reason you are munging the Call-Id host part is for network hiding, then you really, really, really should be hacking the user part, as well. I'll leave the security considerations section as an exercise for the reader. > > P.S., this whole thing breaks lots of stuff. I'm sure Henry will revoke my License to SIP for even explaining some of it :-) > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, February 10, 2004 6:34 PM > To: Anil Bollineni; sip@ietf.org > Subject: Re: [Sip] CallId question > > > > The NAT/FW must not go changing this stuff. If it does, a S/MIME signed sipfrag will fail. There is no need for the NAT to go change call IDs > > > > On 2/10/04 12:27 PM, "Anil Bollineni" wrote: > > > Hello, > > I have a question about CallId. Suppose two UA's generate callid's putting theire hostnames and send to firewall/NAT. > UA1:INVITE > CallID: call1@192.10.10.10 > UA2: INVITE > CallId: call1@192.10.10.12 > > Because those callid information contain IP addresses, the firewall/NAT should translate these IP addresses by putting it's own IP in callId. The callId's are changed to call1@firewall_ip, call1@firewall_ip. When responses come back from their respective UAS's the firewall/NAT translates the it's IP address in callId's to their original IP's. My question is should I change the string "call1" to something generated by firewall or Is it OK to leave like that. Even though they have same CallId, the proxy should discriminate the calls by from-tag, callid, and to-tag. > According to Spec, any UA should have a different means of generating callid's with those of other UA's. > > Anything to do correctly to the above procedure? > > Thanks in advance, > Anil > This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 11:13:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25032 for ; Wed, 18 Feb 2004 11:13:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUJw-0000mN-2c for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 11:13:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IGD8dv002973 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 11:13:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUJo-0000jF-9P; Wed, 18 Feb 2004 11:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUIt-0000fZ-CH for sip@optimus.ietf.org; Wed, 18 Feb 2004 11:12:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24966 for ; Wed, 18 Feb 2004 11:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtUIs-0006TA-00 for sip@ietf.org; Wed, 18 Feb 2004 11:12:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtUI3-0006Nq-00 for sip@ietf.org; Wed, 18 Feb 2004 11:11:12 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AtUHN-0006Fo-00 for sip@ietf.org; Wed, 18 Feb 2004 11:10:29 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 25528; Wed, 18 Feb 2004 11:10:44 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] CallId question Date: Wed, 18 Feb 2004 11:09:59 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A1A0@zoe.office.snowshore.com> Thread-Topic: [Sip] CallId question Thread-Index: AcP2OBzmKMw1rZvCTGeSmHUpdzj38AAAWxKQ From: "Eric Burger" To: "Paul Kyzivat" Cc: "Anil Bollineni" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Good point -- if you are going to be a B2BUA, you have to follow the = *UA* rules, e.g., generate new, unique Call-Id's. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, February 18, 2004 10:59 AM > To: Eric Burger > Cc: Anil Bollineni; sip@ietf.org; Cullen Jennings > Subject: Re: [Sip] CallId question >=20 >=20 > I agree that you shouldn't muck with the call-id, but for different=20 > reasons. From 3261: >=20 > In a new request created by a UAC outside of any dialog,=20 > the Call-ID > header field MUST be selected by the UAC as a globally unique > identifier over space and time unless overridden by=20 > method-specific > behavior. All SIP UAs must have a means to guarantee=20 > that the Call- > ID header fields they produce will not be inadvertently=20 > generated by > any other UA. >=20 > A UA behind a NAT can't use its IP address in its call-id=20 > because that=20 > won't be guaranteed to be unique. It might be able to use its=20 > DNS name.=20 > If it doesn't have one, then it is still obligated to come up with=20 > something unique. Otherwise it is just broken. >=20 > Paul >=20 > Eric Burger wrote: > > Upon reflection, this is an interesting theoretical problem=20 > that statistically is not a problem. > >=20 > > What is a Call-Id? It is an opaque, globally unique string=20 > generated by the UAC. To promote uniqueness, 3261 requires a=20 > string identifying the UAC, either IP address or hostname. =20 > Note that NOTHING in SIP places semantics on the host part of=20 > the Call-Id. > >=20 > > So, in reality, don't bother to mung the Call-Id. What is=20 > the likelihood of two UAC's having the following properties=20 > AT THE SAME TIME: > > same randomly generated LHS (unlikely, but possible) > > same IP address (possible) > > same destination (very unlikely) > >=20 > > IIF all of these conditions are SIMULTANEOUSLY true, then=20 > there is a problem, in that there will be two dialogs with=20 > the same dialog identifier. You've got bigger problems then=20 > what to change an IP address to :-) > >=20 > >=20 > > That said, if the reason you are munging the Call-Id host=20 > part is for network hiding, then you really, really, really=20 > should be hacking the user part, as well. I'll leave the=20 > security considerations section as an exercise for the reader. > >=20 > > P.S., this whole thing breaks lots of stuff. I'm sure=20 > Henry will revoke my License to SIP for even explaining some of it :-) > >=20 > >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Tuesday, February 10, 2004 6:34 PM > > To: Anil Bollineni; sip@ietf.org > > Subject: Re: [Sip] CallId question > >=20 > >=20 > >=20 > > The NAT/FW must not go changing this stuff. If it does, a=20 > S/MIME signed sipfrag will fail. There is no need for the NAT=20 > to go change call IDs > >=20 > >=20 > >=20 > > On 2/10/04 12:27 PM, "Anil Bollineni"=20 > wrote: > >=20 > >=20 > > Hello, > > =20 > > I have a question about CallId. Suppose two=20 > UA's generate callid's putting theire hostnames and send to=20 > firewall/NAT. > > UA1:INVITE > > CallID: call1@192.10.10.10 > > UA2: INVITE > > CallId: call1@192.10.10.12 > > =20 > > Because those callid information contain IP=20 > addresses, the firewall/NAT should translate these IP=20 > addresses by putting it's own IP in callId. The callId's are=20 > changed to call1@firewall_ip, call1@firewall_ip. When=20 > responses come back from their respective UAS's the=20 > firewall/NAT translates the it's IP address in callId's to=20 > their original IP's. My question is should I change the=20 > string "call1" to something generated by firewall or Is it OK=20 > to leave like that. Even though they have same CallId, the=20 > proxy should discriminate the calls by from-tag, callid, and to-tag. > > According to Spec, any UA should have a different means of=20 > generating callid's with those of other UA's.=20 > > =20 > > Anything to do correctly to the above procedure? > > =20 > > Thanks in advance, > > Anil > > This email contains material that is confidential. The=20 > content of this email is for the sole use of the intended=20 > recipient(s). Any review or distribution by persons other=20 > than the intended recipient(s) without the express permission=20 > of NetScreen Technologies, Inc. is strictly prohibited. If=20 > you are not the intended recipient, please contact the sender=20 > and delete/destroy all copies of this email and any related=20 > attachments. NetScreen does not guarantee the accuracy or=20 > completeness of third party materials or information. > >=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 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 15:19:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17244 for ; Wed, 18 Feb 2004 15:19:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYA9-0006MI-GN for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 15:19:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IKJHP9024379 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 15:19:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtY9u-0006FV-9d; Wed, 18 Feb 2004 15:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtY92-000614-SN for sip@optimus.ietf.org; Wed, 18 Feb 2004 15:18:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17090 for ; Wed, 18 Feb 2004 15:18:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtY91-0003Qy-00 for sip@ietf.org; Wed, 18 Feb 2004 15:18:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtY87-0003OF-00 for sip@ietf.org; Wed, 18 Feb 2004 15:17:11 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AtY7b-0003JP-00 for sip@ietf.org; Wed, 18 Feb 2004 15:16:39 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i1IKG6d05691 for ; Wed, 18 Feb 2004 14:16:06 -0600 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Message-Id: <1077135359.2249.102.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 18 Feb 2004 14:15:59 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Moving forward on non-invite issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All - At the request of the chairs, I split the non-invite draft into three parts : - the description of the problems - the things we seem to have consensus to fix now - the things we might do in the future but need to argue over more. The resulting drafts are available in the repository: http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-problems-00.txt http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-actions-00.txt http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-future-00.txt My recommendation is to LC the problems and actions drafts as soon as it is feasible to do so and send them to the IESG. RjS ps - if you prefer reading xml2rfc's html output, you can get that at: http://www.nostrum.com/~rjsparks/draft-sparks-sip-nit-problems-00.html http://www.nostrum.com/~rjsparks/draft-sparks-sip-nit-actions-00.html http://www.nostrum.com/~rjsparks/draft-sparks-sip-nit-future-00.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 15:31:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18371 for ; Wed, 18 Feb 2004 15:31:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYLd-0000Z7-8o for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 15:31:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IKV9cM002167 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 15:31:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYLY-0000X4-15; Wed, 18 Feb 2004 15:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYLN-0000VP-8W for sip@optimus.ietf.org; Wed, 18 Feb 2004 15:30:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18311 for ; Wed, 18 Feb 2004 15:30:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtYLL-0004hs-00 for sip@ietf.org; Wed, 18 Feb 2004 15:30:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtYKa-0004Wv-00 for sip@ietf.org; Wed, 18 Feb 2004 15:30:06 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AtYJO-0004Gc-00 for sip@ietf.org; Wed, 18 Feb 2004 15:28:50 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i1IKRpd05861; Wed, 18 Feb 2004 14:27:51 -0600 Subject: RE: [Sip] CallId question From: Robert Sparks To: Eric Burger Cc: Paul Kyzivat , Anil Bollineni , sip@ietf.org In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A1A0@zoe.office.snowshore.com> References: <4A3384433CE2AB46A63468CB207E209DB1A1A0@zoe.office.snowshore.com> Content-Type: text/plain Message-Id: <1077136065.2249.113.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 18 Feb 2004 14:27:45 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would like to see us revisit the BNF for Call-ID at some point and explicitly make its value a single bundle of opaque bits. It almost is already - it is defined as word @ word (NOT word @ host). There are implementations that have been mislead by the recommendation to use a host for the second word (as a source of probably-unique bits) into _parsing_ that field from received messages as a host (as defined in the BNF in 3261), and rejecting messages (or breaking) when the bits they found didn't line up. I'm willing to bet that a very large subset of the existing implementations in the world would not deal with two "@" signs show up gracefully. (Something to add to the torture tests maybe). We can make this less likely to occur in the future. RjS On Wed, 2004-02-18 at 10:09, Eric Burger wrote: > Good point -- if you are going to be a B2BUA, you have to follow the *UA* rules, e.g., generate new, unique Call-Id's. > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, February 18, 2004 10:59 AM > > To: Eric Burger > > Cc: Anil Bollineni; sip@ietf.org; Cullen Jennings > > Subject: Re: [Sip] CallId question > > > > > > I agree that you shouldn't muck with the call-id, but for different > > reasons. From 3261: > > > > In a new request created by a UAC outside of any dialog, > > the Call-ID > > header field MUST be selected by the UAC as a globally unique > > identifier over space and time unless overridden by > > method-specific > > behavior. All SIP UAs must have a means to guarantee > > that the Call- > > ID header fields they produce will not be inadvertently > > generated by > > any other UA. > > > > A UA behind a NAT can't use its IP address in its call-id > > because that > > won't be guaranteed to be unique. It might be able to use its > > DNS name. > > If it doesn't have one, then it is still obligated to come up with > > something unique. Otherwise it is just broken. > > > > Paul > > > > Eric Burger wrote: > > > Upon reflection, this is an interesting theoretical problem > > that statistically is not a problem. > > > > > > What is a Call-Id? It is an opaque, globally unique string > > generated by the UAC. To promote uniqueness, 3261 requires a > > string identifying the UAC, either IP address or hostname. > > Note that NOTHING in SIP places semantics on the host part of > > the Call-Id. > > > > > > So, in reality, don't bother to mung the Call-Id. What is > > the likelihood of two UAC's having the following properties > > AT THE SAME TIME: > > > same randomly generated LHS (unlikely, but possible) > > > same IP address (possible) > > > same destination (very unlikely) > > > > > > IIF all of these conditions are SIMULTANEOUSLY true, then > > there is a problem, in that there will be two dialogs with > > the same dialog identifier. You've got bigger problems then > > what to change an IP address to :-) > > > > > > > > > That said, if the reason you are munging the Call-Id host > > part is for network hiding, then you really, really, really > > should be hacking the user part, as well. I'll leave the > > security considerations section as an exercise for the reader. > > > > > > P.S., this whole thing breaks lots of stuff. I'm sure > > Henry will revoke my License to SIP for even explaining some of it :-) > > > > > > > > > -----Original Message----- > > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > Sent: Tuesday, February 10, 2004 6:34 PM > > > To: Anil Bollineni; sip@ietf.org > > > Subject: Re: [Sip] CallId question > > > > > > > > > > > > The NAT/FW must not go changing this stuff. If it does, a > > S/MIME signed sipfrag will fail. There is no need for the NAT > > to go change call IDs > > > > > > > > > > > > On 2/10/04 12:27 PM, "Anil Bollineni" > > wrote: > > > > > > > > > Hello, > > > > > > I have a question about CallId. Suppose two > > UA's generate callid's putting theire hostnames and send to > > firewall/NAT. > > > UA1:INVITE > > > CallID: call1@192.10.10.10 > > > UA2: INVITE > > > CallId: call1@192.10.10.12 > > > > > > Because those callid information contain IP > > addresses, the firewall/NAT should translate these IP > > addresses by putting it's own IP in callId. The callId's are > > changed to call1@firewall_ip, call1@firewall_ip. When > > responses come back from their respective UAS's the > > firewall/NAT translates the it's IP address in callId's to > > their original IP's. My question is should I change the > > string "call1" to something generated by firewall or Is it OK > > to leave like that. Even though they have same CallId, the > > proxy should discriminate the calls by from-tag, callid, and to-tag. > > > According to Spec, any UA should have a different means of > > generating callid's with those of other UA's. > > > > > > Anything to do correctly to the above procedure? > > > > > > Thanks in advance, > > > Anil > > > This email contains material that is confidential. The > > content of this email is for the sole use of the intended > > recipient(s). Any review or distribution by persons other > > than the intended recipient(s) without the express permission > > of NetScreen Technologies, Inc. is strictly prohibited. If > > you are not the intended recipient, please contact the sender > > and delete/destroy all copies of this email and any related > > attachments. NetScreen does not guarantee the accuracy or > > completeness of third party materials or information. > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 15:53:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19949 for ; Wed, 18 Feb 2004 15:53:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYgv-0002w1-Nv for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 15:53:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IKr93I011277 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 15:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYgo-0002sE-63; Wed, 18 Feb 2004 15:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYgN-0002qo-0m for sip@optimus.ietf.org; Wed, 18 Feb 2004 15:52:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19861 for ; Wed, 18 Feb 2004 15:52:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtYgL-0006d3-00 for sip@ietf.org; Wed, 18 Feb 2004 15:52:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtYfC-0006XR-00 for sip@ietf.org; Wed, 18 Feb 2004 15:51:23 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1AtYem-0006TR-00 for sip@ietf.org; Wed, 18 Feb 2004 15:50:56 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i1IKo1Dm013542; Wed, 18 Feb 2004 14:50:02 -0600 (CST) Message-ID: <4033CFF8.8050800@alcatel.com> Date: Wed, 18 Feb 2004 14:50:00 -0600 From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org, jmpolk@cisco.com Subject: [Sip] draft-ietf-sip-resource-priority-02 - behavior References: <402FF85F.4020202@cs.columbia.edu> <40325ADF.30508@cisco.com> <4032A0B2.50504@cs.columbia.edu> In-Reply-To: <4032A0B2.50504@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Subsection 4.1 (General Rules) gave an example behavior of a SIP element supporting this specification as: ... "For example, for SUBSCRIBE, a higher-priority request may get preferential treatment if storage or bandwidth for notifications are scarce, possibly displacing a lower-priority subscription." Is this suggesting that resources allocated to a lower priority request can be reclaimed for a higher priority one (say in the case of scarce storage space)? If that is the case, how are the clients of the lower priority request notified of their misfortune? Regards, Alex. Henning Schulzrinne wrote: > >> - Now that Resource-Priority is optional in all requests, shouldn't >> Accept-Resource-Priority be permitted in 420 responses to all the same >> messages? > > > Agreed; except for ACK... > >> >> - Shouldn't the R-P be optional in responses to any request where it was >> permitted? > > > Same quick cut-and-paste error; yes. > >> >> - If A-R-P is mandatory in 417 responses to SUB, NOT, and MSG, shouldn't >> it also be mandatory (rather than optional) in 417 response to INVITE? >> And by logic just above, shouldn't it be mandatory in responses to any >> message where R-P is optional? >> >> - So I think the table probably ought to look like: >> >> Header field where proxy INV ACK CAN BYE REG OPT PRA >> ---------------------------------------------------------------- >> Resource-Priority R amd o o o o o o o >> Resource-Priority 200 - o o o o o o o >> Accept-Resource-Priority 200 - o o o o o o o >> Accept-Resource-Priority 417 - m m m m m m m >> Accept-Resource-Priority 420 - o o o o o o o >> >> Header field where proxy SUB NOT UPD MSG REF INF PUB >> ---------------------------------------------------------------- >> Resource-Priority R amd o o o o o o o >> Resource-Priority 200 - o o o o o o o >> Accept-Resource-Priority 200 - o o o o o o o >> Accept-Resource-Priority 417 - m m m m m m m >> Accept-Resource-Priority 420 - o o o o o o o > > > Yup, minus the responses for ACK. > >> >> In section 4.1, why do you single out INVITE, MESSAGE, UPDATE, SUBSCRIBE >> and NOTIFY, but omit ACK and PRACK? If INVITE is important, then ACK and >> PRACK must be important too. This probably isn't an issue in a UAS, >> because it considers those to be part of the INVITE. But it could make a >> difference in a proxy. >> >> Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 16:00:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20345 for ; Wed, 18 Feb 2004 16:00:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYnk-0003Xe-QU for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 16:00:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IL0CTi013605 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 16:00:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYne-0003Vl-HK; Wed, 18 Feb 2004 16:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYmo-0003TG-Ff for sip@optimus.ietf.org; Wed, 18 Feb 2004 15:59:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20239 for ; Wed, 18 Feb 2004 15:59:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtYmm-00075C-00 for sip@ietf.org; Wed, 18 Feb 2004 15:59:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtYlp-00072h-00 for sip@ietf.org; Wed, 18 Feb 2004 15:58:14 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AtYlX-00070d-00 for sip@ietf.org; Wed, 18 Feb 2004 15:57:55 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1IKvNYK022218; Wed, 18 Feb 2004 15:57:23 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1IKvNH28482; Wed, 18 Feb 2004 15:57:23 -0500 Message-ID: <4033D1B3.2080401@cs.columbia.edu> Date: Wed, 18 Feb 2004 15:57:23 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: sip@ietf.org, jmpolk@cisco.com Subject: Re: [Sip] draft-ietf-sip-resource-priority-02 - behavior References: <402FF85F.4020202@cs.columbia.edu> <40325ADF.30508@cisco.com> <4032A0B2.50504@cs.columbia.edu> <4033CFF8.8050800@alcatel.com> In-Reply-To: <4033CFF8.8050800@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit SUBSCRIBE is never a guarantee or contract of delivery. The notifier can decide, for any reason whatsoever, to stop delivering notifications at any time. This is just one more, along with "I don't feel like it any more". It's unfortunate, but priority always involves stiffing the little guy in some way. (The more likely behavior is that a system that is bandwidth-constrained might prioritize notifications resulting from a PUBLISH. It simply sends notifications in order of priority until the next PUBLISH arrives; the ones low on the totem pole might never get notified.) Alex Audu wrote: > Subsection 4.1 (General Rules) gave an example behavior of a SIP > element supporting this > specification as: > > ... "For example, for SUBSCRIBE, a higher-priority request > may get preferential treatment if storage or bandwidth for > notifications are scarce, possibly displacing a lower-priority > subscription." > > Is this suggesting that resources allocated to a lower priority request > can be reclaimed for a higher priority one (say in the case of scarce > storage space)? If that is the case, how are the clients of the lower > priority request notified of their misfortune? > > Regards, > Alex. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 16:16:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21153 for ; Wed, 18 Feb 2004 16:16:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ3E-0005qI-Au for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 16:16:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ILGCVF022456 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 16:16:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ34-0005l4-A0; Wed, 18 Feb 2004 16:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZ2r-0005ig-5R for sip@optimus.ietf.org; Wed, 18 Feb 2004 16:15:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21014 for ; Wed, 18 Feb 2004 16:15:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZ2p-0000IR-00 for sip@ietf.org; Wed, 18 Feb 2004 16:15:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZ1q-00008m-00 for sip@ietf.org; Wed, 18 Feb 2004 16:14:47 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AtZ0u-00001o-00 for sip@ietf.org; Wed, 18 Feb 2004 16:13:48 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 10736; Wed, 18 Feb 2004 16:14:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] CallId question Date: Wed, 18 Feb 2004 16:13:17 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A1AA@zoe.office.snowshore.com> Thread-Topic: [Sip] CallId question Thread-Index: AcP2XbNm60e0A+AeTAKXhuGCuTTjyQABTBdA From: "Eric Burger" To: "Robert Sparks" Cc: "Paul Kyzivat" , "Anil Bollineni" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I concur (make it token). > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, February 18, 2004 3:28 PM > To: Eric Burger > Cc: Paul Kyzivat; Anil Bollineni; sip@ietf.org > Subject: RE: [Sip] CallId question >=20 >=20 > I would like to see us revisit the BNF for Call-ID at > some point and explicitly make its value a single bundle > of opaque bits. >=20 > It almost is already - it is defined as word @ word > (NOT word @ host).=20 >=20 > There are implementations that have been mislead by > the recommendation to use a host for the second > word (as a source of probably-unique bits) into > _parsing_ that field from received messages as=20 > a host (as defined in the BNF in 3261), and=20 > rejecting messages (or breaking) when the bits > they found didn't line up. >=20 > I'm willing to bet that a very large subset of > the existing implementations in the world would > not deal with two "@" signs show up gracefully. > (Something to add to the torture tests maybe). >=20 > We can make this less likely to occur in the future. >=20 > RjS >=20 > On Wed, 2004-02-18 at 10:09, Eric Burger wrote: > > Good point -- if you are going to be a B2BUA, you have to=20 > follow the *UA* rules, e.g., generate new, unique Call-Id's. > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Wednesday, February 18, 2004 10:59 AM > > > To: Eric Burger > > > Cc: Anil Bollineni; sip@ietf.org; Cullen Jennings > > > Subject: Re: [Sip] CallId question > > >=20 > > >=20 > > > I agree that you shouldn't muck with the call-id, but for=20 > different=20 > > > reasons. From 3261: > > >=20 > > > In a new request created by a UAC outside of any dialog,=20 > > > the Call-ID > > > header field MUST be selected by the UAC as a globally unique > > > identifier over space and time unless overridden by=20 > > > method-specific > > > behavior. All SIP UAs must have a means to guarantee=20 > > > that the Call- > > > ID header fields they produce will not be inadvertently=20 > > > generated by > > > any other UA. > > >=20 > > > A UA behind a NAT can't use its IP address in its call-id=20 > > > because that=20 > > > won't be guaranteed to be unique. It might be able to use its=20 > > > DNS name.=20 > > > If it doesn't have one, then it is still obligated to=20 > come up with=20 > > > something unique. Otherwise it is just broken. > > >=20 > > > Paul > > >=20 > > > Eric Burger wrote: > > > > Upon reflection, this is an interesting theoretical problem=20 > > > that statistically is not a problem. > > > >=20 > > > > What is a Call-Id? It is an opaque, globally unique string=20 > > > generated by the UAC. To promote uniqueness, 3261 requires a=20 > > > string identifying the UAC, either IP address or hostname. =20 > > > Note that NOTHING in SIP places semantics on the host part of=20 > > > the Call-Id. > > > >=20 > > > > So, in reality, don't bother to mung the Call-Id. What is=20 > > > the likelihood of two UAC's having the following properties=20 > > > AT THE SAME TIME: > > > > same randomly generated LHS (unlikely, but possible) > > > > same IP address (possible) > > > > same destination (very unlikely) > > > >=20 > > > > IIF all of these conditions are SIMULTANEOUSLY true, then=20 > > > there is a problem, in that there will be two dialogs with=20 > > > the same dialog identifier. You've got bigger problems then=20 > > > what to change an IP address to :-) > > > >=20 > > > >=20 > > > > That said, if the reason you are munging the Call-Id host=20 > > > part is for network hiding, then you really, really, really=20 > > > should be hacking the user part, as well. I'll leave the=20 > > > security considerations section as an exercise for the reader. > > > >=20 > > > > P.S., this whole thing breaks lots of stuff. I'm sure=20 > > > Henry will revoke my License to SIP for even explaining=20 > some of it :-) > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > > Sent: Tuesday, February 10, 2004 6:34 PM > > > > To: Anil Bollineni; sip@ietf.org > > > > Subject: Re: [Sip] CallId question > > > >=20 > > > >=20 > > > >=20 > > > > The NAT/FW must not go changing this stuff. If it does, a=20 > > > S/MIME signed sipfrag will fail. There is no need for the NAT=20 > > > to go change call IDs > > > >=20 > > > >=20 > > > >=20 > > > > On 2/10/04 12:27 PM, "Anil Bollineni"=20 > > > wrote: > > > >=20 > > > >=20 > > > > Hello, > > > > =20 > > > > I have a question about CallId. Suppose two=20 > > > UA's generate callid's putting theire hostnames and send to=20 > > > firewall/NAT. > > > > UA1:INVITE > > > > CallID: call1@192.10.10.10 > > > > UA2: INVITE > > > > CallId: call1@192.10.10.12 > > > > =20 > > > > Because those callid information contain IP=20 > > > addresses, the firewall/NAT should translate these IP=20 > > > addresses by putting it's own IP in callId. The callId's are=20 > > > changed to call1@firewall_ip, call1@firewall_ip. When=20 > > > responses come back from their respective UAS's the=20 > > > firewall/NAT translates the it's IP address in callId's to=20 > > > their original IP's. My question is should I change the=20 > > > string "call1" to something generated by firewall or Is it OK=20 > > > to leave like that. Even though they have same CallId, the=20 > > > proxy should discriminate the calls by from-tag, callid,=20 > and to-tag. > > > > According to Spec, any UA should have a different means of=20 > > > generating callid's with those of other UA's.=20 > > > > =20 > > > > Anything to do correctly to the above procedure? > > > > =20 > > > > Thanks in advance, > > > > Anil > > > > This email contains material that is confidential. The=20 > > > content of this email is for the sole use of the intended=20 > > > recipient(s). Any review or distribution by persons other=20 > > > than the intended recipient(s) without the express permission=20 > > > of NetScreen Technologies, Inc. is strictly prohibited. If=20 > > > you are not the intended recipient, please contact the sender=20 > > > and delete/destroy all copies of this email and any related=20 > > > attachments. NetScreen does not guarantee the accuracy or=20 > > > completeness of third party materials or information. > > > >=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=20 > current sip > > > > Use sipping@ietf.org for new developments on the=20 > application of sip > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 16:52:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24479 for ; Wed, 18 Feb 2004 16:52:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZc4-0001hI-Uf for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 16:52:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ILqC8K006463 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 16:52:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZbv-0001cy-4Y; Wed, 18 Feb 2004 16:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZbT-0001aw-HS for sip@optimus.ietf.org; Wed, 18 Feb 2004 16:51:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24419 for ; Wed, 18 Feb 2004 16:51:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZbR-0003N2-00 for sip@ietf.org; Wed, 18 Feb 2004 16:51:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZaU-0003LN-00 for sip@ietf.org; Wed, 18 Feb 2004 16:50:35 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtZZj-0003JC-00 for sip@ietf.org; Wed, 18 Feb 2004 16:49:48 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2004 13:58:17 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1ILnFuA010501; Wed, 18 Feb 2004 13:49:15 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGD56584; Wed, 18 Feb 2004 16:49:14 -0500 (EST) Message-ID: <4033DDDA.6000606@cisco.com> Date: Wed, 18 Feb 2004 16:49:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: Robert Sparks , Anil Bollineni , sip@ietf.org Subject: Re: [Sip] CallId question References: <4A3384433CE2AB46A63468CB207E209DB1A1AA@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eric, You can't make it a token an remain backward compatible with 3261. I support tightening up the semantics. But you can't just say it must be a globally unique value in space and time without giving some guidance on how to partition the namespace so that developers don't pick conflicting techniques. Even changing to word@host would be slightly incompatible. But perhaps it could be specified that the form word@host should not be used unless the application generating the callid can assure that no other entity is using the same value of host to generate callids. Paul Eric Burger wrote: > I concur (make it token). > > >>-----Original Message----- >>From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >>Sent: Wednesday, February 18, 2004 3:28 PM >>To: Eric Burger >>Cc: Paul Kyzivat; Anil Bollineni; sip@ietf.org >>Subject: RE: [Sip] CallId question >> >> >>I would like to see us revisit the BNF for Call-ID at >>some point and explicitly make its value a single bundle >>of opaque bits. >> >>It almost is already - it is defined as word @ word >>(NOT word @ host). >> >>There are implementations that have been mislead by >>the recommendation to use a host for the second >>word (as a source of probably-unique bits) into >>_parsing_ that field from received messages as >>a host (as defined in the BNF in 3261), and >>rejecting messages (or breaking) when the bits >>they found didn't line up. >> >>I'm willing to bet that a very large subset of >>the existing implementations in the world would >>not deal with two "@" signs show up gracefully. >>(Something to add to the torture tests maybe). >> >>We can make this less likely to occur in the future. >> >>RjS >> >>On Wed, 2004-02-18 at 10:09, Eric Burger wrote: >> >>>Good point -- if you are going to be a B2BUA, you have to >> >>follow the *UA* rules, e.g., generate new, unique Call-Id's. >> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: Wednesday, February 18, 2004 10:59 AM >>>>To: Eric Burger >>>>Cc: Anil Bollineni; sip@ietf.org; Cullen Jennings >>>>Subject: Re: [Sip] CallId question >>>> >>>> >>>>I agree that you shouldn't muck with the call-id, but for >>> >>different >> >>>>reasons. From 3261: >>>> >>>> In a new request created by a UAC outside of any dialog, >>>>the Call-ID >>>> header field MUST be selected by the UAC as a globally unique >>>> identifier over space and time unless overridden by >>>>method-specific >>>> behavior. All SIP UAs must have a means to guarantee >>>>that the Call- >>>> ID header fields they produce will not be inadvertently >>>>generated by >>>> any other UA. >>>> >>>>A UA behind a NAT can't use its IP address in its call-id >>>>because that >>>>won't be guaranteed to be unique. It might be able to use its >>>>DNS name. >>>>If it doesn't have one, then it is still obligated to >>> >>come up with >> >>>>something unique. Otherwise it is just broken. >>>> >>>> Paul >>>> >>>>Eric Burger wrote: >>>> >>>>>Upon reflection, this is an interesting theoretical problem >>>> >>>>that statistically is not a problem. >>>> >>>>>What is a Call-Id? It is an opaque, globally unique string >>>> >>>>generated by the UAC. To promote uniqueness, 3261 requires a >>>>string identifying the UAC, either IP address or hostname. >>>>Note that NOTHING in SIP places semantics on the host part of >>>>the Call-Id. >>>> >>>>>So, in reality, don't bother to mung the Call-Id. What is >>>> >>>>the likelihood of two UAC's having the following properties >>>>AT THE SAME TIME: >>>> >>>>> same randomly generated LHS (unlikely, but possible) >>>>> same IP address (possible) >>>>> same destination (very unlikely) >>>>> >>>>>IIF all of these conditions are SIMULTANEOUSLY true, then >>>> >>>>there is a problem, in that there will be two dialogs with >>>>the same dialog identifier. You've got bigger problems then >>>>what to change an IP address to :-) >>>> >>>>> >>>>>That said, if the reason you are munging the Call-Id host >>>> >>>>part is for network hiding, then you really, really, really >>>>should be hacking the user part, as well. I'll leave the >>>>security considerations section as an exercise for the reader. >>>> >>>>>P.S., this whole thing breaks lots of stuff. I'm sure >>>> >>>>Henry will revoke my License to SIP for even explaining >>> >>some of it :-) >> >>>>> >>>>>-----Original Message----- >>>>>From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>Sent: Tuesday, February 10, 2004 6:34 PM >>>>>To: Anil Bollineni; sip@ietf.org >>>>>Subject: Re: [Sip] CallId question >>>>> >>>>> >>>>> >>>>>The NAT/FW must not go changing this stuff. If it does, a >>>> >>>>S/MIME signed sipfrag will fail. There is no need for the NAT >>>>to go change call IDs >>>> >>>>> >>>>> >>>>>On 2/10/04 12:27 PM, "Anil Bollineni" >>>> >>>> wrote: >>>> >>>>> >>>>>Hello, >>>>> >>>>> I have a question about CallId. Suppose two >>>> >>>>UA's generate callid's putting theire hostnames and send to >>>>firewall/NAT. >>>> >>>>> UA1:INVITE >>>>> CallID: call1@192.10.10.10 >>>>> UA2: INVITE >>>>> CallId: call1@192.10.10.12 >>>>> >>>>> Because those callid information contain IP >>>> >>>>addresses, the firewall/NAT should translate these IP >>>>addresses by putting it's own IP in callId. The callId's are >>>>changed to call1@firewall_ip, call1@firewall_ip. When >>>>responses come back from their respective UAS's the >>>>firewall/NAT translates the it's IP address in callId's to >>>>their original IP's. My question is should I change the >>>>string "call1" to something generated by firewall or Is it OK >>>>to leave like that. Even though they have same CallId, the >>>>proxy should discriminate the calls by from-tag, callid, >>> >>and to-tag. >> >>>>>According to Spec, any UA should have a different means of >>>> >>>>generating callid's with those of other UA's. >>>> >>>>> >>>>>Anything to do correctly to the above procedure? >>>>> >>>>>Thanks in advance, >>>>>Anil >>>>>This email contains material that is confidential. The >>>> >>>>content of this email is for the sole use of the intended >>>>recipient(s). Any review or distribution by persons other >>>>than the intended recipient(s) without the express permission >>>>of NetScreen Technologies, Inc. is strictly prohibited. If >>>>you are not the intended recipient, please contact the sender >>>>and delete/destroy all copies of this email and any related >>>>attachments. NetScreen does not guarantee the accuracy or >>>>completeness of third party materials or information. >>>> >>>>> >>>>>_______________________________________________ >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>This list is for NEW development of the core SIP Protocol >>>>>Use sip-implementors@cs.columbia.edu for questions on >>>> >>current sip >> >>>>>Use sipping@ietf.org for new developments on the >>>> >>application of sip >> >>>> >>>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >> >> >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 16:56:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24621 for ; Wed, 18 Feb 2004 16:56:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZfq-0002EZ-2r for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 16:56:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ILu5UM008544 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 16:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZfm-00027M-NV; Wed, 18 Feb 2004 16:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZfQ-00024s-Ox for sip@optimus.ietf.org; Wed, 18 Feb 2004 16:55:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24597 for ; Wed, 18 Feb 2004 16:55:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZfO-0003a6-00 for sip@ietf.org; Wed, 18 Feb 2004 16:55:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZeT-0003WM-00 for sip@ietf.org; Wed, 18 Feb 2004 16:54:42 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtZdX-0003Rg-00 for sip@ietf.org; Wed, 18 Feb 2004 16:53:43 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2004 14:02:54 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1ILrBuA014890; Wed, 18 Feb 2004 13:53:12 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQK14768; Wed, 18 Feb 2004 13:52:47 -0800 (PST) In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A19E@zoe.office.snowshore.com> References: <4A3384433CE2AB46A63468CB207E209DB1A19E@zoe.office.snowshore.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/alternative; boundary=Apple-Mail-25-49748451 Message-Id: Cc: "Anil Bollineni" , From: Rohan Mahy Subject: Re: [Sip] Changing Via In NAT Date: Wed, 18 Feb 2004 13:53:16 -0800 To: "Eric Burger" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-25-49748451 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable There is one critical difference between an ALG and a SIP proxy or =20 B2BUA. ALGs don't insert Via headers, Contact, Record-Route, Route, etc.. =20 They just rewrite stuff going by on the wire, assuming that packets =20 will happen to go through this particular firewall of NAT on their way =20= to the "outside". SIP intermediaries insert some sort of SIP identifier so that requests =20= and responses get routed to them. In this way, ALGs are much, much worse. thanks, -rohan On Feb 18, 2004, at 7:44 AM, Eric Burger wrote: > An ALG is an ALG: a B2BUA. > =A0 > Do whatever you want.=A0 It is not subject to standardization.=A0 It = is =20 > not a good idea.=A0 Do so at your own peril. > -----Original Message----- > From: Anil Bollineni [mailto:ABollineni@netscreen.com] > Sent: Friday, February 13, 2004 2:08 PM > To: 'sip@ietf.org' > Subject: [Sip] Changing Via In NAT > > > Dear All, > > =A0 > > In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT =20 > traversal. The received and rport parameter are used to send back the =20= > responses correctly. However if we don't use these extensions, and =20 > change the via ip address and port with that of firewall/port then the = =20 > SIP responses will come directly to firewall, in that case the =20 > firewall permits the responses. UA1 inside the network sends requests =20= > to firewall/NAT. > > =A0 > > UA1 > > INVITE sip:user@domain.com SIP/2.0 --------------=E0 Firewall/NAT =20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ---------------------------------------------=E0UA2 > > Via: SIP/2.0/UDP 10.1.1.1:4540=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 INVITE =20 > sip:user@domain.com SIP/2.0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > > Via: SIP/2.0/UDP firewall_ip:5060 > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 > (Maintain mapping) > > =A0 > > the UA2 will send the responses to firewall/NAT and firewall/NAT will =20= > write back the addresses in Via to original IP/port. I understand from = =20 > the draft, if there are no SIP ALG functionality in firewall, then the = =20 > extensions are used to make SIP traverse through NAT. However if we =20= > implement SIP ALG in firewall then we can make SIP traverse through =20= > NAT. Can anybody tell that this way is per SIP spec. > > =A0 > > Thank you, > > Anil > > =A0 > > This email contains material that is confidential. The content of this = =20 > email is for the sole use of the intended recipient(s). Any review or =20= > distribution by persons other than the intended recipient(s) without =20= > the express permission of NetScreen Technologies, Inc. is strictly =20 > prohibited. If you are not the intended recipient, please contact the =20= > sender and delete/destroy all copies of this email and any related =20 > attachments. NetScreen does not guarantee the accuracy or completeness = =20 > of third party materials or information. > > =A0 --Apple-Mail-25-49748451 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is one critical difference between an ALG and a SIP proxy or B2BUA. ALGs don't insert Via headers, Contact, Record-Route, Route, etc..=20 They just rewrite stuff going by on the wire, assuming that packets will happen to go through this particular firewall of NAT on their way to the "outside". SIP intermediaries insert some sort of SIP identifier so that requests and responses get routed to them. In this way, ALGs are much, much worse. thanks, -rohan On Feb 18, 2004, at 7:44 AM, Eric Burger wrote: = Arial0000,0000,FFFFAn ALG is an ALG: a B2BUA. =A0 = Arial0000,0000,FFFFDo whatever you want.=A0 It is not subject to standardization.=A0 It is not = a good idea.=A0 Do so at your own peril. Tahoma-----Original = Message----- = TahomaFrom:Tahoma Anil Bollineni [mailto:ABollineni@netscreen.com] = TahomaSent:Tahoma Friday, February 13, 2004 2:08 PM = TahomaTo:= Tahoma 'sip@ietf.org' = TahomaSubject:Tahoma [Sip] Changing Via In NAT ArialDear = All, Times New = Roman=A0 ArialIn draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT traversal. The received and rport parameter are used to send back the responses correctly. However if we don't use these extensions, and change the via ip address and port with that of firewall/port then the SIP responses will come directly to firewall, in that case the firewall permits the responses. UA1 inside the network sends requests to firewall/NAT. Times New = Roman=A0 = ArialUA1 Arial INVITE sip:user@domain.com SIP/2.0 = --------------=E0= Arial Firewall/NAT =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ---------------------------------------------<= x-tad-bigger>=E0ArialUA2 ArialVia: SIP/2.0/UDP 10.1.1.1:4540=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 INVITE sip:user@domain.com SIP/2.0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Arial Via: SIP/2.0/UDP firewall_ip:5060 = Arial=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (Maintain mapping) Arial Times New = Roman=A0 Arialthe UA2 will send the responses to firewall/NAT and firewall/NAT will write back the addresses in Via to original IP/port. I understand from the draft, if there are no SIP ALG functionality in firewall, then the extensions are used to make SIP traverse through NAT. However if we implement SIP ALG in firewall then we can make SIP traverse through NAT. Can anybody tell that this way is per SIP spec. Times New = Roman=A0 ArialThank = you, = ArialAnil Times New = Roman=A0 ArialThis email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. Times New = Roman=A0 = --Apple-Mail-25-49748451-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 17:32:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26897 for ; Wed, 18 Feb 2004 17:32:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaEp-00068C-Fm for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 17:32:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IMWFee023567 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 17:32:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaEc-000663-Ja; Wed, 18 Feb 2004 17:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaEF-00065V-2e for sip@optimus.ietf.org; Wed, 18 Feb 2004 17:31:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26872 for ; Wed, 18 Feb 2004 17:31:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtaEC-0005x7-00 for sip@ietf.org; Wed, 18 Feb 2004 17:31:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtaDH-0005w3-00 for sip@ietf.org; Wed, 18 Feb 2004 17:30:40 -0500 Received: from [63.126.135.16] (helo=mail1.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AtaCa-0005tV-00 for sip@ietf.org; Wed, 18 Feb 2004 17:29:56 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i1IMTJTl013414; Wed, 18 Feb 2004 14:29:19 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Feb 2004 14:29:19 -0800 Message-ID: <017B1BB60535DF4285666089FA048AC20172EFED@SONOMA.netscreen.com> From: Anil Bollineni To: "'Rohan Mahy'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Changing Via In NAT Date: Wed, 18 Feb 2004 14:29:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F66E.A60AD8B0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F66E.A60AD8B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rohan, =20 Thanks for pointing me to right RFC. I am thinking that how = many UA's correctly support this STUN protocol. I am thinking that we need = to add SIP ALG in NAT that if we want to support UA's that don't support any = SIP NAT extensions and STUN protocol. I thought that this supporting all = SIP aware functionality in ALG is difficult as changes made to SIP protocol = need to accommodate in SIP ALG.=20 =20 Thanks, Anil =20 This email contains material that is confidential. The content of this = email is for the sole use of the intended recipient(s). Any review or = distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If = you are not the intended recipient, please contact the sender and = delete/destroy all copies of this email and any related attachments. NetScreen does = not guarantee the accuracy or completeness of third party materials or information. -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com]=20 Sent: Wednesday, February 18, 2004 4:46 AM To: Anil Bollineni Cc: 'sip@ietf.org' Subject: Re: [Sip] Changing Via In NAT =20 =20 On Feb 13, 2004, at 11:07 AM, Anil Bollineni wrote:=20 =20 Dear All,=20 =20 In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT = traversal. The received and rport parameter are used to send back the responses correctly.=20 =20 This is an extremely old reference. The name was changed to draft-ietf-sip-symmetric-response, and is now published as RFC 3581.=20 =20 However if we don't use these extensions, and change the via ip address = and port with that of firewall/port then the SIP responses will come = directly to firewall, in that case the firewall permits the responses. UA1 inside = the network sends requests to firewall/NAT.=20 =20 UA1=20 =20 INVITE sip:user@domain.com SIP/2.0 --------------=E0 Firewall/NAT ---------------------------------------------=E0UA2=20 =20 Via: SIP/2.0/UDP 10.1.1.1:4540 INVITE sip:user@domain.com SIP/2.0 =20 =20 Via: SIP/2.0/UDP firewall_ip:5060=20 =20 =20 (Maintain mapping)=20 =20 the UA2 will send the responses to firewall/NAT and firewall/NAT will = write back the addresses in Via to original IP/port. I understand from the = draft, if there are no SIP ALG functionality in firewall, then the extensions = are used to make SIP traverse through NAT. However if we implement SIP ALG = in firewall then we can make SIP traverse through NAT. Can anybody tell = that this way is per SIP spec.=20 =20 The experience of the working group has shown that implementing a SIP = ALG in a firewall is "a bad thing". I have personal experience with the = failings of SIP ALGs at my own company, not the least of which is that they don't = work at all when SIP is integrity-protected using TLS.=20 =20 Many UAs now support RFC 3581 and can use the STUN protocol to get = valid public addresses and ports to advertise in SDP for their RTP traffic. = This has been relatively painless compared to working with the shortcomings = of ALGs.=20 =20 thanks,=20 -rohan=20 =20 ------_=_NextPart_001_01C3F66E.A60AD8B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Rohan,

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Thanks for pointing me to right RFC. I am thinking that how many UA's correctly support this STUN = protocol. I am thinking that we need to add SIP ALG in NAT that if we want to = support UA's that don't support any SIP NAT extensions and STUN protocol. I thought that this supporting all SIP aware functionality in ALG is difficult as = changes made to SIP protocol need to accommodate in SIP ALG. =

 

Thanks,

Anil

 

This email contains material that is confidential. = The content of this email is for the sole use of the intended recipient(s). = Any review or distribution by persons other than the intended recipient(s) = without the express permission of NetScreen Technologies, Inc. is strictly = prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. = NetScreen does not guarantee the accuracy or completeness of third party = materials or information.

-----Original = Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Wednesday, = February 18, 2004 4:46 AM
To: Anil = Bollineni
Cc: 'sip@ietf.org= '
Subject: Re: [Sip] = Changing Via In NAT

 

 

On Feb 13, 2004, at 11:07 AM, Anil Bollineni = wrote:

 

Dear All,

 

In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT traversal. The received and rport parameter are used = to send back the responses correctly.

 

This is an extremely old reference. The name = was changed to draft-ietf-sip-symmetric-response, and is now published as = RFC 3581.

 

However if we don't use these extensions, and = change the via ip address and port with that of firewall/port then the SIP = responses will come directly to firewall, in that case the firewall permits the responses. UA1 inside the network sends requests to = firewall/NAT.

 

UA1

 

INVITE sip:user@domain.com SIP/2.0 = --------------=E0 Firewall/NAT             =   ---------------------------------------------=E0UA2

 

Via: SIP/2.0/UDP 10.1.1.1:4540          = ;            = ;    INVITE sip:user@domain.com SIP/2.0 =             =             =    

 

Via: SIP/2.0/UDP = firewall_ip:5060

 

       &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;    (Maintain mapping)

 

the UA2 will send the responses to = firewall/NAT and firewall/NAT will write back the addresses in Via to original IP/port. = I understand from the draft, if there are no SIP ALG functionality in = firewall, then the extensions are used to make SIP traverse through NAT. However = if we implement SIP ALG in firewall then we can make SIP traverse through = NAT. Can anybody tell that this way is per SIP spec.

 

The experience of the working group has = shown that implementing a SIP ALG in a firewall is "a bad thing". I have personal experience with the failings of SIP ALGs at my own company, = not the least of which is that they don't work at all when SIP is = integrity-protected using TLS.

 

Many UAs now support RFC 3581 and can use = the STUN protocol to get valid public addresses and ports to advertise in SDP = for their RTP traffic. This has been relatively painless compared to working with = the shortcomings of ALGs.

 

thanks,

-rohan

 

------_=_NextPart_001_01C3F66E.A60AD8B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 18 18:13:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29999 for ; Wed, 18 Feb 2004 18:13:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtasN-0007HS-Oq for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 18:13:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IND7H5027960 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 18:13:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtasH-0007EB-Bt; Wed, 18 Feb 2004 18:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atas1-0007Al-SG for sip@optimus.ietf.org; Wed, 18 Feb 2004 18:12:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29936 for ; Wed, 18 Feb 2004 18:12:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atarz-0000qS-00 for sip@ietf.org; Wed, 18 Feb 2004 18:12:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atar2-0000oD-00 for sip@ietf.org; Wed, 18 Feb 2004 18:11:45 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AtaqB-0000kM-00 for sip@ietf.org; Wed, 18 Feb 2004 18:10:51 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i1INALd08555; Wed, 18 Feb 2004 17:10:21 -0600 From: Robert Sparks To: sip@ietf.org, sip-implementors@ietf.org Content-Type: text/plain Message-Id: <1077145813.2249.163.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 18 Feb 2004 17:10:13 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,WORK_AT_HOME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Summary of observations from SIPIT 14 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit SIPIT 14 took place Feb 9 to 13, 2004 in Mandelieu, France. The event was hosted by ETSI Plugtests. If you aren't familiar with SIPITs, please review the information at http://www.sipit.net . This is a summary of what I observed: There were roughly 128 attendees from 55 organizations. Participants came from the US, Canada, Israel, Japan, Taiwan, France, Germany, Belgium, UK, Turkey, India, Sweden, Finland, and Norway. Roughly 1/5 of the implementations had not been to a previous SIPIT. Startup at this event was more stressful than normal - we had a shipment of switches go awry and there was a good deal of last minute creative network engineering, leading to a good deal of support work on Monday. We resolved that by Monday night and had a solid network for the remainder of the event. Still - the infrastructure volunteers were up ridiculous hours the whole week. I have plans to improve that. We started training a "loading crew" to help with future events, and we are refining our kit and our requirements on the host. If you're a regular SIPIT attendee and are willing to help, please send me a note. Overall, the state of interoperability at the event continues to improve. The biggest strides between this event and the last were around correct support for TLS. The biggest weakness continues to be proper construction of offers and answers. Folks know where to put their SDP, but can't agree what to put in it. The offer-answer-examples draft is helping, but we may need to do more. We found a few places to work on clarifying the specification: - The merge detection language covers initial requests, but not in-dialog requests. We don't expect in-dialog requests to diverge and merge, but there are edge cases where it can happen (such as through NAPTR/SRV failover). This became particularly important when elements "optimized" failover, shorting over to the next SRV record after 4 seconds of no response instead of waiting for a full transaction timeout. - We inherit HEXDIG from 2234 (I think, this isn't super clear). That RFC allows only uppercase letters for hex digits. We defined LHEX to deal with that for digest challenges (where we allow only lower case in the syntax). But - ipv6 addresses can realistically take either case. We need something new. - There were several UAs that puked on Call-IDs that had an @ sign in them where the stuff after the @ sign was a quoted ([]) IPv6 address (which happened when a request went through a v6tov4 gateway). We really should deprecate the '@' form from the BNF, replacing the whole header field value with an opaque bitstring. - It was not clear to all implementors that an in-dialog REFER was a target refresh request (hence MUST have a single Contact HFV. Bug 750 captures this. - An optimization question came up: If you parallel fork over UDP to n legs, leg 1 answers, leg 2-n have not yet responded (at all, so you can't send a CANCEL). Do you still have to continue retransmitting the request on legs 2-n, or can you squelch them? (You would have to keep the transaction around to deal with a response if it came, of course). - Empty reason phrases broke lots of people - we will add these to the torture-test draft. Note that the BNF still requires a space after the Status-Code even if the phrase is empty. - We had another example of Table 2 causing more confusion than not - a new registrar decided it was ok not to include the current bindings in REGISTER responses since table 2 listed Contact as optional in that context. I was able to interview 46 of the 55 organizations. Here are some observations from those notes - treat all the numbers as approximations. - 20 did not support TLS, but 5 of those plan to by the next event. (So we're running at about half the implementations supporting TLS.) All but one implementation was built on top of openssl. Only 6 implementations supported sips: - We had two implementations of event-lists (and they interoperated) - Only four implementations did not support loose-routing. - around 10 implementations supported IPv6. - Only 9 implementations understood UPDATE - I noted 12 implementations supported NAPTR+SRV, 4 SRV only, 8 do A lookups only, and 4 did no DNS at all. My notes only captured this information for roughly half the teams, but I think the proportions are representative. - 7 implementations supported S/MIME - 18 implementations supported PRACK - UA implementations (including proxies and b2buas) outnumbered proxy/registrar implementations around 4 to 1. - There were fewer SIMPLE implementations (and most of the ones present were presence server only). Many teams left their SIMPLE work at home, waiting for a SIMPLEt. The multiparty tests at this event were similar to those of the past. The spiral test continues to have the highest participation and yields the most implementation bugs. We refined the test scenario for REFER, setting up a star topology that lets us configure once and run many scenarios. We ran a NAPTR/SRV failover test that was intricate. Several implementations performed correctly when it became necessary to fail-over. We exposed one that was only taking the first returned record of a given type, and others that got their weighting algorithms backwards. We didn't have many STUN implementations, but those that were there worked together. We only had one SIGCOMP implementation show up this time. 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 From exim@www1.ietf.org Wed Feb 18 18:27:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01254 for ; Wed, 18 Feb 2004 18:27:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atb5z-0002AX-7b for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 18:27:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1INRBsx008276 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 18:27:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atb5p-00024Z-Ri; Wed, 18 Feb 2004 18:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atb5U-00023d-5B for sip@optimus.ietf.org; Wed, 18 Feb 2004 18:26:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01206 for ; Wed, 18 Feb 2004 18:26:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atb5R-0001ab-00 for sip@ietf.org; Wed, 18 Feb 2004 18:26:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atb4X-0001Yc-00 for sip@ietf.org; Wed, 18 Feb 2004 18:25:42 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Atb3d-0001VV-00 for sip@ietf.org; Wed, 18 Feb 2004 18:24:45 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i1INOAd08761; Wed, 18 Feb 2004 17:24:10 -0600 Subject: [Fwd: [Sip] Summary of observations from SIPIT 14] From: Robert Sparks To: sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1077146642.2249.175.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 18 Feb 2004 17:24:02 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I just sent: -----Forwarded Message----- > From: Robert Sparks > To: sip@ietf.org, sip-implementors@ietf.org > Subject: [Sip] Summary of observations from SIPIT 14 > Date: Wed, 18 Feb 2004 17:10:13 -0600 Of course, the second address is bogus. The correct address for that list appears in the headers of this message. Apologies now to those who will "Reply-All" to the original and get a bounce. 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 From exim@www1.ietf.org Thu Feb 19 01:59:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17331 for ; Thu, 19 Feb 2004 01:59:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati9M-00044I-Eb for sip-archive@odin.ietf.org; Thu, 19 Feb 2004 01:59:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J6x8tp015585 for sip-archive@odin.ietf.org; Thu, 19 Feb 2004 01:59:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati9F-00040S-87; Thu, 19 Feb 2004 01:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9av-0002Ey-H1 for sip@optimus.ietf.org; Tue, 17 Feb 2004 13:05:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22498 for ; Tue, 17 Feb 2004 13:05:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9at-0005Au-00 for sip@ietf.org; Tue, 17 Feb 2004 13:05:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9a0-00052W-00 for sip@ietf.org; Tue, 17 Feb 2004 13:04:21 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1At9Z3-0004vK-00 for sip@ietf.org; Tue, 17 Feb 2004 13:03:21 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1HI3KAH009546 for ; Tue, 17 Feb 2004 11:03:20 -0700 (MST) Received: from artibeus.nsr.labs.mot.com (artibeus.nsr.labs.mot.com [173.23.95.73]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i1HHhZsg001811 for ; Tue, 17 Feb 2004 11:43:36 -0600 Received: from motorola.com (artibeus.nsr.labs.mot.com [173.23.95.73]) by artibeus.nsr.labs.mot.com (Postfix) with ESMTP id EDDA13800B; Tue, 17 Feb 2004 11:44:06 -0600 (CST) Message-ID: <403252E6.2040301@motorola.com> Date: Tue, 17 Feb 2004 11:44:06 -0600 From: Bryan Thale Organization: Networks & Infrastructure Research, Motorola Labs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Cc: Cullen Jennings Subject: Re: [Sip] Binary Encoding for SIP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Cullen, I'd vote for 'b', not because the idea is stupid but because it is unnecessary. Why restrict the ability of the end-point service to choose the most efficient encoding for its purposes? If that happens to be 'binary' then great, but if not, that's OK, too. I agree with this sentiment from your draft: > ... it is reasonable to suggest that SIP implementations send one type > of encoding However, this is at odds with the ultimate recommendation of your draft: > Devices MUST use a content transfer encoding of "binary" for MIME body > parts in SIP messages they send. If the problem is that implementors are inappropriately choosing Base64 due to lack of sufficient guidance, I would prefer to see "Devices SHOULD use ..." instead. It provides the needed guidance and yet does not arbitrarily close doors on possible future implementations. Bryan. -- Bryan Thale Networks & Infrastructure Research, Motorola Labs mailto:bryan.thale@motorola.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 19 05:33:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12683 for ; Thu, 19 Feb 2004 05:33:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtlUY-0004SZ-IU for sip-archive@odin.ietf.org; Thu, 19 Feb 2004 05:33:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JAXEqa017142 for sip-archive@odin.ietf.org; Thu, 19 Feb 2004 05:33:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtlUL-0004R0-RS; Thu, 19 Feb 2004 05:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtlTQ-0004Nc-0s for sip@optimus.ietf.org; Thu, 19 Feb 2004 05:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12669 for ; Thu, 19 Feb 2004 05:32:00 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtlTM-0003sP-00 for sip@ietf.org; Thu, 19 Feb 2004 05:32:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtlST-0003p3-00 for sip@ietf.org; Thu, 19 Feb 2004 05:31:06 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AtlRs-0003n3-00 for sip@ietf.org; Thu, 19 Feb 2004 05:30:28 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1JATWS01578; Thu, 19 Feb 2004 12:30:02 +0200 (EET) X-Scanned: Thu, 19 Feb 2004 12:29:02 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1JAT21S030062; Thu, 19 Feb 2004 12:29:02 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00Dov8l1; Thu, 19 Feb 2004 12:29:00 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1JASx710171; Thu, 19 Feb 2004 12:28:59 +0200 (EET) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 19 Feb 2004 12:28:55 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-khartabil-sip-auth-analysis-00.txt Date: Thu, 19 Feb 2004 12:28:55 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797789@esebe019.ntc.nokia.com> Thread-Topic: [Sip] draft-khartabil-sip-auth-analysis-00.txt Thread-Index: AcP2NDJLmgdr87j7RnOQEN0wPaWjDwAmdHPw To: Cc: X-OriginalArrivalTime: 19 Feb 2004 10:28:55.0560 (UTC) FILETIME=[2D554080:01C3F6D3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Scott Lawrence [mailto:slawrence@pingtel.com] > Sent: 18.February.2004 17:30 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: sip@ietf.org > Subject: Re: [Sip] draft-khartabil-sip-auth-analysis-00.txt >=20 >=20 >=20 >=20 > > > realm > > > A string to be displayed to users so they know which=20 > username and > > > password to use. > >=20 > > I don't think this takes into consideration pre-configuration. >=20 > That's not really the point; the realm needs to provide=20 > enough of a hint > for the UA to determine which credentials it should use. Setting up a > configuration that requires different credentials for the=20 > same realm at > different servers is dumb, and not something I think we need to spend > much worry on. It not about setting different credentials for the same realm. It is = about pre-configuring the wrong credentials for a realm. If my phone is = preconfigured with username: hisham, password: hishampass, realm: = nokia.com and: --> INVITE <-- 407 --> INVITE <-- 407 (credentials where wrong) At this stage, the user should be prompted to enter new = username/password. My objection is to the text quoted below from = RFC3261: " A service provider that pre-configures UAs with credentials for its realm should be aware that users will not have the opportunity to present their own credentials for this realm when challenged at a pre-configured device". I think the users should have the opportunity. >=20 > > > ... This string should contain at least=20 > the name of > > > the host performing the authentication and might additionally > > > indicate the collection of users who might have=20 > access. An example > > > might be "registered_users@gotham.news.com". > >=20 > > Can we mandate that for SIP?? >=20 > I don't think that we can mandate anything that is by nature an > administrative decision - we already provide good advice. =20 > However, 3261 > does say (22.1): >=20 > o Realm strings MUST be globally unique. It is=20 > RECOMMENDED that > a realm string contain a hostname or domain name,=20 > following the > recommendation in Section 3.2.1 of RFC 2617 [17]. MUST be globally unique for every proxy in the same administrative = domain? I don't think this is required. >=20 > > > As a practical matter, if you have the same username and=20 > password in > > > both domains it doesn't matter - if you don't, then it's=20 > an impossibly > > > clumsy situation (this problem is part of the reason that=20 > we defined > > > proxy authentication to by hop-by-hop in HTTP in the first place). > >=20 > > Perhaps I was not clear in my text. Imagine this scenario:=20 > I have cached my credentials for an outbound proxy with realm=20 > proxy.nokia.com from an earlier transaction. Now I send a new=20 > INVITE routed through the outbound proxy that gets a 407 from=20 > a second proxy with the same realm. How do I know if the 407=20 > came from the outbound proxy (the username password might=20 > have changed in the meantime) or from the next hop proxy? >=20 > What difference does it make? You just use the credentials=20 > you have in > either case, or you fail... =20 It matters because the UA doesn't know if the credentials supplied to = the first proxy were wrong and therefore is sending another 407 or if = the second proxy is challenging with the same realm. The qop ting you = mention below should fix this. >As I pointed out, you can tell the > difference if the server is using qop. >=20 >=20 > > > If the proxy is using the 2617 version of Digest (with the qop > > > attribute) as opposed to the 1867 version, then the UA can tell > > > the difference. The message flow looks like this: > > >=20 > > > UA P1 P2 > > > a +------REQ 1--------->| | > > > b |<----407(1)----------+ | > > > c +------REQ 2 -------->+----REQ 2--------->| > > > e |<---407(2)-----------+<-----407(2)-------| > > > +------REQ 3--------->+----REQ 3--------->| > > >=20 > > > a) initial request > > > b) challenge from P1, with the qop parameter specified > > > c) retried request, with a qop parameter, and therefor=20 > also a cnonce > > > chosen by the UA; it is passed on (now without=20 > > > authentication) to P2 > > > d) P2 challenges, also specifying a qop parameter > > > P2 challenge is forwarded by P1, with the WWW-Authenticate > > > header as provided by P2, but also with an Authentication-Info > > > provided by P1. > > >=20 > > > The UA can recognize that authentication to P1 was=20 > successful, because > > > P1 returned an Authentication-Info header that contained=20 > the cnonce > > > and nc values from message c (REQ 2), and a correct=20 > response hash to > > > show that P1 knows the authentication secret. > >=20 > > This is not mandated for SIP entities, maybe it aught to be. >=20 > Actually, it is, but it's the usual unfortunate incorrect=20 > intrepretation > of SHOULD that is biting us again. RFC 2617 says: >=20 > qop-options > This directive is optional, but is made so only for backward > compatibility with RFC 2069 [6]; it SHOULD be used by all > implementations compliant with this version of the Digest scheme. >=20 > Since SIP references only 2617, and backward compatibility=20 > with 1867 is > not important, all SIP servers should be using qop-options. This is all great, although I prefer for this to be called out = explicitly for SIP, making the SHOULD a MUST. Also, there is nothing = mandating a proxy to send the Authentication-info header. Perhaps that = aught to be mandated also if a proxy server proxies a request it had = previously challenged and another proxy downstream challenges the same = request with the same realm. >=20 > > > > 10. Authentication-Info > > > > > > > > RFC 3261 allows the usage of Authentication-Info=20 > header. The BNF in > > > > RFC 3261 allows multiple authentication-info headers=20 > where RFC 2617 > > > > allows only one. Is it only the terminating UAS that=20 > is allowed to > > > > insert this header. If so, why allow multiples to be=20 > > > present. If not, > > > > how does the UAC know which proxy added this header?=20 > It cannot know > > > > since there is no parameter indicating so, not even nonce. > > >=20 > > > As I noted earlier, 2617 allows only one because proxy=20 > authentication > > > is hop-by-hop, but the cnonce value allows the UA to=20 > disambiguate them > > > (if they are carefully constructed, but then they should=20 > be anyway). > >=20 > > SIP BNF allows multiples of those headers. Is this a BNF=20 > bug? If not, then some Authentication-Info parameters need to=20 > be mandated. >=20 > The BNF is never the last word - the text MUST be read too, and the > requirement there is, I think, already clear. Ok, although it is only implied that message-qop MUST appear in = Authentication-info header if the earlier challenge/response contained = the qop. >=20 > --=20 > Scott Lawrence =20 > Pingtel Corp. =20 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 19 10:51:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24364 for ; Thu, 19 Feb 2004 10:51:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqSJ-0007iF-5a for sip-archive@odin.ietf.org; Thu, 19 Feb 2004 10:51:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JFpFSA029644 for sip-archive@odin.ietf.org; Thu, 19 Feb 2004 10:51:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqS6-0007fT-3W; Thu, 19 Feb 2004 10:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqRS-0007Uy-CS for sip@optimus.ietf.org; Thu, 19 Feb 2004 10:50:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24290 for ; Thu, 19 Feb 2004 10:50:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtqRQ-0003xu-00 for sip@ietf.org; Thu, 19 Feb 2004 10:50:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtqQl-0003ua-00 for sip@ietf.org; Thu, 19 Feb 2004 10:49:39 -0500 Received: from web41802.mail.yahoo.com ([66.218.93.136]) by ietf-mx with smtp (Exim 4.12) id 1AtqQA-0003n9-00 for sip@ietf.org; Thu, 19 Feb 2004 10:49:02 -0500 Message-ID: <20040219154832.94731.qmail@web41802.mail.yahoo.com> Received: from [63.159.88.109] by web41802.mail.yahoo.com via HTTP; Thu, 19 Feb 2004 07:48:32 PST Date: Thu, 19 Feb 2004 07:48:32 -0800 (PST) From: CAITR Reply-To: info@caitr.org To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1905995372-1077205712=:94531" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2 autolearn=no version=2.60 Subject: [Sip] Internetworking 2004: May 13-14, 2004, Las Vegas Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0-1905995372-1077205712=:94531 Content-Type: text/plain; charset=us-ascii CONFERENCE ANNOUNCEMENT & CALL FOR PRESENTATIONS ------------------------------------------------------------------------------ INTERNETWORKING 2004 Technical Program: May 13-14, 2004 Las Vegas, Nevada http://www.caitr.org/internetworking04/ In conjunction with NetWorld+Interop Las Vegas 2004 -------------------------------------------------------------------------------- The Internetworking 2004 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words should be submitted (in plain text format) to submissions at caitr.org for review and possible inclusion in the program, no later than February 25, 2004. Topics of interest include, but are not limited to the following: Voice over IP (VoIP) Virtual Private Networks Routing and Quality of Service (QoS) Network Processors Network Security Service Integration Operational Support Systems Transition from IPv4 to IPv6 and Interworking Network Survivability and Fault Management Wireless Internet Next Generation Mobile Networks Internetworking IP and Optical Networks Internetworking MPLS with Legacy ATM and Frame Relay Networks Fiber To The Home (FTTH) High Speed Transport Layer Protocols Unicast and Multicast Routing and Convergence Storage Area Networks (SANs) Peer to Peer Networking Pervasive Computing Grid Computing IP Video Conferencing High Definition Video Distribution For additional information, please contact info at caitr.org, or the conference technical chair, Dr. Parviz Yegani (). --0-1905995372-1077205712=:94531 Content-Type: text/html; charset=us-ascii
CONFERENCE ANNOUNCEMENT & CALL FOR PRESENTATIONS

------------------------------------------------------------------------------
      INTERNETWORKING 2004
Technical Program: May 13-14, 2004
          Las Vegas, Nevada
http://www.caitr.org/internetworking04/
In conjunction with NetWorld+Interop Las Vegas 2004
--------------------------------------------------------------------------------
The Internetworking 2004 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains.

Summaries not exceeding 250 words should be submitted (in plain text format) to submissions at caitr.org for review and possible inclusion in the program, no later than February 25, 2004.

Topics of interest include, but are not limited to the following:

   Voice over IP (VoIP)
   Virtual Private Networks
   Routing and Quality of Service (QoS)
   Network Processors
   Network Security
   Service Integration
   Operational Support Systems
   Transition from IPv4 to IPv6 and Interworking
   Network Survivability and Fault Management
   Wireless Internet
   Next Generation Mobile Networks
   Internetworking IP and Optical Networks
   Internetworking MPLS with Legacy ATM and Frame Relay Networks
   Fiber To The Home (FTTH)
   High Speed Transport Layer Protocols
   Unicast and Multicast Routing and Convergence
   Storage Area Networks (SANs)
   Peer to Peer Networking
   Pervasive Computing
   Grid Computing
   IP Video Conferencing
   High Definition Video Distribution

For additional information, please contact info at caitr.org, or the conference technical chair, Dr. Parviz Yegani (<pyegani at cisco.com>).
--0-1905995372-1077205712=:94531-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 19 11:23:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25859 for ; Thu, 19 Feb 2004 11:23:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqxC-0003o9-Mv for sip-archive@odin.ietf.org; Thu, 19 Feb 2004 11:23:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JGNAuu014575 for sip-archive@odin.ietf.org; Thu, 19 Feb 2004 11:23:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atqx3-0003lR-OF; Thu, 19 Feb 2004 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqwG-0003jL-HI for sip@optimus.ietf.org; Thu, 19 Feb 2004 11:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25817 for ; Thu, 19 Feb 2004 11:22:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtqwF-0006A6-00 for sip@ietf.org; Thu, 19 Feb 2004 11:22:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtqvK-00068X-00 for sip@ietf.org; Thu, 19 Feb 2004 11:21:15 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1Atque-00066y-00 for sip@ietf.org; Thu, 19 Feb 2004 11:20:32 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id A94E9BD88; Thu, 19 Feb 2004 17:16:19 +0100 (CET) Received: from jku07.iptel.org (dhcp240.fokus.fraunhofer.de [195.37.78.240]) by fox.iptel.org (Postfix) with ESMTP id 04B8BBD88; Thu, 19 Feb 2004 17:16:19 +0100 (CET) Message-Id: <6.0.1.1.0.20040219170843.03ef5ec0@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 19 Feb 2004 17:11:38 +0100 To: Rohan Mahy , Anil Bollineni From: Jiri Kuthan Subject: Re: [Sip] Changing Via In NAT Cc: "'sip@ietf.org'" In-Reply-To: <75587981-6210-11D8-9B6B-0003938AF740@cisco.com> References: <017B1BB60535DF4285666089FA048AC20172EFE6@SONOMA.netscreen.com> <75587981-6210-11D8-9B6B-0003938AF740@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 01:46 PM 2/18/2004, Rohan Mahy wrote: >The experience of the working group has shown that implementing a SIP ALG in a firewall is "a bad thing". I have personal experience with the failings of SIP ALGs at my own company, not the least of which is that they don't work at all when SIP is integrity-protected using TLS. > >Many UAs now support RFC 3581 and can use the STUN protocol to get valid public addresses and ports to advertise in SDP for their RTP traffic. This has been relatively painless compared to working with the shortcomings of ALGs. Absolutely -- rport is very essential part of the story as it adds lot of robustness to traversal of SIP transactions over NATs. Sending replies back symmetricaly simply works. Not using rport leads to all kind of instabilities such as missed SIP replies when STUN address in Via without rport becomes invalid for whatever reason. Besides that, adding rport to UAC is banal. -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 exim@www1.ietf.org Fri Feb 20 00:24:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17968 for ; Fri, 20 Feb 2004 00:24:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au39F-0002mU-FN for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:24:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K5OOHA010447 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:24:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au38t-0002Tj-7F; Fri, 20 Feb 2004 00:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au38Y-0002SY-Lx for sip@optimus.ietf.org; Fri, 20 Feb 2004 00:23:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17812 for ; Fri, 20 Feb 2004 00:23:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au38W-0002ds-00 for sip@ietf.org; Fri, 20 Feb 2004 00:23:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au37Y-0002XY-00 for sip@ietf.org; Fri, 20 Feb 2004 00:22:40 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Au36Z-0002Qe-01 for sip@ietf.org; Fri, 20 Feb 2004 00:21:39 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1K5L7uC021868; Thu, 19 Feb 2004 21:21:09 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-148.cisco.com [10.21.96.148]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMN04131; Thu, 19 Feb 2004 21:21:07 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 19 Feb 2004 18:00:58 -0800 Subject: Re: [Sip] SIP instance identifiers From: Cullen Jennings To: Brian Stucker , Jonathan Rosenberg , Paul H Kyzivat CC: Message-ID: In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B5975304B81C63@zrc2c012.us.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/17/04 11:26 PM, "Brian Stucker" wrote: > . I also don't see a reason why we should expect > other nodes in the network to be able to use the instance identifier for > anything > other than a token (ie. if it's a mac address, and two UA instances do > something > because it's a MAC address, that's OK, but other's may not take that tact). I sort of agree and sort of don't. The only important thing about MAC is that most phone vendors have it on the outside of the box and you can read it with a barcode scanner. If a user goes to some configuration web page and see that they have 2 devices registered, they have some hope of finding an identifier on the back of the phone (the MAC) that they can match to one of the two instances on the web page. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 00:24:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17969 for ; Fri, 20 Feb 2004 00:24:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au39F-0002mX-GJ for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:24:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K5OO1o010445 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:24:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au38u-0002Ty-JB; Fri, 20 Feb 2004 00:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au38a-0002Sd-5k for sip@optimus.ietf.org; Fri, 20 Feb 2004 00:23:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17815 for ; Fri, 20 Feb 2004 00:23:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au38X-0002e5-00 for sip@ietf.org; Fri, 20 Feb 2004 00:23:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au37Z-0002Xh-00 for sip@ietf.org; Fri, 20 Feb 2004 00:22:41 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Au36a-0002Qf-00 for sip@ietf.org; Fri, 20 Feb 2004 00:21:40 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2004 21:31:07 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1K5L84U013678; Thu, 19 Feb 2004 21:21:09 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-148.cisco.com [10.21.96.148]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMN04132; Thu, 19 Feb 2004 21:21:07 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 19 Feb 2004 18:01:05 -0800 From: Cullen Jennings To: Dean Willis , Brian Stucker CC: Jonathan Rosenberg , Message-ID: In-Reply-To: <40326894.7010809@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Abstraction: SIP instance identifiers requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't think this unique instance identifier thing had much to do with billing or debugging. I'm imagine a case something like the following: I have two offices, one on the west side of the building and one of the east. They both have phones registered as fluffy. Because it is better for lounging in the Sun, I spend the morning in the East office and afternoon in the West. Right now I can't write a proxy that forward to the correct one. If I was using SUBSCRIBE to support event notification of provisioning changes, I would not be able to identify which phone was subscribing. On 2/17/04 11:16 AM, "Dean Willis" wrote: > 1) billing -- "Alice called Bob from phone ID000001 through gateway > ID3344555 on Tuesday, March 1, 2011" > > 2) Debugging -- "This request was responded to by node IDYIYIOHIHIUH, > which is a Barfia model 9995 phone running Finux 21.05A and the Vocal > user agent release 89.6" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 00:39:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18936 for ; Fri, 20 Feb 2004 00:39:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3NW-0004jT-5H for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:39:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K5dA3S018128 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3NO-0004dT-11; Fri, 20 Feb 2004 00:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3N3-0004cq-FL for sip@optimus.ietf.org; Fri, 20 Feb 2004 00:38:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18925 for ; Fri, 20 Feb 2004 00:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au3N0-00042a-00 for sip@ietf.org; Fri, 20 Feb 2004 00:38:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au3M4-000401-00 for sip@ietf.org; Fri, 20 Feb 2004 00:37:41 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Au3Ls-0003xZ-00 for sip@ietf.org; Fri, 20 Feb 2004 00:37:28 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2004 21:37:22 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1K5au4U021716; Thu, 19 Feb 2004 21:36:56 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-109.cisco.com [10.86.242.109]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGE61716; Fri, 20 Feb 2004 00:36:55 -0500 (EST) Message-ID: <40359CF6.4090406@cisco.com> Date: Fri, 20 Feb 2004 00:36:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] SIP instance identifiers References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just to be clear, I am not *advocating* that we need these identifiers any other place. I'm just saying that if there are other uses for a device id, that it won't hurt to use the same id elsewhere. For the purpose we are discussing, it is important that the id be associated with a registered contact, and since REGISTER permits multiple contacts, it really needs to be a parameter on each contact. That is really an entirely different application from identifying which device originated a particular message. If there is a need for that, then it needs to be in some header that can be in any message. I don't recommend we do that until we have a need for it. Paul Cullen Jennings wrote: > On 2/17/04 2:28 PM, "Paul Kyzivat" wrote: > > >>I can see >>validity in Brian's desire to have it in a header of its own, >>potentially in any message. I don't see those usages as conflicting. > > > Just to be clear, I don't want it to have multiple possible place it could > be in a SIP message and I have to go traipsing around the message trying > here then there unless it is a FOO message where you look over here. A > header would work or caller pref but I don't see an argument for doing both. > I want it just one place. > > The case with PUBLISH not having contact header had concerned me (actually I > think this was a mistake) but seems what happens in PIDF bodies could be > different. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 01:10:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17967 for ; Fri, 20 Feb 2004 00:24:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au39F-0002mY-Gh for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:24:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K5OPdY010442 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:24:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au38r-0002TO-NE; Fri, 20 Feb 2004 00:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au38X-0002ST-Ga for sip@optimus.ietf.org; Fri, 20 Feb 2004 00:23:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17809 for ; Fri, 20 Feb 2004 00:23:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au38U-0002df-00 for sip@ietf.org; Fri, 20 Feb 2004 00:23:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au37X-0002XQ-00 for sip@ietf.org; Fri, 20 Feb 2004 00:22:40 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Au36Z-0002Qe-00 for sip@ietf.org; Fri, 20 Feb 2004 00:21:39 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1K5L7uA021868; Thu, 19 Feb 2004 21:21:07 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-148.cisco.com [10.21.96.148]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMN04130; Thu, 19 Feb 2004 21:21:06 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 19 Feb 2004 18:00:57 -0800 Subject: Re: [Sip] SIP instance identifiers From: Cullen Jennings To: Paul H Kyzivat , Jonathan Rosenberg CC: Message-ID: In-Reply-To: <40329592.1080001@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/17/04 2:28 PM, "Paul Kyzivat" wrote: > I can see > validity in Brian's desire to have it in a header of its own, > potentially in any message. I don't see those usages as conflicting. Just to be clear, I don't want it to have multiple possible place it could be in a SIP message and I have to go traipsing around the message trying here then there unless it is a FOO message where you look over here. A header would work or caller pref but I don't see an argument for doing both. I want it just one place. The case with PUBLISH not having contact header had concerned me (actually I think this was a mistake) but seems what happens in PIDF bodies could be different. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 01:10:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17971 for ; Fri, 20 Feb 2004 00:24:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au39F-0002mW-Fw for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:24:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K5OOj6010439 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 00:24:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au38x-0002Uy-30; Fri, 20 Feb 2004 00:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au38f-0002Sn-Fw for sip@optimus.ietf.org; Fri, 20 Feb 2004 00:23:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17833 for ; Fri, 20 Feb 2004 00:23:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au38c-0002ek-00 for sip@ietf.org; Fri, 20 Feb 2004 00:23:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au37k-0002ZI-00 for sip@ietf.org; Fri, 20 Feb 2004 00:22:52 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Au36l-0002Qh-00 for sip@ietf.org; Fri, 20 Feb 2004 00:21:51 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2004 21:21:45 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1K5LJ4U013793; Thu, 19 Feb 2004 21:21:20 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-148.cisco.com [10.21.96.148]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMN04154; Thu, 19 Feb 2004 21:21:18 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 19 Feb 2004 20:32:57 -0800 Subject: Re: [Sip] draft-khartabil-sip-policy-uri-call-info-purpose-00 From: Cullen Jennings To: , Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797753@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I was hoping it would only be conferences. If it is more than that, then I would need to know what I should expect to find when I load the document the URI points at. Cullen On 2/16/04 1:07 AM, "hisham.khartabil@nokia.com" wrote: > Thanks. > > Do you think that it will only be limited to conferences? > > /Hisham > >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext >> Cullen Jennings >> Sent: 13.February.2004 18:49 >> To: sip@ietf.org >> Subject: [Sip] >> >> >> >> I like this draft, just one little NIT, I think it would be >> better to call >> the tag conf-policy-info instead of just policy-info >> >> Cullen >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 02:04:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27127 for ; Fri, 20 Feb 2004 02:04:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4hM-0003nV-BC for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 02:03:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K73iDu014524 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 02:03:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4gq-0003YB-Ss; Fri, 20 Feb 2004 02:03:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4gN-0003PQ-HV for sip@optimus.ietf.org; Fri, 20 Feb 2004 02:02:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25451 for ; Fri, 20 Feb 2004 02:02:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4gJ-0002iB-00 for sip@ietf.org; Fri, 20 Feb 2004 02:02:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4fN-0002fZ-00 for sip@ietf.org; Fri, 20 Feb 2004 02:01:42 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Au4ee-0002aJ-00 for sip@ietf.org; Fri, 20 Feb 2004 02:00:56 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2004 23:00:54 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1K70Rcw002278; Thu, 19 Feb 2004 23:00:27 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-34.cisco.com [10.21.112.34]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMN08350; Thu, 19 Feb 2004 23:00:26 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 19 Feb 2004 22:21:19 -0800 Subject: Re: [Sip] Binary Encoding for SIP From: Cullen Jennings To: Paul H Kyzivat CC: Message-ID: In-Reply-To: <403224E2.5070401@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Good point. I think that all they ways I can imagine getting indirect content, HTTP, FTP, TFTP, NFS, SMB, file are all 8 bit safe so I think this argument probably still holds. Cullen On 2/17/04 6:27 AM, "Paul Kyzivat" wrote: > Cullen, > > This is an attractive proposal because it has potential to make sip > implementations simpler. But before I can answer I need clarification on > one thing: > > Does this apply to content referenced and fetched via content-indirection? > > This proposal only has value if my mime processor *never* needs to deal > with any content-transfer-encoding other than binary. If content > referenced by content indirection still might use other encodings, then > that value is lost. Unfortunately, given the potential range of > transports that might be used with content indirection, I don't know if > requiring binary can be done in general. > > Paul > > Cullen Jennings wrote: >> >> I submitted a draft on binary encoding for SIP. This improves >> interoperability, improves speed, decreases sizes of messages, and generally >> makes life better for SIP which will no doubt eventually help with World >> Hunger. I need feedback, please let me know: >> >> a) Yah, lets do it >> >> b) No this is a stupid ideas and here are the reasons why >> >> c) There has not been many list comments, this draft involves some very >> complex issues. I need a year or two to develop an opinion on the single >> sentence inside it. >> >> d) I agree with Cowboy Willis >> >> Until it arrives in the archives, you can find it at >> >> http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html >> >> or, if you prefer ASCII encodings of everything, >> >> www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt >> >> Thanks, Cullen >> >> >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 02:04:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27155 for ; Fri, 20 Feb 2004 02:04:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4hM-0003nU-BC for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 02:03:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K73iuJ014523 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 02:03:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4h1-0003bW-RB; Fri, 20 Feb 2004 02:03:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4gO-0003Pm-OP for sip@optimus.ietf.org; Fri, 20 Feb 2004 02:02:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25471 for ; Fri, 20 Feb 2004 02:02:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4gL-0002iN-00 for sip@ietf.org; Fri, 20 Feb 2004 02:02:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4fP-0002fp-00 for sip@ietf.org; Fri, 20 Feb 2004 02:01:43 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Au4ef-0002aM-00 for sip@ietf.org; Fri, 20 Feb 2004 02:00:57 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1K70Qcw002265; Thu, 19 Feb 2004 23:00:26 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-34.cisco.com [10.21.112.34]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMN08348; Thu, 19 Feb 2004 23:00:25 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 19 Feb 2004 22:18:51 -0800 Subject: Re: [Sip] Binary Encoding for SIP From: Cullen Jennings To: Marc Petit-Huguenin CC: Message-ID: In-Reply-To: <402FA64B.2060907@acm.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You are right - 3261 definitely allows binaries bodies. I am just trying to suggest that it would be better to send MIME bodies with a transfer encoding set to binary instead of base64 when sending them. Right now SIP allows either, the examples are in base64, but binary is probably a better choice. It seems like it should not be a big deal but it has been one of the frustrating interoperability issues in getting S/MIME to work. Cullen On 2/15/04 9:03 AM, "Marc Petit-Huguenin" wrote: > I thought that binary body was already supported: RFC3261 section 7.4.1, > third paragraph. > > Cullen Jennings wrote: >> >> I submitted a draft on binary encoding for SIP. This improves >> interoperability, improves speed, decreases sizes of messages, and generally >> makes life better for SIP which will no doubt eventually help with World >> Hunger. I need feedback, please let me know: >> >> a) Yah, lets do it >> >> b) No this is a stupid ideas and here are the reasons why >> >> c) There has not been many list comments, this draft involves some very >> complex issues. I need a year or two to develop an opinion on the single >> sentence inside it. >> >> d) I agree with Cowboy Willis >> >> Until it arrives in the archives, you can find it at >> >> http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html >> >> or, if you prefer ASCII encodings of everything, >> >> www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt >> >> Thanks, Cullen >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 02:04:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27156 for ; Fri, 20 Feb 2004 02:04:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4hM-0003nS-BD for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 02:03:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K73iL7014526 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 02:03:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4gj-0003Va-6G; Fri, 20 Feb 2004 02:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4gN-0003PG-AT for sip@optimus.ietf.org; Fri, 20 Feb 2004 02:02:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25442 for ; Fri, 20 Feb 2004 02:02:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4gJ-0002i6-00 for sip@ietf.org; Fri, 20 Feb 2004 02:02:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4fM-0002fR-00 for sip@ietf.org; Fri, 20 Feb 2004 02:01:41 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Au4ed-0002aJ-00 for sip@ietf.org; Fri, 20 Feb 2004 02:00:55 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2004 23:00:51 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1K70Md0002213; Thu, 19 Feb 2004 23:00:24 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-34.cisco.com [10.21.112.34]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMN08336; Thu, 19 Feb 2004 23:00:21 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 19 Feb 2004 21:48:06 -0800 Subject: Re: [Sip] RE: [Sip-implementors] Via: processing From: Cullen Jennings To: , , , CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit No I don't think this is a good idea. Putting a FQDN that is behind a NAT is not any more likely to be resolvable to a routeable IP address. A private IP is much easier to recognize and debug. Many hosts think they know their hostname but do not and they should not put in an address that is not routable in any domain. For example. most things, be it windows or unix, will report a hostname when really they got their IP address from DHCP and the hostname they are reporting is not in DNS. Here's my recommendation for IP phones, softphones - always use an IP in via and contacts unless you are positive that your FQDN really is in the global DNS and you have a specific reason to use DNS (like multiple NICs for redundancy). Cullen On 2/12/04 10:20 PM, "ranjit.avasarala@wipro.com" wrote: > Hi > actually putting IP address in Via is not recommended when the SIP > message has to traverse through NAT. So it is better to have FQDN > instead of IP. > > Ranjit > > > > > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > Nataraju Alilaghatta (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) > Sent: Friday, February 13, 2004 4:37 AM > To: Paul.D.Smith@dataconnection.com; brett@broadsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] RE: [Sip-implementors] Via: processing > > > I guess putting FQDN or IP addresses in the Via header driven by the > tradeoff between overhead in DNS query for FQDN name but provides > robustness or direct usage of IP address which lead to undeliverable in > case intermediate entities failure. > > It's my feeling, please correct me if I am wrong.... > > Thanks & Regards, > Nataraju A.B. > > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Paul > D.Smith > Sent: Friday, January 30, 2004 9:56 PM > To: 'brett@broadsoft.com' > Cc: SIP WG > Subject: [Sip] RE: [Sip-implementors] Via: processing > > Brett, Arlie, > > RFC3261 clearly allows a response to be "rerouted" if it can be > determined that the response did not reach the first-attempt target. > For example, if the request is received over TCP, and the connection has > gone and cannot be reestablished by the time the response is ready to be > sent back, RFC3261 states the following > > --- from RFC3261, section 18.2.2, 1st bullet. > > If that connection attempt fails, the server SHOULD use the procedures > in [4] for servers in order to determine the IP address and port to open > the connection and send the response to. > > --- end of cut > > RFC3263 then gives an algorithm for attempting to determine alternate IP > addresses to which the response might be sent. Clearly having an FQDN > in the sent-by will give a chance of success which having an IP address > will not, especially if the sent-by and received IP addresses are the > same! > > Paul DS. > > Paul D.Smith > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > > > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 29 January 2004 00:27 > To: SIP (E-mail) > Subject: RE: [Sip-implementors] Via: processing > > >> I'm looking at the spec for Via: processing. >> RFC 3261 clearly shows that a Via: line can >> contain DNS names, as well as textual >> representations of network addresses. >> >> How many products actually implement support >> for resolving DNS names provided in Via: lines? > > Not very many support DNS resolution of a > Via entry. However many support the concept > of adding the Via's received parameter when > it does not match the Via's sent-by address. > >> This seems... well, it seems unnecessary, >> potentially insecure (allowing for easy DDoS >> and potentially amplification attacks), and >> just a general nuisance. Is this kind of >> thing ever actually used for a good purpose? > > Some people have toyed with the idea of > advancing response addresses based upon > rfc3263 during failure situations. > >> Does any product do anything *but* just put >> real network addresses in Via: lines in >> requests? > > Yes. > > _______________________________________________ > 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 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 02:50:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27157 for ; Fri, 20 Feb 2004 02:04:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4hM-0003nT-BD for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 02:03:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K73iSh014525 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 02:03:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4gy-0003aR-4C; Fri, 20 Feb 2004 02:03:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4gO-0003Pf-7o for sip@optimus.ietf.org; Fri, 20 Feb 2004 02:02:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25461 for ; Fri, 20 Feb 2004 02:02:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4gK-0002iG-00 for sip@ietf.org; Fri, 20 Feb 2004 02:02:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4fO-0002fh-00 for sip@ietf.org; Fri, 20 Feb 2004 02:01:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Au4ee-0002aJ-01 for sip@ietf.org; Fri, 20 Feb 2004 02:00:56 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2004 23:00:55 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1K70Rd0002278; Thu, 19 Feb 2004 23:00:29 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-34.cisco.com [10.21.112.34]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMN08351; Thu, 19 Feb 2004 23:00:26 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 19 Feb 2004 22:30:44 -0800 Subject: Re: [Sip] Binary Encoding for SIP From: Cullen Jennings To: Bryan Thale , , Henning Schulzrinne Message-ID: In-Reply-To: <403252E6.2040301@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I sat for a long time looking at that one MUST and trying to decide if it should be a SHOULD. I also avoided mentioning what Henning points is the more interesting question of what must all UAs be willing to receive. So I take if you would be happy to see is say that things SHOULD send binary but need to be prepared to receive anything. I can live with that. Fits a certain stringent in what you send, lenient in what you receive model that I like. I doubt that implementers will be busy to go off and implement receiving multiple different things when there is no apparent value to doing that. It would solve my one really key issues which is that I would like to give enough guidance on the minimum to implement that things like S/MIME had a better chance of working together. Cullen On 2/17/04 9:44 AM, "Bryan Thale" wrote: > Hi Cullen, > > I'd vote for 'b', not because the idea is stupid but because it is > unnecessary. Why restrict the ability of the end-point service to > choose the most efficient encoding for its purposes? If that happens to > be 'binary' then great, but if not, that's OK, too. > > I agree with this sentiment from your draft: > >> ... it is reasonable to suggest that SIP implementations send one type >> of encoding > > > However, this is at odds with the ultimate recommendation of your draft: > >> Devices MUST use a content transfer encoding of "binary" for MIME body >> parts in SIP messages they send. > > > If the problem is that implementors are inappropriately choosing Base64 > due to lack of sufficient guidance, I would prefer to see "Devices > SHOULD use ..." instead. It provides the needed guidance and yet does > not arbitrarily close doors on possible future implementations. > > Bryan. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 04:55:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12783 for ; Fri, 20 Feb 2004 04:55:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7NV-0008NR-3H for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 04:55:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K9tO8c032104 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 04:55:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7NC-0008K3-4X; Fri, 20 Feb 2004 04:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7Mw-0008Ix-Up for sip@optimus.ietf.org; Fri, 20 Feb 2004 04:54:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12760 for ; Fri, 20 Feb 2004 04:54:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au7Mt-0007FT-00 for sip@ietf.org; Fri, 20 Feb 2004 04:54:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au7Lw-0007D0-00 for sip@ietf.org; Fri, 20 Feb 2004 04:53:48 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1Au7Lo-0007AY-00 for sip@ietf.org; Fri, 20 Feb 2004 04:53:40 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1K9r9W5024646; Fri, 20 Feb 2004 18:53:09 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1K9r9mt016704; Fri, 20 Feb 2004 18:53:09 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1K9r84o001131; Fri, 20 Feb 2004 18:53:08 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1K9r7dV001115; Fri, 20 Feb 2004 18:53:07 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1K9r4Ni009599; Fri, 20 Feb 2004 18:53:06 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA04214; Fri, 20 Feb 2004 18:53:04 +0900 (JST) Received: from lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id SAA14358; Fri, 20 Feb 2004 18:53:04 +0900 (JST) Date: Fri, 20 Feb 2004 18:53:02 +0900 From: Kumiko Ono Subject: Re: [Sip] Binary Encoding for SIP To: Cullen Jennings , Bryan Thale , sip@ietf.org, Henning Schulzrinne MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 3.07beta6 (WinNT,501) In-Reply-To: References: Message-Id: <4DC3F7975438E3ono.kumiko@lab.ntt.co.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Cullen, I am for 'a'. However, there may be some proxy severs who have the capability in handling 8-bit (text) data, not binary data. There may be an impact on all SIP entities including proxy servers that need not handle S/MIME data. Regards, Kumiko >I sat for a long time looking at that one MUST and trying to decide if it >should be a SHOULD. I also avoided mentioning what Henning points is the >more interesting question of what must all UAs be willing to receive. > >So I take if you would be happy to see is say that things SHOULD send binary >but need to be prepared to receive anything. > >I can live with that. Fits a certain stringent in what you send, lenient in >what you receive model that I like. I doubt that implementers will be busy >to go off and implement receiving multiple different things when there is no >apparent value to doing that. It would solve my one really key issues which >is that I would like to give enough guidance on the minimum to implement >that things like S/MIME had a better chance of working together. > >Cullen > > > >On 2/17/04 9:44 AM, "Bryan Thale" wrote: > >> Hi Cullen, >> >> I'd vote for 'b', not because the idea is stupid but because it is >> unnecessary. Why restrict the ability of the end-point service to >> choose the most efficient encoding for its purposes? If that happens to >> be 'binary' then great, but if not, that's OK, too. >> >> I agree with this sentiment from your draft: >> >>> ... it is reasonable to suggest that SIP implementations send one type >>> of encoding >> >> >> However, this is at odds with the ultimate recommendation of your draft: >> >>> Devices MUST use a content transfer encoding of "binary" for MIME body >>> parts in SIP messages they send. >> >> >> If the problem is that implementors are inappropriately choosing Base64 >> due to lack of sufficient guidance, I would prefer to see "Devices >> SHOULD use ..." instead. It provides the needed guidance and yet does >> not arbitrarily close doors on possible future implementations. >> >> Bryan. > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Kumiko Ono NTT Network Service Systems Labs. Tel +81 422 59 4508/Fax +81 422 60 4012 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 06:24:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15809 for ; Fri, 20 Feb 2004 06:24:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8lS-0006dY-FL for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 06:24:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KBOEYf025449 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 06:24:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8lF-0006ad-MB; Fri, 20 Feb 2004 06:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8lA-0006aL-7P for sip@optimus.ietf.org; Fri, 20 Feb 2004 06:23:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15801 for ; Fri, 20 Feb 2004 06:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au8l6-0005sF-00 for sip@ietf.org; Fri, 20 Feb 2004 06:23:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au8kA-0005on-00 for sip@ietf.org; Fri, 20 Feb 2004 06:22:54 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1Au8jI-0005jG-00 for sip@ietf.org; Fri, 20 Feb 2004 06:22:00 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i1KBLHLc026662 for ; Fri, 20 Feb 2004 05:21:17 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Feb 2004 05:16:58 -0600 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FGYL4TJA; Fri, 20 Feb 2004 05:21:24 -0600 Message-ID: <4035EDB4.8040108@ericsson.com> Date: Fri, 20 Feb 2004 13:21:24 +0200 X-Sybari-Trust: 67a4f572 c77f3eb6 1886a979 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip CC: "Christer Holmberg (JO/LMF)" , Rohan Mahy , Dean Willis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2004 11:16:58.0156 (UTC) FILETIME=[0DE83EC0:01C3F7A3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Defining new requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, it seems that some people in the ITU-T are having some issues figuring out whether or not certain requests can be sent by the UAS within an early dialog. The confusion comes from statements like this one (taken from the INFO spec): " Unless stated otherwise, the protocol rules for the INFO request governing the usage of tags, Route and Record-Route, retransmission and reliability, CSeq incrementing and message formatting follow those in [1] as defined for the BYE request." Since a UAS does not send BYEs within an early dialog, but a non-2xx final response instead, to terminate the dialog, people assume that INFO cannot be sent in this situation either. Let's try to keep this in mind and clarify this point when/if we define new SIP methods. In any event, the clarification to this issue can be found in RFC 3398: "From the callee to the caller, if a message is received by a gateway before the call has been answered (i.e., ANM is received) it SHOULD be encapsulated in an INFO, provided that this will not be the first SIP message sent in the backwards direction (in which case it SHOULD be encapsulated in a provisional 1xx response)." Regards, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 06:42:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16608 for ; Fri, 20 Feb 2004 06:42:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au92n-0000O9-G3 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 06:42:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KBg9Iu001460 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 06:42:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au92g-0000M9-5A; Fri, 20 Feb 2004 06:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au92Y-0000LW-NP for sip@optimus.ietf.org; Fri, 20 Feb 2004 06:41:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16605 for ; Fri, 20 Feb 2004 06:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au92U-000783-00 for sip@ietf.org; Fri, 20 Feb 2004 06:41:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au91Z-00075r-00 for sip@ietf.org; Fri, 20 Feb 2004 06:40:54 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Au91F-00073H-00 for sip@ietf.org; Fri, 20 Feb 2004 06:40:33 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1KBeXqY016735 for ; Fri, 20 Feb 2004 12:40:33 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Feb 2004 12:40:33 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Feb 2004 12:42:01 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "Gonzalo Camarillo (JO/LMF)" , sip Cc: Rohan Mahy , Dean Willis Date: Fri, 20 Feb 2004 12:40:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 20 Feb 2004 11:40:33.0257 (UTC) FILETIME=[595F8590:01C3F7A6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] RE: Defining new requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Gonzalo, Thanks for your reply! >it seems that some people in the ITU-T are having some issues >figuring out whether or not certain requests can be sent by the UAS within an >early dialog. The confusion comes from statements like this >one (taken from the INFO spec): > > " Unless stated otherwise, the protocol rules for the INFO request > governing the usage of tags, Route and Record-Route, > retransmission and reliability, CSeq incrementing and message > formatting follow those in [1] as defined for the BYE request." > >Since a UAS does not send BYEs within an early dialog, but a non-2xx >final response instead, to terminate the dialog, people assume that INFO >cannot be sent in this situation either. > >Let's try to keep this in mind and clarify this point when/if >we define new SIP methods. > >In any event, the clarification to this issue can be found in >RFC 3398: > >"From the callee to the caller, if a message is received by a gateway >before the call has been answered (i.e., ANM is received) >it SHOULD be encapsulated in an INFO, provided that this will not >be the first SIP message sent in the backwards direction (in which >case it SHOULD be encapsulated in a provisional 1xx response)." The problem is that the ITU-T interworking spec doesn't reference RFC3398. The spec reference the INFO RFC, and that is also where I think the usage rules should be defined (not in another spec, RFC3398 in this case, simply using the method). The INFO RFC, as you said, currently says that INFO "follows the rules of BYE" (whatever that means is another question :), and the rules for BYE specifically says that it must not be sent backward before the INVITE has finished. If the INFO RFC would say "follow the rules of UPDATE" we would not have this problem, since the UPDATE spec specifically allows the use of the method before the INVITE has finished. Thanks! Christer Holmberg Ericsson Finland This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 06:57:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17150 for ; Fri, 20 Feb 2004 06:57:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9HN-0001Kx-5L for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 06:57:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KBvDIL005136 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 06:57:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9HD-0001JA-2G; Fri, 20 Feb 2004 06:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9H8-0001IM-CS for sip@optimus.ietf.org; Fri, 20 Feb 2004 06:56:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17110 for ; Fri, 20 Feb 2004 06:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au9H4-0000MJ-00 for sip@ietf.org; Fri, 20 Feb 2004 06:56:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au9G7-0000Ig-00 for sip@ietf.org; Fri, 20 Feb 2004 06:55:56 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1Au9FU-0000D7-00 for sip@ietf.org; Fri, 20 Feb 2004 06:55:16 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i1KBsmfX021612 for ; Fri, 20 Feb 2004 05:54:48 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Feb 2004 05:50:19 -0600 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FGYL443D; Fri, 20 Feb 2004 05:54:45 -0600 Message-ID: <4035F586.1000405@ericsson.com> Date: Fri, 20 Feb 2004 13:54:46 +0200 X-Sybari-Trust: 42404863 c77f3eb6 1886a979 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" CC: sip , Rohan Mahy , Dean Willis References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2004 11:50:19.0609 (UTC) FILETIME=[B6DDBC90:01C3F7A7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Defining new requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christer, would the ITU-T be happier if we log an errata against the INFO RFC saying that UASs can send INFO within early dialogs? Gonzalo Christer Holmberg (JO/LMF) wrote: > Hi Gonzalo, > > Thanks for your reply! > > >>it seems that some people in the ITU-T are having some issues >>figuring out whether or not certain requests can be sent by the UAS > > within an > >>early dialog. The confusion comes from statements like this >>one (taken from the INFO spec): >> >>" Unless stated otherwise, the protocol rules for the INFO request >> governing the usage of tags, Route and Record-Route, >> retransmission and reliability, CSeq incrementing and message >> formatting follow those in [1] as defined for the BYE request." >> >>Since a UAS does not send BYEs within an early dialog, but a non-2xx >>final response instead, to terminate the dialog, people assume that > > INFO > >>cannot be sent in this situation either. >> >>Let's try to keep this in mind and clarify this point when/if >>we define new SIP methods. >> >>In any event, the clarification to this issue can be found in >>RFC 3398: >> >>"From the callee to the caller, if a message is received by a gateway >>before the call has been answered (i.e., ANM is received) >>it SHOULD be encapsulated in an INFO, provided that this will not >>be the first SIP message sent in the backwards direction (in which >>case it SHOULD be encapsulated in a provisional 1xx response)." > > > The problem is that the ITU-T interworking spec doesn't reference > RFC3398. The spec reference the INFO RFC, and that is also where I think > the usage rules should be defined (not in another spec, RFC3398 in this > case, simply using the method). > > The INFO RFC, as you said, currently says that INFO "follows the rules > of BYE" (whatever that means is another question :), and the rules for > BYE specifically says that it must not be sent backward before the > INVITE has finished. If the INFO RFC would say "follow the rules of > UPDATE" we would not have this problem, since the UPDATE spec > specifically allows the use of the method before the INVITE has > finished. > > Thanks! > > Christer Holmberg > Ericsson Finland This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 07:08:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17525 for ; Fri, 20 Feb 2004 07:08:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9S3-0002wh-K6 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 07:08:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KC8E40011032 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 07:08:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9Rs-0002qR-Mm; Fri, 20 Feb 2004 07:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9Rk-0002p7-E9 for sip@optimus.ietf.org; Fri, 20 Feb 2004 07:07:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17522 for ; Fri, 20 Feb 2004 07:07:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au9Rf-00015t-00 for sip@ietf.org; Fri, 20 Feb 2004 07:07:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au9Qo-00013M-00 for sip@ietf.org; Fri, 20 Feb 2004 07:06:59 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1Au9QN-00010A-00 for sip@ietf.org; Fri, 20 Feb 2004 07:06:31 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1KC6TAh000035 for ; Fri, 20 Feb 2004 13:06:29 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Feb 2004 13:06:29 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Feb 2004 13:07:57 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "Gonzalo Camarillo (JO/LMF)" Cc: sip , Rohan Mahy , Dean Willis Date: Fri, 20 Feb 2004 13:06:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 20 Feb 2004 12:06:29.0220 (UTC) FILETIME=[F8CCA240:01C3F7A9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] RE: Defining new requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I don't know how happy it would be, but at least it wouldn't have to spend time on this relatively minor issue :) Regards, Christer > -----Original Message----- > From: Gonzalo Camarillo (JO/LMF) > Sent: 20. helmikuuta 2004 13:55 > To: Christer Holmberg (JO/LMF) > Cc: sip; Rohan Mahy; Dean Willis > Subject: Re: Defining new requests > > > Christer, > > would the ITU-T be happier if we log an errata against the INFO RFC > saying that UASs can send INFO within early dialogs? > > Gonzalo > > Christer Holmberg (JO/LMF) wrote: > > > Hi Gonzalo, > > > > Thanks for your reply! > > > > > >>it seems that some people in the ITU-T are having some issues > >>figuring out whether or not certain requests can be sent by the UAS > > > > within an > > > >>early dialog. The confusion comes from statements like this > >>one (taken from the INFO spec): > >> > >>" Unless stated otherwise, the protocol rules for the > INFO request > >> governing the usage of tags, Route and Record-Route, > >> retransmission and reliability, CSeq incrementing and message > >> formatting follow those in [1] as defined for the > BYE request." > >> > >>Since a UAS does not send BYEs within an early dialog, but > a non-2xx > >>final response instead, to terminate the dialog, people assume that > > > > INFO > > > >>cannot be sent in this situation either. > >> > >>Let's try to keep this in mind and clarify this point when/if > >>we define new SIP methods. > >> > >>In any event, the clarification to this issue can be found in > >>RFC 3398: > >> > >>"From the callee to the caller, if a message is received by > a gateway > >>before the call has been answered (i.e., ANM is received) > >>it SHOULD be encapsulated in an INFO, provided that this will not > >>be the first SIP message sent in the backwards direction (in which > >>case it SHOULD be encapsulated in a provisional 1xx response)." > > > > > > The problem is that the ITU-T interworking spec doesn't reference > > RFC3398. The spec reference the INFO RFC, and that is also > where I think > > the usage rules should be defined (not in another spec, > RFC3398 in this > > case, simply using the method). > > > > The INFO RFC, as you said, currently says that INFO > "follows the rules > > of BYE" (whatever that means is another question :), and > the rules for > > BYE specifically says that it must not be sent backward before the > > INVITE has finished. If the INFO RFC would say "follow the rules of > > UPDATE" we would not have this problem, since the UPDATE spec > > specifically allows the use of the method before the INVITE has > > finished. > > > > Thanks! > > > > Christer Holmberg > > Ericsson Finland > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 13:43:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06177 for ; Fri, 20 Feb 2004 13:43:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFcG-0002fy-2T for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 13:43:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KIhCNn010282 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 13:43:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFc5-0002e9-Oo; Fri, 20 Feb 2004 13:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFbI-0002bv-Se for sip@optimus.ietf.org; Fri, 20 Feb 2004 13:42:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06086 for ; Fri, 20 Feb 2004 13:42:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFbG-0006tG-00 for sip@ietf.org; Fri, 20 Feb 2004 13:42:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFaM-0006oQ-00 for sip@ietf.org; Fri, 20 Feb 2004 13:41:16 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AuFZN-0006fV-00 for sip@ietf.org; Fri, 20 Feb 2004 13:40:13 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 20 Feb 2004 10:39:42 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Feb 2004 10:39:42 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 20 Feb 2004 10:39:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [Sip] SIP instance identifiers Date: Fri, 20 Feb 2004 10:39:54 -0800 Message-ID: Thread-Topic: [Sip] SIP instance identifiers Thread-Index: AcP3c/GFoo55qWQqR6Gy9CfqFvO3IgAYBWCA From: "Orit Levin" To: X-OriginalArrivalTime: 20 Feb 2004 18:39:40.0386 (UTC) FILETIME=[E63AE420:01C3F7E0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F7E0.E1B251F4" ------_=_NextPart_001_01C3F7E0.E1B251F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I tend to agree with Paul (if I read him correctly). =20 I think that GUID and the original GRID parameter are very different things because of their properties (and obviously the resultant usage cases). Below is my view on the topic. =20 1. Global Unique ID: GUID IS a very well-known concept. It is used by many applications outside SIP, but I don't see its direct relation to SIP. I am not sure whether we need a dedicated SIP placeholder for it. For PIDF applications, GRUU is enough, in my opinion (see below). =20 2. GRUU format: GRUU (not GRID or GUID) is a SIP URI and is very SIPish concept with the properties as defined in the GRUU draft. It IS the "SIP Instance Identifier". Being a SIP URI, it can be used in any Presence (e.g. PIDF) applications without changing the defined XML schemas. It may be beneficial to define a URI parameter that says: "This SIP URI has GRUU properties". It will eliminate the need for Supported: gruu in every message and for potential expanding the PIDF documents to include this clarification.=20 =20 3. GRUU signaling and usage: GRUU can be allocated either by Registrar, or by UA, or by different means. My point is GRUU identification (i.e. placement and signaling) during session establishment and usage (especially outside the Registrar domain) MUST be identical for all cases. Moreover, it MUST be possible for the Registrar domain to conceal the information about the allocation method being used. =20 4. Registration Procedure: We need to standardize the registration procedure for both basic cases: GRUU allocated by Server (done) and GRUU allocated by Client. In my opinion, both cases need to be under the Registration/contact umbrella - which makes them SIP concepts! Whether GRUU value is preserved during client's/server's reboots - it doesn't change the concept. From usability point of view, it would be very nice to keep the value as long as possible. From the outside user point of view - it doesn't need to know (and doesn't want to know) what the registration durability of its peers is. =20 5. Saving Registration Cycles and DB size: By using GRUU we have the ability to contact a specific instance of SIP AOR. Once we point to a specific entity, we MAY also need to point to specific sub-entities inside this GRUU. This will save the registration burden from each of these sub-entities, since they will be covered by GRUU's registration and routing. The original GRID parameters allowed for exactly this functionality. The usage example is a conference factory which generates foci and doesn't need to dynamically REGISTER each of them in order to achieve proper routing. BTW, the concept of "internal routing" to specific logical module inside SIP entity can be generalized, decoupled from GRUU and be defined as a dedicated SIP header. =20 Orit. =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, February 19, 2004 9:37 PM To: Cullen Jennings Cc: Jonathan Rosenberg; sip@ietf.org Subject: Re: [Sip] SIP instance identifiers =20 Just to be clear, I am not *advocating* that we need these identifiers=20 any other place. I'm just saying that if there are other uses for a=20 device id, that it won't hurt to use the same id elsewhere. =20 For the purpose we are discussing, it is important that the id be=20 associated with a registered contact, and since REGISTER permits=20 multiple contacts, it really needs to be a parameter on each contact. =20 That is really an entirely different application from identifying which=20 device originated a particular message. If there is a need for that,=20 then it needs to be in some header that can be in any message. I don't=20 recommend we do that until we have a need for it. =20 Paul ------_=_NextPart_001_01C3F7E0.E1B251F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I tend to agree with Paul (if I read him = correctly).

 

I think that GUID and the original GRID parameter are very = different things because of their properties (and obviously the resultant usage = cases).

Below is my view on the topic.

 

1. Global Unique ID: GUID IS a very well-known concept. = It is used by many applications outside SIP, but I don't see its direct = relation to SIP. I am not sure whether we need a dedicated SIP placeholder for it. = For PIDF applications, GRUU is enough, in my opinion (see = below).

 

2. GRUU format: GRUU (not GRID or GUID) is a SIP URI and = is very SIPish concept with the properties as defined in the GRUU draft. It IS = the "SIP Instance Identifier". Being a SIP URI, it can be used in = any Presence (e.g. PIDF) applications without changing the defined XML schemas. It = may be beneficial to define a URI parameter that says: "This SIP URI has GRUU properties". It will eliminate the need for Supported: gruu in = every message and for potential expanding the PIDF documents to include this = clarification.

 

3. GRUU signaling and usage: GRUU can be allocated either = by Registrar, or by UA, or by different means. My point is GRUU = identification (i.e. placement and signaling) during session establishment and usage = (especially outside the Registrar domain) MUST be identical for all cases. Moreover, = it MUST be possible for the Registrar domain to conceal the information = about the allocation method being used.

 

4. Registration Procedure: We need to standardize the registration procedure for both basic cases: GRUU allocated by Server = (done) and GRUU allocated by Client. In my opinion, both cases need to be under = the Registration/contact umbrella - which makes them SIP concepts! Whether GRUU value is = preserved during client's/server's reboots - it doesn't change the concept. From = usability point of view, it would be very nice to keep the value as long as possible. = From the outside user point of view - it doesn't need to know (and doesn't want to know) = what the registration durability of its peers is.

 

5. Saving Registration Cycles and DB size: By using GRUU = we have the ability to contact a specific instance of SIP AOR. Once we point to = a specific entity, we MAY also need to point to specific sub-entities = inside this GRUU. This will save the registration burden from each of these = sub-entities, since they will be covered by GRUU’s registration and routing. The original GRID parameters allowed for exactly this functionality. The = usage example is a conference factory which generates foci and doesn’t = need to dynamically REGISTER each of them in order to achieve proper routing. BTW, the = concept of “internal routing” to specific logical module inside SIP entity can be = generalized, decoupled from GRUU and be defined as a dedicated SIP = header.

 

Orit.

 

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Paul = Kyzivat
Sent: Thursday, February 19, 2004 9:37 PM
To: Cullen Jennings
Cc: Jonathan Rosenberg; sip@ietf.org
Subject: Re: [Sip] SIP instance identifiers

 

Just to be clear, I am not *advocating* that we need these = identifiers

any other place. I'm just saying that if there are other uses = for a

device id, that it won't hurt to use the same id = elsewhere.

 

For the purpose we are discussing, it is important that the id = be

associated with a registered contact, and since REGISTER permits =

multiple contacts, it really needs to be a parameter on each = contact.

 

That is really an entirely different application from = identifying which

device originated a particular message. If there is a need for = that,

then it needs to be in some header that can be in any message. I = don't

recommend we do that until we have a need for = it.

 

      Paul

------_=_NextPart_001_01C3F7E0.E1B251F4-- --------------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 exim@www1.ietf.org Fri Feb 20 16:04:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13600 for ; Fri, 20 Feb 2004 16:04:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHon-00017O-NG for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 16:04:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KL4H47004237 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 16:04:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHoX-00014u-RM; Fri, 20 Feb 2004 16:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHnh-00010F-IP for sip@optimus.ietf.org; Fri, 20 Feb 2004 16:03:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13532 for ; Fri, 20 Feb 2004 16:03:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHng-0001DY-00 for sip@ietf.org; Fri, 20 Feb 2004 16:03:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHmm-0001AO-00 for sip@ietf.org; Fri, 20 Feb 2004 16:02:13 -0500 Received: from [63.126.135.16] (helo=mail1.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AuHm1-00013o-00 for sip@ietf.org; Fri, 20 Feb 2004 16:01:25 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i1KL0jTl000589 for ; Fri, 20 Feb 2004 13:00:48 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Feb 2004 13:00:45 -0800 Message-ID: <017B1BB60535DF4285666089FA048AC20172EFF0@SONOMA.netscreen.com> From: Anil Bollineni To: "'sip@ietf.org'" Date: Fri, 20 Feb 2004 13:00:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F7F4.9B2993A0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] From Port Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F7F4.9B2993A0 Content-Type: text/plain Hi All, For any SIP message, if UA or Proxy sending message than other than from port 5060, then it should be included in SIP from URI. For example, if the Register message comes from 202.10.10.20:2218, the From header should look like From: sip:joe@202.10.10.20:2218. Is it MUST if the port is different than port 5060 then it should appear in the From header? Thanks in Advance, Anil This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. ------_=_NextPart_001_01C3F7F4.9B2993A0 Content-Type: text/html

Hi All,

            For any SIP message, if UA or Proxy sending message than other than from port 5060, then it should be included in SIP from URI. For example, if the Register message comes from 202.10.10.20:2218, the From header should look like From: sip:joe@202.10.10.20:2218. Is it MUST if the port is different than port 5060 then it should appear in the From header?

 

Thanks in Advance,

Anil

This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information.

 

------_=_NextPart_001_01C3F7F4.9B2993A0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 20 19:41:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24927 for ; Fri, 20 Feb 2004 19:41:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLCu-0002xQ-OI for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 19:41:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L0fOdM011305 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 19:41:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLCZ-0002uf-11; Fri, 20 Feb 2004 19:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLBr-0002qo-B0 for sip@optimus.ietf.org; Fri, 20 Feb 2004 19:40:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24902 for ; Fri, 20 Feb 2004 19:40:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuLBp-0002jD-00 for sip@ietf.org; Fri, 20 Feb 2004 19:40:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuLAr-0002gM-00 for sip@ietf.org; Fri, 20 Feb 2004 19:39:18 -0500 Received: from [63.126.135.16] (helo=mail1.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AuLAb-0002dY-00 for sip@ietf.org; Fri, 20 Feb 2004 19:39:02 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i1L0bsTl024457; Fri, 20 Feb 2004 16:37:54 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Feb 2004 16:37:53 -0800 Message-ID: <017B1BB60535DF4285666089FA048AC20172EFF1@SONOMA.netscreen.com> From: Anil Bollineni To: "'sip@ietf.org'" , "'sip-implementors@cs.columbia.edu'" Date: Fri, 20 Feb 2004 16:37:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F812.F0C1FA50" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] From Header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F812.F0C1FA50 Content-Type: text/plain Hi All, I understand from the following statement in RFC, that From header SHOULD not contain IP addresses/ports from whom the request has come. If it is so, I can't assume that the information is not used to assume from where (IP address/port) the request has come. Appreciate your response to clarify the point. As such, it is very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names. Thank you, Anil This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. ------_=_NextPart_001_01C3F812.F0C1FA50 Content-Type: text/html

Hi All,

 

      I understand from the following statement in RFC, that From header SHOULD not contain IP addresses/ports from whom the request has come. If it is so, I can't assume that the information is not used to assume from where (IP address/port) the request has come. Appreciate your response to clarify the point.

 

  As such, it is very important that the From URI not contain IP addresses or the FQDN

   of the host on which the UA is running, since these are not logical

   names.

 

Thank you,

Anil

 

This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information.

 

------_=_NextPart_001_01C3F812.F0C1FA50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 22 18:19:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13590 for ; Sun, 22 Feb 2004 18:19:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av2sV-0003D4-VR for sip-archive@odin.ietf.org; Sun, 22 Feb 2004 18:19:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MNJFHp012277 for sip-archive@odin.ietf.org; Sun, 22 Feb 2004 18:19:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av2sH-0003Bp-Rr; Sun, 22 Feb 2004 18:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av2s3-00037T-JC for sip@optimus.ietf.org; Sun, 22 Feb 2004 18:18:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13560 for ; Sun, 22 Feb 2004 18:18:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av2s0-0001yy-00 for sip@ietf.org; Sun, 22 Feb 2004 18:18:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av2r3-0001wk-00 for sip@ietf.org; Sun, 22 Feb 2004 18:17:46 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Av2qY-0001rx-00 for sip@ietf.org; Sun, 22 Feb 2004 18:17:14 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1MNGar01223 for ; Sun, 22 Feb 2004 17:16:37 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CKAFH0>; Sun, 22 Feb 2004 23:16:35 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B3EF0E9@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Christer Holmberg (JO/LMF)" , "Gonzalo Camarillo (JO/LMF)" , sip Cc: Rohan Mahy , Dean Willis Subject: RE: [Sip] RE: Defining new requests Date: Sun, 22 Feb 2004 23:16:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , While RFC 3398 may appear to clarify this, it is not in the scope of RFC 3398 to do so. RFC 3398 defines only the interworking, not the SIP protocol associated with it. I would suggest a bug fix is tables for the INFO RFC. regards Keith > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 20 February 2004 11:40 > To: Gonzalo Camarillo (JO/LMF); sip > Cc: Rohan Mahy; Dean Willis > Subject: [Sip] RE: Defining new requests > > > > Hi Gonzalo, > > Thanks for your reply! > > >it seems that some people in the ITU-T are having some issues > >figuring out whether or not certain requests can be sent by > the UAS within an > >early dialog. The confusion comes from statements like this > >one (taken from the INFO spec): > > > > " Unless stated otherwise, the protocol rules for the > INFO request > > governing the usage of tags, Route and Record-Route, > > retransmission and reliability, CSeq incrementing and message > > formatting follow those in [1] as defined for the > BYE request." > > > >Since a UAS does not send BYEs within an early dialog, but a non-2xx > >final response instead, to terminate the dialog, people > assume that INFO > >cannot be sent in this situation either. > > > >Let's try to keep this in mind and clarify this point when/if > >we define new SIP methods. > > > >In any event, the clarification to this issue can be found in > >RFC 3398: > > > >"From the callee to the caller, if a message is received by a gateway > >before the call has been answered (i.e., ANM is received) > >it SHOULD be encapsulated in an INFO, provided that this will not > >be the first SIP message sent in the backwards direction (in which > >case it SHOULD be encapsulated in a provisional 1xx response)." > > The problem is that the ITU-T interworking spec doesn't > reference RFC3398. The spec reference the INFO RFC, and that > is also where I think the usage rules should be defined (not > in another spec, RFC3398 in this case, simply using the method). > > The INFO RFC, as you said, currently says that INFO "follows > the rules of BYE" (whatever that means is another question > :), and the rules for BYE specifically says that it must not > be sent backward before the INVITE has finished. If the INFO > RFC would say "follow the rules of UPDATE" we would not have > this problem, since the UPDATE spec specifically allows the > use of the method before the INVITE has finished. > > Thanks! > > Christer Holmberg > Ericsson Finland > > This communication is confidential and intended solely for > the addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has > been sent to you in error, please notify the sender by > replying to this transmission and delete the message without > disclosing it. Thank you. > > E-mail including attachments is susceptible to data > corruption, interruption, unauthorized amendment, tampering > and viruses, and we only send and receive e-mails on the > basis that we are not liable for any such corruption, > interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 23 14:11:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12796 for ; Mon, 23 Feb 2004 14:11:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLUC-00005y-Q5 for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 14:11:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NJBOTa000303 for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 14:11:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLTt-0008OT-HB; Mon, 23 Feb 2004 14:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLTN-0008KW-Gm for sip@optimus.ietf.org; Mon, 23 Feb 2004 14:10:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12768 for ; Mon, 23 Feb 2004 14:10:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvLTL-0001Rq-00 for sip@ietf.org; Mon, 23 Feb 2004 14:10:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvLSL-0001NX-00 for sip@ietf.org; Mon, 23 Feb 2004 14:09:30 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AvLRq-0001Io-00 for sip@ietf.org; Mon, 23 Feb 2004 14:08:58 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1NJ8NZ20573; Mon, 23 Feb 2004 14:08:23 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1FN2B3N5; Mon, 23 Feb 2004 14:08:23 -0500 Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJKHF; Mon, 23 Feb 2004 14:08:24 -0500 Message-ID: <403A4FA6.8040407@nortelnetworks.com> Date: Mon, 23 Feb 2004 14:08:22 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Christer Holmberg (JO/LMF)" , sip , Rohan Mahy , Dean Willis Subject: Re: [Sip] Re: Defining new requests References: <4035F586.1000405@ericsson.com> In-Reply-To: <4035F586.1000405@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The ITU-T (Study Group 11, to be exact) had a different issue with INFO: that the RFC depends on RFC 2543 rather than 3261. As a result, they picked up the content of RFC 2976 as Annex C.3 of the ISUP interworking specification Q.1912.5. If RFC 2976 ever gets updated Annex C.3 can be deprecated. In the meantime, this INFO question means we have some maintenance to perform. I think the best solution will be to take Gonzalo's suggestion and say that INFO follows the rules for UPDATE. We already have a normative dependency on the UPDATE RFC. Gonzalo Camarillo wrote: > Christer, > > would the ITU-T be happier if we log an errata against the INFO RFC > saying that UASs can send INFO within early dialogs? > > Gonzalo > > Christer Holmberg (JO/LMF) wrote: > >> Hi Gonzalo, >> >> Thanks for your reply! >> >> >>> it seems that some people in the ITU-T are having some issues >>> figuring out whether or not certain requests can be sent by the UAS >> >> >> within an >> >>> early dialog. The confusion comes from statements like this one >>> (taken from the INFO spec): >>> >>> " Unless stated otherwise, the protocol rules for the INFO request >>> governing the usage of tags, Route and Record-Route, >>> retransmission and reliability, CSeq incrementing and message >>> formatting follow those in [1] as defined for the BYE request." >>> >>> Since a UAS does not send BYEs within an early dialog, but a non-2xx >>> final response instead, to terminate the dialog, people assume that >> >> >> INFO >> >>> cannot be sent in this situation either. >>> >>> Let's try to keep this in mind and clarify this point when/if we >>> define new SIP methods. >>> >>> In any event, the clarification to this issue can be found in RFC 3398: >>> >>> "From the callee to the caller, if a message is received by a gateway >>> before the call has been answered (i.e., ANM is received) it SHOULD >>> be encapsulated in an INFO, provided that this will not be the first >>> SIP message sent in the backwards direction (in which case it SHOULD >>> be encapsulated in a provisional 1xx response)." >> >> >> >> The problem is that the ITU-T interworking spec doesn't reference >> RFC3398. The spec reference the INFO RFC, and that is also where I think >> the usage rules should be defined (not in another spec, RFC3398 in this >> case, simply using the method). >> >> The INFO RFC, as you said, currently says that INFO "follows the rules >> of BYE" (whatever that means is another question :), and the rules for >> BYE specifically says that it must not be sent backward before the >> INVITE has finished. If the INFO RFC would say "follow the rules of >> UPDATE" we would not have this problem, since the UPDATE spec >> specifically allows the use of the method before the INVITE has >> finished. >> >> Thanks! >> >> Christer Holmberg >> Ericsson Finland > > > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 23 14:16:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13166 for ; Mon, 23 Feb 2004 14:16:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLYk-0000jr-0Y for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 14:16:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NJG5ru002778 for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 14:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLYg-0000f9-JM; Mon, 23 Feb 2004 14:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLYL-0000cO-AD for sip@optimus.ietf.org; Mon, 23 Feb 2004 14:15:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13107 for ; Mon, 23 Feb 2004 14:15:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvLYI-0001wO-00 for sip@ietf.org; Mon, 23 Feb 2004 14:15:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvLXJ-0001qv-00 for sip@ietf.org; Mon, 23 Feb 2004 14:14:38 -0500 Received: from [63.126.135.16] (helo=mail1.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AvLWT-0001fB-00 for sip@ietf.org; Mon, 23 Feb 2004 14:13:45 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i1NJD2Tl021410; Mon, 23 Feb 2004 11:13:02 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Feb 2004 11:13:02 -0800 Message-ID: <017B1BB60535DF4285666089FA048AC20172EFF3@SONOMA.netscreen.com> From: Anil Bollineni To: "'xiao'tong liang'" Cc: "'sip@ietf.org'" , "'sip-implementors@cs.columbia.edu'" Subject: RE: [Sip] From Header Date: Mon, 23 Feb 2004 11:13:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,SUSPICIOUS_RECIPS autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The Via header tells that IP address/port where the response should be sent. It does not specify from where the request has been come, as the ports for sending request and receiving responses can be different. I think the only way we can tell is by seeing the sending ip and port in IP header of the packet. Please correct if I am wrong. Thanks, Anil This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. -----Original Message----- From: xiao'tong liang [mailto:boyliangxt@yahoo.com] Sent: Sunday, February 22, 2004 6:07 PM To: Anil Bollineni Subject: Re: [Sip] From Header Via header. -- xiaotong --- Anil Bollineni wrote: > Hi All, > > > > I understand from the following statement in > RFC, that From header > SHOULD not contain IP addresses/ports from whom the > request has come. If it > is so, I can't assume that the information is not > used to assume from where > (IP address/port) the request has come. Appreciate > your response to clarify > the point. > > > > As such, it is very important that the From URI > not contain IP addresses > or the FQDN > > of the host on which the UA is running, since > these are not logical > > names. > > > > Thank you, > > Anil > > > > This email contains material that is confidential. > The content of this email > is for the sole use of the intended recipient(s). > Any review or distribution > by persons other than the intended recipient(s) > without the express > permission of NetScreen Technologies, Inc. is > strictly prohibited. If you > are not the intended recipient, please contact the > sender and delete/destroy > all copies of this email and any related > attachments. NetScreen does not > guarantee the accuracy or completeness of third > party materials or > information. > > > > __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 23 14:39:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14824 for ; Mon, 23 Feb 2004 14:39:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLv3-0002fk-Ot for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 14:39:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NJd9xQ010209 for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 14:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLuv-0002dL-PK; Mon, 23 Feb 2004 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLuP-0002aM-Pk for sip@optimus.ietf.org; Mon, 23 Feb 2004 14:38:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14779 for ; Mon, 23 Feb 2004 14:38:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvLuN-0004hk-00 for sip@ietf.org; Mon, 23 Feb 2004 14:38:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvLtT-0004dP-00 for sip@ietf.org; Mon, 23 Feb 2004 14:37:32 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvLsx-0004Xf-00 for sip@ietf.org; Mon, 23 Feb 2004 14:36:59 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Feb 2004 11:46:25 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1NJaQ4U020798; Mon, 23 Feb 2004 11:36:27 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG17744; Mon, 23 Feb 2004 14:36:25 -0500 (EST) Message-ID: <403A5639.30303@cisco.com> Date: Mon, 23 Feb 2004 14:36:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: sip@ietf.org Subject: Re: [Sip] SIP instance identifiers References: Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA14780 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Orit Levin wrote: > I tend to agree with Paul (if I read him correctly). I think maybe you don't read me as intended, because I don't entirely=20 agree with you here. (At least if I understand you.) > I think that GUID and the original GRID parameter are very different=20 > things because of their properties (and obviously the resultant usage=20 > cases). If you are talking about the grid=3Dxxx parameter that Jonathan has=20 proposed be used with GRUUs, then I don't think it has any signficance=20 to this discussion at all. > Below is my view on the topic. >=20 > 1. _Global Unique ID:_ GUID IS a very well-known concept. It is used by= =20 > many applications outside SIP, but I don't see its direct relation to=20 > SIP. I am not sure whether we need a dedicated SIP placeholder for it.=20 > For PIDF applications, GRUU is enough, in my opinion (see below). I don't know that anyone is talking about this. But we are talking about=20 a slightly more restricted concept - a Device ID. Conceivably a device=20 could use a guid as its device id, but that is largely irrelevant to=20 this discussion. > 2. _GRUU format:_ GRUU (not GRID or GUID) is a SIP URI and is very=20 > SIPish concept with the properties as defined in the GRUU draft. It IS=20 > the "SIP Instance Identifier". The last sentence is debatable. It is *an* endpoint instance identifier=20 that is sip routable. But it isn't necessarily defined for as long as=20 the device(s) it references are. And it isn't necessarily bound to the=20 same device at all times. I think you may have missed the point that the device id is distinct=20 from the GRUU, though dependent upon it. Many different GRUUs may share=20 the same device id. I am proposing that the device id be represented as=20 a URI, but not necessarily (generally not) a sip uri. Generally I expect=20 a URN to be used. > 3. _GRUU signaling and usage:_ GRUU can be allocated either by=20 > Registrar, or by UA, or by different means. My point is GRUU=20 > identification (i.e. placement and signaling) during session=20 > establishment and usage (especially outside the Registrar domain) MUST=20 > be identical for all cases. Moreover, it MUST be possible for the=20 > Registrar domain to conceal the information about the allocation method= =20 > being used. >=20 > 4. _Registration Procedure:_ We need to standardize the registration=20 > procedure for both basic cases: GRUU allocated by Server (done) and GRU= U=20 > allocated by Client. In my opinion, both cases need to be under the=20 > Registration/contact umbrella - which makes them SIP concepts! Whether=20 > GRUU value is preserved during client's/server's reboots - it doesn't=20 > change the concept. From usability point of view, it would be very nice= =20 > to keep the value as long as possible. >From the outside user point of=20 > view - it doesn't need to know (and doesn't want to know) what the=20 > registration durability of its peers is. Jonathan should probably chime in here. I believe he argues that=20 typically a UA can't tell whether it can generate its own GRUU, so they=20 should always be assigned by registrars. > 5. _Saving Registration Cycles and DB size_: By using GRUU we have the=20 > ability to contact a specific instance of SIP AOR. Once we point to a=20 > specific entity, we MAY also need to point to specific sub-entities=20 > inside this GRUU. This will save the registration burden from each of=20 > these sub-entities, since they will be covered by GRUU=92s registration= =20 > and routing. The original GRID parameters allowed for exactly this=20 > functionality. The usage example is a conference factory which generate= s=20 > foci and doesn=92t need to dynamically REGISTER each of them in order t= o=20 > achieve proper routing. BTW, the concept of =93internal routing=94 to=20 > specific logical module inside SIP entity can be generalized, decoupled= =20 > from GRUU and be defined as a dedicated SIP header. Maybe it can be decoupled from GRUU, but I think it must be coupled to a=20 URL, not a message. So it must be a URL formatting convention and/or a=20 url parameter. So maybe you could generalize the grid parameter to apply=20 to all sip/sips urls, rather than coupling it to gruu. I haven't thought=20 thru where that might be useful. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 23 16:10:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19965 for ; Mon, 23 Feb 2004 16:10:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNLB-0002DI-WD for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 16:10:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NLAD08008445 for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 16:10:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNL1-0002BR-HD; Mon, 23 Feb 2004 16:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNKR-00028c-8t for sip@optimus.ietf.org; Mon, 23 Feb 2004 16:09:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19913 for ; Mon, 23 Feb 2004 16:09:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvNKP-0003wa-00 for sip@ietf.org; Mon, 23 Feb 2004 16:09:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvNJR-0003sA-00 for sip@ietf.org; Mon, 23 Feb 2004 16:08:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AvNIZ-0003l9-00 for sip@ietf.org; Mon, 23 Feb 2004 16:07:31 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1NL6v1m014730; Mon, 23 Feb 2004 13:06:58 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG27034; Mon, 23 Feb 2004 16:06:56 -0500 (EST) Message-ID: <403A6B70.7080301@cisco.com> Date: Mon, 23 Feb 2004 16:06:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohan@cisco.com CC: sip@ietf.org, "Orit Levin" , "Francois Audet" References: <200402172137.QAA07482@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-mahy-sip-remote-cc-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I find the newest version of this draft troubling. It feels to me like it has selected a slippery slope and is already accelerating rapidly downward. My major concern is with the approach described in section 4: Alternatively, the Refer-To URI could be a Universal Resource Name (URN) [21] which could describe a particular operation such as Hold or Retrieve. Combined with the dialog-identifiers of an existing session conveyed as parameters of the Refer-To header, this would permit explicit operations which do not need additional parameters or handle more than a single session. For example, the following could represent a Hold operation of a session with the Call-ID "123": Refer-To: ;call-id=123;remote-tag=aaa;local-tag=bbb Further examples are given abstractly, for example: -------------------------------- | Remote Call Control Body | | transfer | | FirstCall= | | sip:line1@192.168.0.5 | | call-id:456 | | remote-tag=uvw | | local-tag=xyz | | SecondCall= | | sip:cathy@example.net | | other parameters | -------------------------------- My concern is that this appears to be defining an explicit feature invocation model, with specific features that have names and parameters. While it could conceivably be in scope for IETF to define things to this level, in the past the sip wg has avoided doing so. If that philosophy is to change, then I think we must consider all the implications of doing so. I think every feature of this sort will require a considerable effort to specify in sufficient detail so that interoperation is assured. It may be that we are already in that situation with REFER and just haven't realized it yet, but I am inclined to think this makes that situation worse. I don't think the features as described go far enough to define their semantics. In particular, I think it is difficult to define the meaning of these features without addressing media handling and the management of explicit UI components of the endpoint. For instance, what does MakeCall imply about the UI and media handling on the device that is to make a call? Is the user alerted first, with the device awaiting an off-hook before completing the call? Or are the microphone and speaker in the handset activated for media even though the phone is on-hook? If the device is capable of using multiple media, which are enabled in the call? The questions abound. More generally, must all endpoints that support extended-refer support every feature that might be named in a Remote Call Control Body? If so, how do we evolve the set of features? If not, how does a UA determine what features it can invoke, and how? The approach of simply enhancing Refer-To with header parameters that simplify the construction of complex referred operations is more bounded, and less likely to present issues in the future. Of course it may or may not be sufficient for the kinds of call control people may want to do remotely. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Feb 23 16:22:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20571 for ; Mon, 23 Feb 2004 16:22:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNWk-0002v2-LS for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 16:22:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NLMAbj011214 for sip-archive@odin.ietf.org; Mon, 23 Feb 2004 16:22:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNWb-0002tk-SQ; Mon, 23 Feb 2004 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNW4-0002sJ-Nx for sip@optimus.ietf.org; Mon, 23 Feb 2004 16:21:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20525 for ; Mon, 23 Feb 2004 16:21:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvNW2-0004ro-00 for sip@ietf.org; Mon, 23 Feb 2004 16:21:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvNVA-0004oC-00 for sip@ietf.org; Mon, 23 Feb 2004 16:20:33 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AvNUR-0004gD-00 for sip@ietf.org; Mon, 23 Feb 2004 16:19:47 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 23 Feb 2004 13:18:08 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Feb 2004 13:19:16 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 13:19:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP instance identifiers Date: Mon, 23 Feb 2004 13:19:15 -0800 Message-ID: Thread-Topic: [Sip] SIP instance identifiers Thread-Index: AcP6RHilq77kPP2SRnmknSrZwAgopwADLlXA From: "Orit Levin" To: "Paul Kyzivat" , X-OriginalArrivalTime: 23 Feb 2004 21:19:15.0863 (UTC) FILETIME=[B0E5FA70:01C3FA52] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Whatever the overlap in our views is, what is in the scope of this discussion and what is out of the scope - is a point of view based on the applications each of us is familiar with. If we=20 - have both the GRUU concept and the GRID concept as URI parameters - allow a user to allocated its own device identifier (which needs to be "globally" unique within its AOR scope only) - allow a Registrar to override the user allocated GRUU and replace it with Registrar generated value (if required according to local policies) it will satisfy the requirements of the applications that I am familiar with. Orit.=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, February 23, 2004 11:36 AM To: Orit Levin Cc: sip@ietf.org Subject: Re: [Sip] SIP instance identifiers Orit Levin wrote: > I tend to agree with Paul (if I read him correctly). I think maybe you don't read me as intended, because I don't entirely agree with you here. (At least if I understand you.) > I think that GUID and the original GRID parameter are very different=20 > things because of their properties (and obviously the resultant usage=20 > cases). If you are talking about the grid=3Dxxx parameter that Jonathan has proposed be used with GRUUs, then I don't think it has any signficance to this discussion at all. > Below is my view on the topic. >=20 > 1. _Global Unique ID:_ GUID IS a very well-known concept. It is used=20 > by many applications outside SIP, but I don't see its direct relation=20 > to SIP. I am not sure whether we need a dedicated SIP placeholder for it. > For PIDF applications, GRUU is enough, in my opinion (see below). I don't know that anyone is talking about this. But we are talking about a slightly more restricted concept - a Device ID. Conceivably a device could use a guid as its device id, but that is largely irrelevant to this discussion. > 2. _GRUU format:_ GRUU (not GRID or GUID) is a SIP URI and is very=20 > SIPish concept with the properties as defined in the GRUU draft. It IS > the "SIP Instance Identifier". The last sentence is debatable. It is *an* endpoint instance identifier that is sip routable. But it isn't necessarily defined for as long as the device(s) it references are. And it isn't necessarily bound to the same device at all times. I think you may have missed the point that the device id is distinct from the GRUU, though dependent upon it. Many different GRUUs may share the same device id. I am proposing that the device id be represented as a URI, but not necessarily (generally not) a sip uri. Generally I expect a URN to be used. > 3. _GRUU signaling and usage:_ GRUU can be allocated either by=20 > Registrar, or by UA, or by different means. My point is GRUU=20 > identification (i.e. placement and signaling) during session=20 > establishment and usage (especially outside the Registrar domain) MUST > be identical for all cases. Moreover, it MUST be possible for the=20 > Registrar domain to conceal the information about the allocation=20 > method being used. >=20 > 4. _Registration Procedure:_ We need to standardize the registration=20 > procedure for both basic cases: GRUU allocated by Server (done) and=20 > GRUU allocated by Client. In my opinion, both cases need to be under=20 > the Registration/contact umbrella - which makes them SIP concepts!=20 > Whether GRUU value is preserved during client's/server's reboots - it=20 > doesn't change the concept. From usability point of view, it would be=20 > very nice to keep the value as long as possible. >From the outside=20 > user point of view - it doesn't need to know (and doesn't want to=20 > know) what the registration durability of its peers is. Jonathan should probably chime in here. I believe he argues that typically a UA can't tell whether it can generate its own GRUU, so they should always be assigned by registrars. > 5. _Saving Registration Cycles and DB size_: By using GRUU we have the > ability to contact a specific instance of SIP AOR. Once we point to a=20 > specific entity, we MAY also need to point to specific sub-entities=20 > inside this GRUU. This will save the registration burden from each of=20 > these sub-entities, since they will be covered by GRUU's registration=20 > and routing. The original GRID parameters allowed for exactly this=20 > functionality. The usage example is a conference factory which=20 > generates foci and doesn't need to dynamically REGISTER each of them=20 > in order to achieve proper routing. BTW, the concept of "internal=20 > routing" to specific logical module inside SIP entity can be=20 > generalized, decoupled from GRUU and be defined as a dedicated SIP header. Maybe it can be decoupled from GRUU, but I think it must be coupled to a URL, not a message. So it must be a URL formatting convention and/or a url parameter. So maybe you could generalize the grid parameter to apply to all sip/sips urls, rather than coupling it to gruu. I haven't thought thru where that might be useful. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 24 00:06:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13968 for ; Tue, 24 Feb 2004 00:06:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUlq-0001ml-U2 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 00:06:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O56EPc006800 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 00:06:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUle-0001ku-Bx; Tue, 24 Feb 2004 00:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUlN-0001jU-ER for sip@optimus.ietf.org; Tue, 24 Feb 2004 00:05:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13921 for ; Tue, 24 Feb 2004 00:05:41 -0500 (EST) From: ranjit.avasarala@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvUlL-0005xC-00 for sip@ietf.org; Tue, 24 Feb 2004 00:05:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvUkP-0005rv-00 for sip@ietf.org; Tue, 24 Feb 2004 00:04:46 -0500 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1AvUje-0005hx-00 for sip@ietf.org; Tue, 24 Feb 2004 00:03:59 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1O53QqA004817 for ; Tue, 24 Feb 2004 10:33:26 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 24 Feb 2004 10:34:26 +0530 Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Feb 2004 10:33:25 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] From Header Date: Tue, 24 Feb 2004 10:33:25 +0530 Message-ID: Thread-Topic: [Sip] From Header Thread-Index: AcP6QYpFb0302AXqSp6JDD6/9myKwQAUt4qQ To: , Cc: , X-OriginalArrivalTime: 24 Feb 2004 05:03:25.0353 (UTC) FILETIME=[887CE990:01C3FA93] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Anil, If I understand you correctly then I think you want to know the sender's IP and port number. This information can be obtaine from the SDP. Via header gives information of Proxy not of sender's. Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Anil Bollineni Sent: Tuesday, February 24, 2004 12:43 AM To: 'xiao'tong liang' Cc: 'sip@ietf.org'; 'sip-implementors@cs.columbia.edu' Subject: RE: [Sip] From Header The Via header tells that IP address/port where the response should be sent. It does not specify from where the request has been come, as the ports for sending request and receiving responses can be different. I think the only way we can tell is by seeing the sending ip and port in IP header of the packet. Please correct if I am wrong. Thanks, Anil This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. -----Original Message----- From: xiao'tong liang [mailto:boyliangxt@yahoo.com]=20 Sent: Sunday, February 22, 2004 6:07 PM To: Anil Bollineni Subject: Re: [Sip] From Header Via header. -- xiaotong --- Anil Bollineni wrote: > Hi All, >=20 > =20 >=20 > I understand from the following statement in > RFC, that From header > SHOULD not contain IP addresses/ports from whom the > request has come. If it > is so, I can't assume that the information is not > used to assume from where > (IP address/port) the request has come. Appreciate > your response to clarify > the point. >=20 > =20 >=20 > As such, it is very important that the From URI > not contain IP addresses > or the FQDN >=20 > of the host on which the UA is running, since > these are not logical >=20 > names. >=20 > =20 >=20 > Thank you, >=20 > Anil >=20 > =20 >=20 > This email contains material that is confidential. > The content of this email > is for the sole use of the intended recipient(s). > Any review or distribution > by persons other than the intended recipient(s) > without the express > permission of NetScreen Technologies, Inc. is > strictly prohibited. If you > are not the intended recipient, please contact the > sender and delete/destroy > all copies of this email and any related > attachments. NetScreen does not > guarantee the accuracy or completeness of third > party materials or > information. >=20 > =20 >=20 >=20 __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 24 02:35:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04806 for ; Tue, 24 Feb 2004 02:35:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvX65-00056j-9Y for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 02:35:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O7ZHdq019633 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 02:35:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvX5r-00054i-Py; Tue, 24 Feb 2004 02:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvX5d-00052m-KN for sip@optimus.ietf.org; Tue, 24 Feb 2004 02:34:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04761 for ; Tue, 24 Feb 2004 02:34:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvX5Z-00055z-00 for sip@ietf.org; Tue, 24 Feb 2004 02:34:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvX4h-00052A-00 for sip@ietf.org; Tue, 24 Feb 2004 02:33:51 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvX3m-0004yS-00 for sip@ietf.org; Tue, 24 Feb 2004 02:32:55 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1O7WsAh007548 for ; Tue, 24 Feb 2004 08:32:54 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 08:32:54 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FKWDRK5R; Tue, 24 Feb 2004 08:32:54 +0100 Message-ID: <403AFE24.9020504@ericsson.com> Date: Tue, 24 Feb 2004 09:32:52 +0200 X-Sybari-Trust: ba4df9cf c77f3eb6 59788f6c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: "Christer Holmberg (JO/LMF)" , sip , Rohan Mahy , Dean Willis Subject: Re: [Sip] Re: Defining new requests References: <4035F586.1000405@ericsson.com> <403A4FA6.8040407@nortelnetworks.com> In-Reply-To: <403A4FA6.8040407@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 07:32:54.0807 (UTC) FILETIME=[6AB2FA70:01C3FAA8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, what is the timeframe here? As you know, we have had discussions in the past about either re-defining INFO so that it can only carry PSTN telephony signalling, or defining INFO packages. We could re-start those discussions, and once we reach a conclusion, clarify the rules to send INFO from the UAS within early dialogs in the same spec... If the ITU is in a hurry, other solutions may be better, like logging an errata against the INFO RFC. Gonzalo Tom Taylor wrote: > The ITU-T (Study Group 11, to be exact) had a different issue with INFO: > that the RFC depends on RFC 2543 rather than 3261. As a result, they > picked up the content of RFC 2976 as Annex C.3 of the ISUP interworking > specification Q.1912.5. If RFC 2976 ever gets updated Annex C.3 can be > deprecated. In the meantime, this INFO question means we have some > maintenance to perform. I think the best solution will be to take > Gonzalo's suggestion and say that INFO follows the rules for UPDATE. We > already have a normative dependency on the UPDATE RFC. > > Gonzalo Camarillo wrote: > >> Christer, >> >> would the ITU-T be happier if we log an errata against the INFO RFC >> saying that UASs can send INFO within early dialogs? >> >> Gonzalo >> >> Christer Holmberg (JO/LMF) wrote: >> >>> Hi Gonzalo, >>> >>> Thanks for your reply! >>> >>> >>>> it seems that some people in the ITU-T are having some issues >>>> figuring out whether or not certain requests can be sent by the UAS >>> >>> >>> >>> within an >>> >>>> early dialog. The confusion comes from statements like this one >>>> (taken from the INFO spec): >>>> >>>> " Unless stated otherwise, the protocol rules for the INFO request >>>> governing the usage of tags, Route and Record-Route, >>>> retransmission and reliability, CSeq incrementing and message >>>> formatting follow those in [1] as defined for the BYE request." >>>> >>>> Since a UAS does not send BYEs within an early dialog, but a non-2xx >>>> final response instead, to terminate the dialog, people assume that >>> >>> >>> >>> INFO >>> >>>> cannot be sent in this situation either. >>>> >>>> Let's try to keep this in mind and clarify this point when/if we >>>> define new SIP methods. >>>> >>>> In any event, the clarification to this issue can be found in RFC 3398: >>>> >>>> "From the callee to the caller, if a message is received by a gateway >>>> before the call has been answered (i.e., ANM is received) it SHOULD >>>> be encapsulated in an INFO, provided that this will not be the first >>>> SIP message sent in the backwards direction (in which case it SHOULD >>>> be encapsulated in a provisional 1xx response)." >>> >>> >>> >>> >>> The problem is that the ITU-T interworking spec doesn't reference >>> RFC3398. The spec reference the INFO RFC, and that is also where I think >>> the usage rules should be defined (not in another spec, RFC3398 in this >>> case, simply using the method). >>> >>> The INFO RFC, as you said, currently says that INFO "follows the rules >>> of BYE" (whatever that means is another question :), and the rules for >>> BYE specifically says that it must not be sent backward before the >>> INVITE has finished. If the INFO RFC would say "follow the rules of >>> UPDATE" we would not have this problem, since the UPDATE spec >>> specifically allows the use of the method before the INVITE has >>> finished. >>> >>> Thanks! >>> >>> Christer Holmberg >>> Ericsson Finland >> This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 24 02:56:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05380 for ; Tue, 24 Feb 2004 02:56:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXQJ-0006Vn-6B for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 02:56:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O7uBf0024952 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 02:56:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXQB-0006SB-4O; Tue, 24 Feb 2004 02:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXPx-0006RT-Bf for sip@optimus.ietf.org; Tue, 24 Feb 2004 02:55:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05372 for ; Tue, 24 Feb 2004 02:55:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvXPt-0006a7-00 for sip@ietf.org; Tue, 24 Feb 2004 02:55:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvXOx-0006Wt-00 for sip@ietf.org; Tue, 24 Feb 2004 02:54:48 -0500 Received: from [80.74.106.10] (helo=rvil-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1AvXOE-0006Tc-00 for sip@ietf.org; Tue, 24 Feb 2004 02:54:02 -0500 Received: from rvil-mail.radvision.com [172.20.2.102] by rvil-mail.radvision.com with XWall v3.28 ; Tue, 24 Feb 2004 09:55:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2004 09:55:26 +0200 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B0479F9@rvil-mail.radvision.com> Thread-Topic: RPORT and TCP Thread-Index: AcP6q5ANss4LKXxKTByLwpyT0NZaoQ== From: "Sarit Galanos" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] RPORT and TCP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi,=20 RFC 3581-Symmetric Response Routing specifies that the rport parameter = should be used only if the transport is unreliable. "When a server attempts to send a response, it examines the topmost Via header field value of that response. If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and the port in the "rport" parameter. The response MUST be sent from the same address and port that the corresponding request was received on. This effectively adds a new processing step between bullets two and three in Section 18.2.2 of SIP [1]." As I see it, the same problem that rport solves in UDP can happen in = TCP. This can happen if the connection is broken between the request and the = response. If for example the Via header in the request is: Via: SIP/2.0/TCP proxy.example.com;branch=3Dz9hG4bKkjsh77 and proxy.example.com was resolved to a port different then 5060, the = server will not be able to=20 establish a new connection in order to send the response since 5060 will = be used. Why do we have the UDP limitation in the standard? How can such a problem be solved. Regards, Sarit. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 24 04:45:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09470 for ; Tue, 24 Feb 2004 04:45:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZ82-0006n2-2s for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 04:45:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O9jQpk026035 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 04:45:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZ7f-0006kG-3Q; Tue, 24 Feb 2004 04:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZ7T-0006jh-AN for sip@optimus.ietf.org; Tue, 24 Feb 2004 04:44:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09422 for ; Tue, 24 Feb 2004 04:44:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZ7P-00008V-00 for sip@ietf.org; Tue, 24 Feb 2004 04:44:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZ6S-00003Q-00 for sip@ietf.org; Tue, 24 Feb 2004 04:43:49 -0500 Received: from [62.119.82.43] (helo=hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 1AvZ5c-0007iY-00 for sip@ietf.org; Tue, 24 Feb 2004 04:42:56 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip-implementors] RE: [Sip] From Header Date: Tue, 24 Feb 2004 10:42:26 +0100 Message-ID: Thread-Topic: [Sip-implementors] RE: [Sip] From Header Thread-Index: AcP6QUkfDOfnD87qRv+rmEyz94dmvwAeQgoQ From: "Christian Jansson" To: "Anil Bollineni" , "xiao'tong liang" Cc: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > I think the only way we can tell=20 > is by seeing the sending ip and port in IP header of the=20 > packet. Please correct if I am wrong. Correct. / Christian Jansson, Hotsip R&D _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 24 04:52:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09697 for ; Tue, 24 Feb 2004 04:52:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZEe-0007FJ-Cm for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 04:52:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O9qE6M027791 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 04:52:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZES-0007Ct-0c; Tue, 24 Feb 2004 04:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZDb-00079l-7O for sip@optimus.ietf.org; Tue, 24 Feb 2004 04:51:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09661 for ; Tue, 24 Feb 2004 04:51:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZDY-0000hh-00 for sip@ietf.org; Tue, 24 Feb 2004 04:51:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZCb-0000cA-00 for sip@ietf.org; Tue, 24 Feb 2004 04:50:09 -0500 Received: from [62.119.82.43] (helo=hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 1AvZC4-0000Vl-00 for sip@ietf.org; Tue, 24 Feb 2004 04:49:37 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip-implementors] RE: [Sip] From Header Date: Tue, 24 Feb 2004 10:49:07 +0100 Message-ID: Thread-Topic: [Sip-implementors] RE: [Sip] From Header Thread-Index: AcP6QYpFb0302AXqSp6JDD6/9myKwQAUt4qQAAmG6xA= From: "Christian Jansson" To: , , Cc: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ranjit wrote: > If I understand you correctly then I think you want to know=20 > the sender's IP and port number. This information can be=20 > obtaine from the SDP. No the sender address and port should not be obtained from the SDP. The IP and port found in the SDP only tells the receiver where to send media, nothing else. The IP in the SDP does not have to be the same IP as from where the SIP signaling is done. The port in the SDP will probably always differ from the port from where the SIP signaling is done (I don't think any implementation would like to demux SIP and media on the same port) / Christian Jansson, Hotsip R&D _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 24 08:54:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20153 for ; Tue, 24 Feb 2004 08:54:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avd0s-0006kj-EU for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 08:54:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ODsITv025830 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 08:54:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avd0b-0006fa-No; Tue, 24 Feb 2004 08:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuElD-00061F-JX for sip@optimus.ietf.org; Fri, 20 Feb 2004 12:48:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03642 for ; Fri, 20 Feb 2004 12:48:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuElB-0003A6-00 for sip@ietf.org; Fri, 20 Feb 2004 12:48:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuEkK-00034M-00 for sip@ietf.org; Fri, 20 Feb 2004 12:47:29 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AuEjY-0002xk-00 for sip@ietf.org; Fri, 20 Feb 2004 12:46:40 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i1KHke1q029583 for ; Fri, 20 Feb 2004 10:46:40 -0700 (MST) Received: from artibeus.nsr.labs.mot.com (artibeus.nsr.labs.mot.com [173.23.95.73]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i1KHcoMx020131 for ; Fri, 20 Feb 2004 11:38:51 -0600 Received: from motorola.com (artibeus.nsr.labs.mot.com [173.23.95.73]) by artibeus.nsr.labs.mot.com (Postfix) with ESMTP id CD5643800A; Fri, 20 Feb 2004 11:41:49 -0600 (CST) Message-ID: <403646DD.802@motorola.com> Date: Fri, 20 Feb 2004 11:41:49 -0600 From: Bryan Thale Organization: Networks & Infrastructure Research, Motorola Labs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Cc: sip@ietf.org Subject: Re: [Sip] Binary Encoding for SIP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > >So I take if you would be happy to see is say that things SHOULD send binary >but need to be prepared to receive anything. > > Yep. Bryan. -- Bryan Thale Networks & Infrastructure Research, Motorola Labs mailto:bryan.thale@motorola.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 24 09:40:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20151 for ; Tue, 24 Feb 2004 08:54:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avd0s-0006ki-E6 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 08:54:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ODsIIv025833 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 08:54:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avd0d-0006fm-5R; Tue, 24 Feb 2004 08:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJiB-0008LD-HL for sip@optimus.ietf.org; Mon, 23 Feb 2004 12:17:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06818 for ; Mon, 23 Feb 2004 12:17:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJiA-0006dg-00 for sip@ietf.org; Mon, 23 Feb 2004 12:17:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJh9-0006Vl-00 for sip@ietf.org; Mon, 23 Feb 2004 12:16:39 -0500 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by ietf-mx with esmtp (Exim 4.12) id 1AvJgN-0006Pe-00 for sip@ietf.org; Mon, 23 Feb 2004 12:15:51 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i1NHFpcD059670 for ; Mon, 23 Feb 2004 12:15:51 -0500 (EST) Received: from aura.cs.bell-labs.com (aura.cs.bell-labs.com [135.104.8.15]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i1NHFiws077229 for ; Mon, 23 Feb 2004 12:15:44 -0500 (EST) Received: from research.bell-labs.com (gokul-pcmh.research.bell-labs.com [135.104.47.56]) by aura.cs.bell-labs.com (8.12.9/8.12.9) with ESMTP id i1NHFhGA019077 for ; Mon, 23 Feb 2004 12:15:43 -0500 (EST) Message-ID: <403A36D6.9030904@research.bell-labs.com> Date: Mon, 23 Feb 2004 12:22:30 -0500 From: Gokul Prabhakar User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] On creating SIP services using Java applet encoding. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi I am recent to the group and have been reading and getting interested about encodings in SIP (e.g MIME encoding proposal postings by Cullen). I also noted that Henning in one of his papers (Oct 2000, IEEE Comm magazine), refers to a work where Java applets were proposed to be included in SIP requests for service creation. I am interested if there is any progress made in this specific aspect? In fact, encoding executable content on SIP requests can be powerful abstraction and can be usefully utized for a lot of other things (not only service creation). But it can also create otentially serious security issues... (This is also somewhat similar to binary MIME encodings in SIP, in which case the question arises how such encodings are interpreted.) I am just wondering if any work is done on this.. Thanks & Regards, Gokul Pl post reply to the MG and not to me. Thx. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Feb 24 14:03:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04260 for ; Tue, 24 Feb 2004 14:03:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhpz-0007cR-46 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 14:03:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OJ3MQh029225 for sip-archive@odin.ietf.org; Tue, 24 Feb 2004 14:03:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhpd-0007Ud-Iq; Tue, 24 Feb 2004 14:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhom-0007OM-LC for sip@optimus.ietf.org; Tue, 24 Feb 2004 14:02:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04141 for ; Tue, 24 Feb 2004 14:02:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avhok-000695-00 for sip@ietf.org; Tue, 24 Feb 2004 14:02:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avhnm-00062x-00 for sip@ietf.org; Tue, 24 Feb 2004 14:01:06 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1Avhmn-0005sS-00 for sip@ietf.org; Tue, 24 Feb 2004 14:00:05 -0500 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1OIxSsa022406; Tue, 24 Feb 2004 12:59:28 -0600 Message-ID: <403B9F10.6040403@softarmor.com> Date: Tue, 24 Feb 2004 12:59:28 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org CC: rohan@cisco.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Agenda, IETF 59 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hyperlinked version posted at: http://www.softarmor.com/sipwg/meets/ietf59/agenda.html Please try and get any slides in well in advance. Note that GRUU-related stuff appears on both SIPPING and SIP agendas. The idea is to discuss requirements in SIPPING and mechanism in SIP. Monday, March 1, 2002 1300-1500 Crystal 1/2 1300 Status and Charter Milestones, Working Model Chairs 1320 Request History Mary Barnes draft-ietf-sip-history-info-02.txt 1330 VoiceMail URIs Cullen Jennings draft-jennings-sip-voicemail-uri-01.txt draft-jennings-sip-voicemail-uri-01.html 1340 Wrapping up MIME Body Part Usage Cullen Jennings draft-jennings-sip-mime-01.txt draft-jennings-sip-mime-01.html 1350 Policy URI and Purpose Hisham Khartabil draft-khartabil-sip-policy-uri-call-info-purpose-00 1400 Authentication Issues draft-khartabil-sip-auth-analysis-00.txt 1410 Non-Invite Transactions Robert Sparks draft-sparks-sip-nit-problems-00.txt draft-sparks-sip-nit-actions-00.txt draft-sparks-sip-nit-future-00.txt 1425 GRUU and Device ID Mechanisms Jonathan Rosenberg, Brian Stucker and Cullen Jennings draft-ietf-sip-gruu-01.txt draft-stucker-sip-guid-00.txt draft-jennings-sipping-instance-id-00.txt [html] 1500 Close _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 00:48:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28926 for ; Wed, 25 Feb 2004 00:48:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avru7-000559-8W for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 00:48:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P5mJ0x019471 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 00:48:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avrtq-00052o-0l; Wed, 25 Feb 2004 00:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvrtR-000524-17 for sip@optimus.ietf.org; Wed, 25 Feb 2004 00:47:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28876 for ; Wed, 25 Feb 2004 00:47:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvrtO-0006hy-00 for sip@ietf.org; Wed, 25 Feb 2004 00:47:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avrsd-0006c8-00 for sip@ietf.org; Wed, 25 Feb 2004 00:46:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Avrrh-0006Nn-00 for sip@ietf.org; Wed, 25 Feb 2004 00:45:49 -0500 Received: from dynamicsoft.com ([63.113.46.31]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1P5jUNr008990 for ; Wed, 25 Feb 2004 00:45:31 -0500 (EST) Message-ID: <403C3668.7040306@dynamicsoft.com> Date: Wed, 25 Feb 2004 00:45:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] changes in session timer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I submitted a revision of the session timer, based on comments received from IESG and subsequent list discussion. For some reason, this submission was not processed by the I-D editor (I'm working to correct that). In the mean time, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-session-timer-14.txt There are a few significant changes: * Formerly, if a session refresh timed out, the UA waited until 1/3 of the session interval remained before sending a BYE. This contradicts RFC3261 which basically says to send a BYE immediately. Session timer now references that behavior. * There is now an absolute minimum session timer of 90 seconds. This is basically enough time for completion of a SIP BYE transaction after half of the session has expired. The Min-SE header field now has a default value of 90 seconds when not present. This will preclude usage of session timer for really fine grained refreshes, say on the order of 5 to 10 seconds. I fear that some people may be trying to do some kind of nat traversal or something with session timer - this would rule that out formally (it was never the intended usage). * The default for session-expires, when not present, used to be "infinity". However, thats not really right. Really, it means "undefined", and session expiration is then up to local policy of the proxy. Using infinity would mean that a proxy could never clean up state. Please comment ASAP if you have any problems with these changes. We'd like to get session timer moving along. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 05:01:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07604 for ; Wed, 25 Feb 2004 05:01:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avvr4-0008GG-Hh for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 05:01:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PA1QUY031755 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 05:01:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avvqj-0008Es-Rj; Wed, 25 Feb 2004 05:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvqX-0008DE-UR for sip@optimus.ietf.org; Wed, 25 Feb 2004 05:00:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07595 for ; Wed, 25 Feb 2004 05:00:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvqU-0002VQ-00 for sip@ietf.org; Wed, 25 Feb 2004 05:00:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avvpb-0002PG-00 for sip@ietf.org; Wed, 25 Feb 2004 04:59:55 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Avvp7-0002JB-00 for sip@ietf.org; Wed, 25 Feb 2004 04:59:25 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1P9xLK07637; Wed, 25 Feb 2004 11:59:21 +0200 (EET) X-Scanned: Wed, 25 Feb 2004 11:58:53 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1P9wrcn020197; Wed, 25 Feb 2004 11:58:53 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00haFN0V; Wed, 25 Feb 2004 11:58:51 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1P9wn726528; Wed, 25 Feb 2004 11:58:49 +0200 (EET) Received: from nokia.com ([172.21.39.149]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 25 Feb 2004 11:58:42 +0200 Message-ID: <403C71D2.6020002@nokia.com> Date: Wed, 25 Feb 2004 11:58:42 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Rohan Mahy CC: "'sip@ietf.org'" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-publish-03.txt References: <200402162041.PAA20081@ietf.org> <3B05A58F-6215-11D8-9B6B-0003938AF740@cisco.com> In-Reply-To: <3B05A58F-6215-11D8-9B6B-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 09:58:42.0622 (UTC) FILETIME=[F3375DE0:01C3FB85] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Rohan, ext Rohan Mahy wrote: > Hi Folks, > > I just noticed a minor problem with publish ; it defines a new response > code: > > 412 Precondition Failed > > which is confusingly similar to the existing response code: > > 580 Precondition Failure > > I propose changing The reason phrase for 412 to "Publication Condition > Failed" Good point. A question though: since we're borrowing this response code from HTTP, how strictly do we need to keep the reason phrases aligned? I assume it's enough that the semantics are the same, and the default reason phrase can therefore be different. Also, to generalize, would: 412 (Conditional Request Failed) be better? Cheers, Aki > > thanks, > -rohan > > > On Feb 16, 2004, at 12:41 PM, 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 : Session Initiation Protocol (SIP) Extension for >> Event State >> Publication >> Author(s) : A. Niemi >> Filename : draft-ietf-sip-publish-03.txt >> Pages : 40 >> Date : 2004-2-16 >> >> This document describes an extension to the Session Initiation >> Protocol (SIP) for publishing event state used within the framework >> for SIP Event Notification. The first application of this extension >> is targeted at the publication of presence information. >> The mechanism described in this document can be extended to support >> publication of any event state, for which there exists an appropriate >> event package. It is not intended to be a general-purpose mechanism >> for transport of arbitrary data, as there are better-suited >> mechanisms for this purpose (FTP, HTTP, etc.) >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-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-publish-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-publish-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. >> Content-Type: text/plain >> Content-ID: <2004-2-16123306.I-D@ietf.org> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 05:29:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09262 for ; Wed, 25 Feb 2004 05:29:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwIF-0002Q2-Vk for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 05:29:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PATVJV009297 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 05:29:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwHl-0002Od-TN; Wed, 25 Feb 2004 05:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwHZ-0002O5-5x for sip@optimus.ietf.org; Wed, 25 Feb 2004 05:28:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09244 for ; Wed, 25 Feb 2004 05:28:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvwHV-0005ZK-00 for sip@ietf.org; Wed, 25 Feb 2004 05:28:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvwGU-0005Ur-00 for sip@ietf.org; Wed, 25 Feb 2004 05:27:43 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AvwFm-0005QI-00 for sip@ietf.org; Wed, 25 Feb 2004 05:26:59 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PAQwqY025909 for ; Wed, 25 Feb 2004 11:26:58 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 11:26:58 +0100 Received: from ericsson.com (rvi2-92-155.sw.ericsson.se [153.88.92.155]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBMGCA; Wed, 25 Feb 2004 11:26:57 +0100 Message-ID: <403C786E.3070501@ericsson.com> Date: Wed, 25 Feb 2004 12:26:54 +0200 X-Sybari-Trust: 8bf2635e c77f3eb6 b2f8f052 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'hisham.khartabil@nokia.com'" CC: Jonathan Rosemberg , sip , aki.niemi@nokia.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 10:26:58.0637 (UTC) FILETIME=[E61EB7D0:01C3FB89] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Call-Info purpose Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hisham, in your draft below, you mention that Jonathan pointed out that: " It was also discovered that there was no IANA registry set up for the "purpose" parameter in the Call-info header of the Session Initiation Protocol [1]. This document sets up the IANA registry." http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00 When I check the registry, defined in the draft below, I can see that "purpose" was already registered (page 6). http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry-01.txt Header Field Parameter Name Reference ____________________________________________________________ [...] Call-Info purpose RFC 3261 Regards, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 08:31:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15874 for ; Wed, 25 Feb 2004 08:31:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avz84-0000KE-B0 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 08:31:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PDVCRf001249 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 08:31:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avz7u-0000JN-Vt; Wed, 25 Feb 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avz7b-0000IC-FO for sip@optimus.ietf.org; Wed, 25 Feb 2004 08:30:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15849 for ; Wed, 25 Feb 2004 08:30:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avz7a-0007Pk-00 for sip@ietf.org; Wed, 25 Feb 2004 08:30:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avz6d-0007KA-00 for sip@ietf.org; Wed, 25 Feb 2004 08:29:44 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1Avz5h-0007BC-00 for sip@ietf.org; Wed, 25 Feb 2004 08:28:45 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1PDSAFh016770 for ; Wed, 25 Feb 2004 08:28:10 -0500 (EST) Received: from sonusmail02.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Wed, 25 Feb 2004 08:28:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Feb 2004 08:28:01 -0500 Message-ID: <05AE95C39E8E2642AF9C04526EDAC4145694@sonusmail02.sonusnet.com> Thread-Topic: [Sip] changes in session timer Thread-Index: AcP7YwlMZJLlX09CSsqRXz6YfIgR7gAPvtyA From: "Bharrat, Shaun" To: "Jonathan Rosenberg" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Question re: session timer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi: No problems with the following changes. However, a different question. Can someone explain the rational for not allowing a proxy/UAS to _increase_ the session expiration before=20 accepting it? I understand that the proxy/UAS can effect this increase by responding with the 422 but then every call (from that UAC) requires multiple INVITE exchanges. Is it=20 really the case that we expect the UAC to get a 422 and decide=20 it doesn't want the call after all because the session expiration=20 would be too big? In any event, if this were the case, couldn't=20 the UAC just BYE the call at that point? Thanks in advance for the info. Cheers, Shaun Shaun Bharrat Sonus Networks www.sonusnet.com The Voice of the New Public Network =20 >-----Original Message----- >From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of >Jonathan Rosenberg >Sent: Wednesday, February 25, 2004 12:45 AM >To: sip@ietf.org >Subject: [Sip] changes in session timer > > >Folks, > >I submitted a revision of the session timer, based on comments=20 >received=20 >from IESG and subsequent list discussion. For some reason, this=20 >submission was not processed by the I-D editor (I'm working to correct=20 >that). In the mean time, you can pick it up at: > >http://www.jdrosen.net/papers/draft-ietf-sip-session-timer-14.txt > > >There are a few significant changes: > >* Formerly, if a session refresh timed out, the UA waited until 1/3 of=20 >the session interval remained before sending a BYE. This contradicts=20 >RFC3261 which basically says to send a BYE immediately. Session timer=20 >now references that behavior. > >* There is now an absolute minimum session timer of 90=20 >seconds. This is=20 >basically enough time for completion of a SIP BYE transaction=20 >after half=20 >of the session has expired. The Min-SE header field now has a default=20 >value of 90 seconds when not present. This will preclude usage of=20 >session timer for really fine grained refreshes, say on the order of 5=20 >to 10 seconds. I fear that some people may be trying to do=20 >some kind of=20 >nat traversal or something with session timer - this would=20 >rule that out=20 >formally (it was never the intended usage). > >* The default for session-expires, when not present, used to be=20 >"infinity". However, thats not really right. Really, it means=20 >"undefined", and session expiration is then up to local policy of the=20 >proxy. Using infinity would mean that a proxy could never=20 >clean up state. > > >Please comment ASAP if you have any problems with these changes. We'd=20 >like to get session timer moving along. > >-Jonathan R. > >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 08:58:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16786 for ; Wed, 25 Feb 2004 08:58:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvzYK-0002G2-SJ for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 08:58:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PDwK9d008618 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 08:58:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvzY2-0002Dk-6r; Wed, 25 Feb 2004 08:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvzXo-0002DJ-3W for sip@optimus.ietf.org; Wed, 25 Feb 2004 08:57:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16756 for ; Wed, 25 Feb 2004 08:57:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvzXm-00021L-00 for sip@ietf.org; Wed, 25 Feb 2004 08:57:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvzWu-0001wg-00 for sip@ietf.org; Wed, 25 Feb 2004 08:56:53 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AvzW5-0001mC-00 for sip@ietf.org; Wed, 25 Feb 2004 08:56:01 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCVBAW>; Wed, 25 Feb 2004 08:55:31 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B645C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] changes in session timer Date: Wed, 25 Feb 2004 08:55:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > * There is now an absolute minimum session timer of 90 > seconds. This is > basically enough time for completion of a SIP BYE transaction > after half > of the session has expired. The Min-SE header field now has a default > value of 90 seconds when not present. This will preclude usage of > session timer for really fine grained refreshes, say on the > order of 5 > to 10 seconds. I fear that some people may be trying to do > some kind of > nat traversal or something with session timer - this would > rule that out > formally (it was never the intended usage). I know whenever we bring up billing people turn off, but one of the things session timer is useful for is to tear down calls that got hosed somewhere. Making the min 90 seconds means you could not use the mechanism -- you would have to have some other mechanism that didn't distort your billing record so much. 90 seconds is an eternity in human time. Somehow, precluding use for NAT binding keepalive doesn't sound like a good enough reason to have such a high min. I frankly don't understand why there has to be a min at all; surely it depends on the characteristics of the network the session traverses. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 09:32:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17949 for ; Wed, 25 Feb 2004 09:32:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw05I-0005RV-IS for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 09:32:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEWOCZ020920 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 09:32:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw04v-0005LX-Ij; Wed, 25 Feb 2004 09:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw04l-0005IR-2c for sip@optimus.ietf.org; Wed, 25 Feb 2004 09:31:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17905 for ; Wed, 25 Feb 2004 09:31:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw04j-0005SN-00 for sip@ietf.org; Wed, 25 Feb 2004 09:31:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw03t-0005NF-00 for sip@ietf.org; Wed, 25 Feb 2004 09:30:58 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aw033-0005Hj-00 for sip@ietf.org; Wed, 25 Feb 2004 09:30:05 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1PEToK12623; Wed, 25 Feb 2004 16:29:51 +0200 (EET) X-Scanned: Wed, 25 Feb 2004 16:29:16 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1PETGK4000338; Wed, 25 Feb 2004 16:29:16 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 005THdcs; Wed, 25 Feb 2004 16:29:15 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1PESp715672; Wed, 25 Feb 2004 16:28:51 +0200 (EET) Received: from nokia.com ([172.21.80.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 25 Feb 2004 16:28:48 +0200 Message-ID: <403CB120.6060506@nokia.com> Date: Wed, 25 Feb 2004 16:28:48 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Gonzalo Camarillo CC: "'hisham.khartabil@nokia.com'" , Jonathan Rosemberg , sip References: <403C786E.3070501@ericsson.com> In-Reply-To: <403C786E.3070501@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 14:28:48.0565 (UTC) FILETIME=[AEB60650:01C3FBAB] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Call-Info purpose Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Gonzalo, You're right - the parameter registration is handled by the below draft. But what is missing is a registry for the 'purpose' values. That's what we're porposing to set up, and populate with the already defined set of {icon, info, card} per RFC3261, and the new proposed 'policy-uri' value. Cheers, Aki ext Gonzalo Camarillo wrote: > Hisham, > > in your draft below, you mention that Jonathan pointed out that: > > " It was also discovered that there was no IANA registry set up for the > "purpose" parameter in the Call-info header of the Session Initiation > Protocol [1]. This document sets up the IANA registry." > > http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00 > > > When I check the registry, defined in the draft below, I can see that > "purpose" was already registered (page 6). > > http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry-01.txt > > > Header Field Parameter Name Reference > ____________________________________________________________ > > [...] > > Call-Info purpose RFC 3261 > > Regards, > > Gonzalo > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 09:41:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18487 for ; Wed, 25 Feb 2004 09:41:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0Dp-0006sz-ES for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 09:41:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEfDNr026407 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 09:41:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0Df-0006pl-T1; Wed, 25 Feb 2004 09:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0DQ-0006nw-7O for sip@optimus.ietf.org; Wed, 25 Feb 2004 09:40:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18476 for ; Wed, 25 Feb 2004 09:40:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0DO-0006aO-00 for sip@ietf.org; Wed, 25 Feb 2004 09:40:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0CR-0006V8-00 for sip@ietf.org; Wed, 25 Feb 2004 09:39:48 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw0BV-0006Kl-00 for sip@ietf.org; Wed, 25 Feb 2004 09:38:49 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1PEcFuA022285; Wed, 25 Feb 2004 06:38:15 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGH62632; Wed, 25 Feb 2004 09:38:14 -0500 (EST) Message-ID: <403CB355.8050506@cisco.com> Date: Wed, 25 Feb 2004 09:38:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] changes in session timer References: <403C3668.7040306@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: ... > * The default for session-expires, when not present, used to be > "infinity". However, thats not really right. Really, it means > "undefined", and session expiration is then up to local policy of the > proxy. Using infinity would mean that a proxy could never clean up state. I see a problem with this change. What you say makes sense for proxies, but it doesn't make sense for a UAC or UAS. For them, infinity is the right default, because in this case they don't refresh. In the absence of a session-expires the UAC and UAS can't know the proxy's policy. Perhaps the wording needs separated out for proxy and UA. The new wording is: The default value of the Session-Expires header field is undefined. This means that absence of the Session-Expires header field implies no expiration of the session using the mechanism defined in this specification. Note that other mechanisms not defined in this specification, such as locally configured timers, may apply. while the old wording was: The default value of the Session-Expires header field, when not present, is infinity. This means that absence of the Session-Expires header field implies no expiration. How about the following as a compromise: The default value of the Session-Expires header field, when not present, is infinity. For UAC and UAS this means that absence of the Session-Expires header field implies the session timer will never expire, so no BYE will be sent on expiration, and no refreshes will be performed. This also implies that proxies must make their own determination of how long to retain state in the absence of any messages within the dialog. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 10:11:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20331 for ; Wed, 25 Feb 2004 10:11:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0go-0005C7-Ki for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 10:11:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PFBA6k019958 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 10:11:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0gh-00059X-73; Wed, 25 Feb 2004 10:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0gc-00057o-O6 for sip@optimus.ietf.org; Wed, 25 Feb 2004 10:10:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20267 for ; Wed, 25 Feb 2004 10:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0ga-0001zW-00 for sip@ietf.org; Wed, 25 Feb 2004 10:10:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0fg-0001uE-00 for sip@ietf.org; Wed, 25 Feb 2004 10:10:01 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0fG-0001oS-00 for sip@ietf.org; Wed, 25 Feb 2004 10:09:34 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PF9XYG020617 for ; Wed, 25 Feb 2004 16:09:33 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 16:09:33 +0100 Received: from ericsson.com (rvi2-92-155.sw.ericsson.se [153.88.92.155]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLCB0BR; Wed, 25 Feb 2004 16:09:42 +0100 Message-ID: <403CBAA8.7040005@ericsson.com> Date: Wed, 25 Feb 2004 17:09:28 +0200 X-Sybari-Trust: acf090d0 c77f3eb6 0a449737 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: "'hisham.khartabil@nokia.com'" , Jonathan Rosemberg , sip References: <403C786E.3070501@ericsson.com> <403CB120.6060506@nokia.com> In-Reply-To: <403CB120.6060506@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 15:09:33.0349 (UTC) FILETIME=[5FEA7550:01C3FBB1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Call-Info purpose Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, yes, when we were creating the registries for header field and URI parameters I thought of creating another registry for the values of some parameters (e.g., the one you are dealing with)... but given the huge amount of discussions we had on the other registries, I gave up for the time being... In any case, I will check what is going on with the IANA and get back to you... Gonzalo Aki Niemi wrote: > Hi Gonzalo, > > You're right - the parameter registration is handled by the below draft. > But what is missing is a registry for the 'purpose' values. That's what > we're porposing to set up, and populate with the already defined set of > {icon, info, card} per RFC3261, and the new proposed 'policy-uri' value. > > Cheers, > Aki > > ext Gonzalo Camarillo wrote: > >> Hisham, >> >> in your draft below, you mention that Jonathan pointed out that: >> >> " It was also discovered that there was no IANA registry set up for the >> "purpose" parameter in the Call-info header of the Session Initiation >> Protocol [1]. This document sets up the IANA registry." >> >> http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00 >> >> >> When I check the registry, defined in the draft below, I can see that >> "purpose" was already registered (page 6). >> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry-01.txt >> >> >> Header Field Parameter Name Reference >> ____________________________________________________________ >> >> [...] >> >> Call-Info purpose RFC 3261 >> >> Regards, >> >> Gonzalo >> >> >> This communication is confidential and intended solely for the >> addressee(s). Any unauthorized review, use, disclosure or distribution >> is prohibited. If you believe this message has been sent to you in >> error, please notify the sender by replying to this transmission and >> delete the message without disclosing it. Thank you. >> >> E-mail including attachments is susceptible to data corruption, >> interruption, unauthorized amendment, tampering and viruses, and we >> only send and receive e-mails on the basis that we are not liable for >> any such corruption, interception, amendment, tampering or viruses or >> any consequences thereof. >> -- 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 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 10:16:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20893 for ; Wed, 25 Feb 2004 10:16:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0la-000741-6I for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 10:16:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PFG6md027123 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 10:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0lX-00071h-6U; Wed, 25 Feb 2004 10:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0kW-0006mN-Sq for sip@optimus.ietf.org; Wed, 25 Feb 2004 10:15:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20740 for ; Wed, 25 Feb 2004 10:14:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0kU-0002QA-00 for sip@ietf.org; Wed, 25 Feb 2004 10:14:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0jg-0002Kf-00 for sip@ietf.org; Wed, 25 Feb 2004 10:14:09 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw0j8-0002Ct-00 for sip@ietf.org; Wed, 25 Feb 2004 10:13:34 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1PFDBNr009115; Wed, 25 Feb 2004 10:13:12 -0500 (EST) Message-ID: <403CBB72.8070907@dynamicsoft.com> Date: Wed, 25 Feb 2004 10:12:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Aki Niemi , "'hisham.khartabil@nokia.com'" , sip References: <403C786E.3070501@ericsson.com> <403CB120.6060506@nokia.com> <403CBAA8.7040005@ericsson.com> In-Reply-To: <403CBAA8.7040005@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Call-Info purpose Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Hi, > > yes, when we were creating the registries for header field and URI > parameters I thought of creating another registry for the values of some > parameters (e.g., the one you are dealing with)... but given the huge > amount of discussions we had on the other registries, I gave up for the > time being... > > In any case, I will check what is going on with the IANA and get back to > you... Check for what? The absence of this registry is a bug in RFC3261; it should have been created there (indeed, its mentioned in the spec, but there are no IANA considerations associated with it). So, we need to set it up. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 10:48:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23233 for ; Wed, 25 Feb 2004 10:48:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1GB-0003CT-IK for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 10:47:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PFlhuB012300 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 10:47:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1FX-00031X-Op; Wed, 25 Feb 2004 10:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1FN-00030g-98 for sip@optimus.ietf.org; Wed, 25 Feb 2004 10:46:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23124 for ; Wed, 25 Feb 2004 10:46:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1FK-0005yl-00 for sip@ietf.org; Wed, 25 Feb 2004 10:46:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw1EQ-0005sV-00 for sip@ietf.org; Wed, 25 Feb 2004 10:45:55 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1DW-0005mx-00 for sip@ietf.org; Wed, 25 Feb 2004 10:44:58 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PFivqY018078 for ; Wed, 25 Feb 2004 16:44:57 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 16:44:57 +0100 Received: from ericsson.com (rvi2-92-155.sw.ericsson.se [153.88.92.155]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLCCJLN; Wed, 25 Feb 2004 16:45:08 +0100 Message-ID: <403CC2F6.3080408@ericsson.com> Date: Wed, 25 Feb 2004 17:44:54 +0200 X-Sybari-Trust: 2a58f545 c77f3eb6 0a449737 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Aki Niemi , "'hisham.khartabil@nokia.com'" , sip References: <403C786E.3070501@ericsson.com> <403CB120.6060506@nokia.com> <403CBAA8.7040005@ericsson.com> <403CBB72.8070907@dynamicsoft.com> In-Reply-To: <403CBB72.8070907@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 15:44:57.0506 (UTC) FILETIME=[52031820:01C3FBB6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Call-Info purpose Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan, > Check for what? as you know, we both agree on this, and that's why we set both registries up... nevertheless, I have heard from the IANA (and from the IESG about the IANA) that they are overloaded and that we should not hold our breath waiting for the RFCs-to-be defining the registries to be published as RFCs... Since we will have *many* RFCs-to-be that will depend on these registries and on any new registry we may need to create, I want to make sure that the IANA understands that we are in a hurry. That's whay I am going to check... Gonzalo Jonathan Rosenberg wrote: > > > Gonzalo Camarillo wrote: > >> Hi, >> >> yes, when we were creating the registries for header field and URI >> parameters I thought of creating another registry for the values of >> some parameters (e.g., the one you are dealing with)... but given the >> huge amount of discussions we had on the other registries, I gave up >> for the time being... >> >> In any case, I will check what is going on with the IANA and get back >> to you... > > > Check for what? The absence of this registry is a bug in RFC3261; it > should have been created there (indeed, its mentioned in the spec, but > there are no IANA considerations associated with it). So, we need to set > it up. > > -Jonathan R. > -- 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 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 12:20:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00960 for ; Wed, 25 Feb 2004 12:20:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2hl-0003Sx-Ht for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 12:20:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PHKHCM013259 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 12:20:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2hc-0003Pv-23; Wed, 25 Feb 2004 12:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2hR-0003Nl-Al for sip@optimus.ietf.org; Wed, 25 Feb 2004 12:19:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00938 for ; Wed, 25 Feb 2004 12:19:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw2hQ-000354-00 for sip@ietf.org; Wed, 25 Feb 2004 12:19:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw2gW-00030j-00 for sip@ietf.org; Wed, 25 Feb 2004 12:19:01 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw2fx-0002tj-00 for sip@ietf.org; Wed, 25 Feb 2004 12:18:25 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2004 09:28:56 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1PHHquA004967; Wed, 25 Feb 2004 09:17:53 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQP94584; Wed, 25 Feb 2004 09:17:51 -0800 (PST) In-Reply-To: <403C71D2.6020002@nokia.com> References: <200402162041.PAA20081@ietf.org> <3B05A58F-6215-11D8-9B6B-0003938AF740@cisco.com> <403C71D2.6020002@nokia.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , Rohan Mahy From: Rohan Mahy Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-publish-03.txt Date: Wed, 25 Feb 2004 09:18:32 -0800 To: Aki Niemi X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Aki, I'm fine with your proposal. thx, -r On Feb 25, 2004, at 1:58 AM, Aki Niemi wrote: > Hi Rohan, > > > > ext Rohan Mahy wrote: >> Hi Folks, >> I just noticed a minor problem with publish ; it defines a new >> response code: >> 412 Precondition Failed >> which is confusingly similar to the existing response code: >> 580 Precondition Failure >> I propose changing The reason phrase for 412 to "Publication >> Condition Failed" > > Good point. A question though: since we're borrowing this response > code from HTTP, how strictly do we need to keep the reason phrases > aligned? I assume it's enough that the semantics are the same, and the > default reason phrase can therefore be different. > > Also, to generalize, would: > > 412 (Conditional Request Failed) > > be better? > > Cheers, > Aki > >> thanks, >> -rohan >> On Feb 16, 2004, at 12:41 PM, 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 : Session Initiation Protocol (SIP) Extension for >>> Event State >>> Publication >>> Author(s) : A. Niemi >>> Filename : draft-ietf-sip-publish-03.txt >>> Pages : 40 >>> Date : 2004-2-16 >>> This document describes an extension to the Session Initiation >>> Protocol (SIP) for publishing event state used within the framework >>> for SIP Event Notification. The first application of this extension >>> is targeted at the publication of presence information. >>> The mechanism described in this document can be extended to support >>> publication of any event state, for which there exists an appropriate >>> event package. It is not intended to be a general-purpose mechanism >>> for transport of arbitrary data, as there are better-suited >>> mechanisms for this purpose (FTP, HTTP, etc.) >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-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-publish-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-publish-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. >>> Content-Type: text/plain >>> Content-ID: <2004-2-16123306.I-D@ietf.org> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 15:03:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09106 for ; Wed, 25 Feb 2004 15:03:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5FR-0004pW-KE for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 15:03:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PK3Dtt018558 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 15:03:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5FF-0004c3-CV; Wed, 25 Feb 2004 15:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5EX-0003ph-3T for sip@optimus.ietf.org; Wed, 25 Feb 2004 15:02:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09038 for ; Wed, 25 Feb 2004 15:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5EU-0004HS-00 for sip@ietf.org; Wed, 25 Feb 2004 15:02:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5Di-00049E-00 for sip@ietf.org; Wed, 25 Feb 2004 15:01:27 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Cb-0003sn-00 for sip@ietf.org; Wed, 25 Feb 2004 15:00:17 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1PJxg018152; Wed, 25 Feb 2004 14:59:42 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FS3C88R2; Wed, 25 Feb 2004 14:59:43 -0500 Received: from nortelnetworks.com (acart1ec.ca.nortel.com [47.129.129.121]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJLDV; Wed, 25 Feb 2004 14:59:41 -0500 Message-ID: <403CFEAD.3050300@nortelnetworks.com> Date: Wed, 25 Feb 2004 14:59:41 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Christer Holmberg (JO/LMF)" , sip , Rohan Mahy , Dean Willis References: <4035F586.1000405@ericsson.com> <403A4FA6.8040407@nortelnetworks.com> <403AFE24.9020504@ericsson.com> In-Reply-To: <403AFE24.9020504@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] INFO Documentation (was Re: Defining new requests) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Q.1912.5 is in the process of final approval. Logging errata may be satisfactory -- I'd have to check. It would certainly be more comfortable than reproducing the RFC with modifications in the ITU document. If the IETF acts within the next two weeks we should be able to remove the Annex from the Recommendation. Here is the current list of changes as reported at the beginning of the Annex. "The SIP INFO method is documented in RFC 2976. However, that RFC refers to RFC 2543, the previous version of the SIP specification, rather than to RFC 3261. The text of this Annex reproduces RFC 2976 with changes to reflect the updated reference. "The changes made are as follows: "Paragraph C.3.2.1: The references to the tables of RFC2543 were changed to reflect the new table organization in RFC 3261. "Paragraph C.3.2: The tables 1 and 2 were replaced by new tables that show the header fields defined as presented in RFC3261. All additional headers (additional to RFC 2543) used within RFC3261 were here set to optional with two exceptions. The Reply-To (only optional for the INVITE) and Call-Info Header (only used for INVITE, OPTIONS, REGISTER to give additional information about the caller or callee) are not used with the INFO method. "Paragraph C.3.6: The reference was changed to the current SIP specification, RFC 3261. Gonzalo Camarillo wrote: > Tom, > > what is the timeframe here? As you know, we have had discussions in the > past about either re-defining INFO so that it can only carry PSTN > telephony signalling, or defining INFO packages. We could re-start those > discussions, and once we reach a conclusion, clarify the rules to send > INFO from the UAS within early dialogs in the same spec... > > If the ITU is in a hurry, other solutions may be better, like logging an > errata against the INFO RFC. > > Gonzalo > > Tom Taylor wrote: > >> The ITU-T (Study Group 11, to be exact) had a different issue with >> INFO: that the RFC depends on RFC 2543 rather than 3261. As a result, >> they picked up the content of RFC 2976 as Annex C.3 of the ISUP >> interworking specification Q.1912.5. If RFC 2976 ever gets updated >> Annex C.3 can be deprecated. In the meantime, this INFO question >> means we have some maintenance to perform. I think the best solution >> will be to take Gonzalo's suggestion and say that INFO follows the >> rules for UPDATE. We already have a normative dependency on the >> UPDATE RFC. >> >> Gonzalo Camarillo wrote: >> >>> Christer, >>> >>> would the ITU-T be happier if we log an errata against the INFO RFC >>> saying that UASs can send INFO within early dialogs? >>> >>> Gonzalo >>> >>> Christer Holmberg (JO/LMF) wrote: >>> >>>> Hi Gonzalo, >>>> >>>> Thanks for your reply! >>>> >>>> >>>>> it seems that some people in the ITU-T are having some issues >>>>> figuring out whether or not certain requests can be sent by the UAS >>>> >>>> >>>> >>>> >>>> within an >>>> >>>>> early dialog. The confusion comes from statements like this one >>>>> (taken from the INFO spec): >>>>> >>>>> " Unless stated otherwise, the protocol rules for the INFO request >>>>> governing the usage of tags, Route and Record-Route, >>>>> retransmission and reliability, CSeq incrementing and message >>>>> formatting follow those in [1] as defined for the BYE request." >>>>> >>>>> Since a UAS does not send BYEs within an early dialog, but a >>>>> non-2xx final response instead, to terminate the dialog, people >>>>> assume that >>>> >>>> >>>> >>>> >>>> INFO >>>> >>>>> cannot be sent in this situation either. >>>>> >>>>> Let's try to keep this in mind and clarify this point when/if we >>>>> define new SIP methods. >>>>> >>>>> In any event, the clarification to this issue can be found in RFC >>>>> 3398: >>>>> >>>>> "From the callee to the caller, if a message is received by a gateway >>>>> before the call has been answered (i.e., ANM is received) it SHOULD >>>>> be encapsulated in an INFO, provided that this will not be the >>>>> first SIP message sent in the backwards direction (in which case it >>>>> SHOULD be encapsulated in a provisional 1xx response)." >>>> >>>> >>>> >>>> >>>> >>>> The problem is that the ITU-T interworking spec doesn't reference >>>> RFC3398. The spec reference the INFO RFC, and that is also where I >>>> think >>>> the usage rules should be defined (not in another spec, RFC3398 in this >>>> case, simply using the method). >>>> >>>> The INFO RFC, as you said, currently says that INFO "follows the rules >>>> of BYE" (whatever that means is another question :), and the rules for >>>> BYE specifically says that it must not be sent backward before the >>>> INVITE has finished. If the INFO RFC would say "follow the rules of >>>> UPDATE" we would not have this problem, since the UPDATE spec >>>> specifically allows the use of the method before the INVITE has >>>> finished. >>>> >>>> Thanks! >>>> >>>> Christer Holmberg >>>> Ericsson Finland >>> >>> > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 15:24:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11498 for ; Wed, 25 Feb 2004 15:24:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Zh-00072Q-Lm for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 15:24:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKO9ab026992 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 15:24:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Za-0006zk-KY; Wed, 25 Feb 2004 15:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Yb-0006e2-QP for sip@optimus.ietf.org; Wed, 25 Feb 2004 15:23:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11449 for ; Wed, 25 Feb 2004 15:22:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Ya-0006qU-00 for sip@ietf.org; Wed, 25 Feb 2004 15:23:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5Xf-0006lr-00 for sip@ietf.org; Wed, 25 Feb 2004 15:22:04 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Wq-0006ch-00 for sip@ietf.org; Wed, 25 Feb 2004 15:21:12 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1PKKMNr009351; Wed, 25 Feb 2004 15:20:23 -0500 (EST) Message-ID: <403D0370.5080902@dynamicsoft.com> Date: Wed, 25 Feb 2004 15:20:00 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anil Bollineni CC: "'xiao'tong liang'" , "'sip@ietf.org'" , "'sip-implementors@cs.columbia.edu'" Subject: Re: [Sip] From Header References: <017B1BB60535DF4285666089FA048AC20172EFF3@SONOMA.netscreen.com> In-Reply-To: <017B1BB60535DF4285666089FA048AC20172EFF3@SONOMA.netscreen.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Responses are sent to the Via address, though more commonly to the source IP/port of the request when TCP is used, or when rport is used (RFC 3581) with UDP. The IP/port in the Via effectively provide a fallback, to be used for the server to re-initiate a connection to the client in the event of failure to send the response. Subsequent requests in a dialog are sent to the Contact URI. From is a logical identifier, used for display and policy purposes. Please, please don't muck with it. Let me take this opportunity to preach a little on the role of ALGs in a network. As a general rule, ALGs are quite problematic. They don't work in conjunction with most of the SIP security mechanisms, including S/MIME but more importantly sips and TLS. Their spotty presence in a network, generally undetectable to application entities in the network, cannot be depended on, and therefore can never serve as a complete solution for an application service provider. Worse yet, when (and I say when, not if) one of these ALGs does something wrong that breaks a call flow, it becomes almost impossible to diagnose and correct. Generally speaking, application layer intelligence does not belong in the core of the network; that brings us back to the days of single-service networks where the whole network needs to be upgraded to support a new application. ALGs are contrary to the hourglass model that is one of the defining characteristics of IP. I much prefer solutions like ICE, STUN, TURN and MIDCOM, which separate application layer intelligence from firewalls and NATs, and allow for applications to do the right thing for themselves for the purposes of NAT traversal. As such, the right model is to NOT build an ALG, but if you must, build a full protocol-compliant entity that just so happens to ship with and be co-resident in your firewall/nat. That entity must be directly addressed by other SIP entities, rather than being a transparent element in the network. It is only through this model that we can create robust and secure SIP networks. -Jonathan R. Anil Bollineni wrote: > The Via header tells that IP address/port where the response should be sent. > It does not specify from where the request has been come, as the ports for > sending request and receiving responses can be different. I think the only > way we can tell is by seeing the sending ip and port in IP header of the > packet. Please correct if I am wrong. > > Thanks, > Anil > > > This email contains material that is confidential. The content of this email > is for the sole use of the intended recipient(s). Any review or distribution > by persons other than the intended recipient(s) without the express > permission of NetScreen Technologies, Inc. is strictly prohibited. If you > are not the intended recipient, please contact the sender and delete/destroy > all copies of this email and any related attachments. NetScreen does not > guarantee the accuracy or completeness of third party materials or > information. > > > -----Original Message----- > From: xiao'tong liang [mailto:boyliangxt@yahoo.com] > Sent: Sunday, February 22, 2004 6:07 PM > To: Anil Bollineni > Subject: Re: [Sip] From Header > > Via header. > > -- > xiaotong > > > --- Anil Bollineni wrote: > >>Hi All, >> >> >> >> I understand from the following statement in >>RFC, that From header >>SHOULD not contain IP addresses/ports from whom the >>request has come. If it >>is so, I can't assume that the information is not >>used to assume from where >>(IP address/port) the request has come. Appreciate >>your response to clarify >>the point. >> >> >> >> As such, it is very important that the From URI >>not contain IP addresses >>or the FQDN >> >> of the host on which the UA is running, since >>these are not logical >> >> names. >> >> >> >>Thank you, >> >>Anil >> >> >> >>This email contains material that is confidential. >>The content of this email >>is for the sole use of the intended recipient(s). >>Any review or distribution >>by persons other than the intended recipient(s) >>without the express >>permission of NetScreen Technologies, Inc. is >>strictly prohibited. If you >>are not the intended recipient, please contact the >>sender and delete/destroy >>all copies of this email and any related >>attachments. NetScreen does not >>guarantee the accuracy or completeness of third >>party materials or >>information. >> >> >> >> > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail SpamGuard - Read only the mail you want. > http://antispam.yahoo.com/tools > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 15:47:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13309 for ; Wed, 25 Feb 2004 15:47:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5vw-0000kw-Ih for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 15:47:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKl8rJ002794 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 15:47:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5vq-0000fG-25; Wed, 25 Feb 2004 15:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5uu-0000dt-6d for sip@optimus.ietf.org; Wed, 25 Feb 2004 15:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13135 for ; Wed, 25 Feb 2004 15:46:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5us-0001uQ-00 for sip@ietf.org; Wed, 25 Feb 2004 15:46:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5tt-0001lz-00 for sip@ietf.org; Wed, 25 Feb 2004 15:45:01 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw5sz-0001az-00 for sip@ietf.org; Wed, 25 Feb 2004 15:44:05 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2004 12:54:38 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1PKhX4U001609; Wed, 25 Feb 2004 12:43:33 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQQ23354; Wed, 25 Feb 2004 12:43:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5E64A9AC-67D3-11D8-B826-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Rohan Mahy From: Rohan Mahy Date: Wed, 25 Feb 2004 12:44:12 -0800 To: "'sip@ietf.org'" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Attention: SIP draft authors Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, If you are writing a draft using the xml2rfc tool, please make sure that the following line appears just after the line which begins if you don't do this, the tool will generate each top-level section on its own page, so you end up wasting a whole page to print for example: 11. IANA Considerations This document requires no action by IANA. many thanks for saving trees, etc.. and making my reading list lighter (at least by weight). thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Feb 25 20:31:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28645 for ; Wed, 25 Feb 2004 20:31:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwAMp-0007Tj-1B for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 20:31:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q1VAdZ028685 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 20:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwAMg-0007Qt-Rr; Wed, 25 Feb 2004 20:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwALs-0007Oz-F6 for sip@optimus.ietf.org; Wed, 25 Feb 2004 20:30:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28591 for ; Wed, 25 Feb 2004 20:30:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwALq-000190-00 for sip@ietf.org; Wed, 25 Feb 2004 20:30:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwAKu-00014G-00 for sip@ietf.org; Wed, 25 Feb 2004 20:29:12 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AwAKP-0000yy-00 for sip@ietf.org; Wed, 25 Feb 2004 20:28:41 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2004 17:38:35 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1Q1S91m002014; Wed, 25 Feb 2004 17:28:09 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQQ56308; Wed, 25 Feb 2004 17:28:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0C62BA6D-67FB-11D8-B826-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Dean Willis , "'Gonzalo Camarillo'" From: Rohan Mahy Date: Wed, 25 Feb 2004 17:28:14 -0800 To: "'sip@ietf.org'" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP WG Reading List PDF now available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, A single, properly-paginated, suitable for double-sided printing, PDF file of the entire reading list for the SIP WGs upcoming meeting is now available on the supplemental website. Links are available from the agenda page: http://www.softarmor.com/sipwg/meets/ietf59/agenda.html There are actually 4 PDFs available. You can select from PDFs for A4 or US-Letter paper, and one-page per side or two-pages per side layouts. Enjoy and see many of you in Korea. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 26 02:43:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25605 for ; Thu, 26 Feb 2004 02:43:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGAy-0003oW-MK for sip-archive@odin.ietf.org; Thu, 26 Feb 2004 02:43:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q7hKAa014594 for sip-archive@odin.ietf.org; Thu, 26 Feb 2004 02:43:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGAg-0003kf-Nq; Thu, 26 Feb 2004 02:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGA1-0003jM-7y for sip@optimus.ietf.org; Thu, 26 Feb 2004 02:42:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25546 for ; Thu, 26 Feb 2004 02:42:17 -0500 (EST) From: mankin@psg.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwG9x-0003b8-00 for sip@ietf.org; Thu, 26 Feb 2004 02:42:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwG91-0003Un-00 for sip@ietf.org; Thu, 26 Feb 2004 02:41:19 -0500 Received: from cpe-24-24-140-101.socal.rr.com ([24.24.140.101] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AwG8A-0003OW-00 for sip@ietf.org; Thu, 26 Feb 2004 02:40:26 -0500 To: sip@ietf.org Date: Wed, 25 Feb 2004 23:40:30 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_000049EA.00002548" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.7 required=5.0 tests=MICROSOFT_EXECUTABLE, MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [Sip] doc about me? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0000_000049EA.00002548 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit is that your account? ------=_NextPart_000_0000_000049EA.00002548 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: naked2.txt.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0000_000049EA.00002548-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 26 07:43:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08204 for ; Thu, 26 Feb 2004 07:43:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKr8-0006Mk-JI for sip-archive@odin.ietf.org; Thu, 26 Feb 2004 07:43:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QChAfh024466 for sip-archive@odin.ietf.org; Thu, 26 Feb 2004 07:43:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKr0-0006JS-DD; Thu, 26 Feb 2004 07:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKqf-0006Gl-4v for sip@optimus.ietf.org; Thu, 26 Feb 2004 07:42:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08118 for ; Thu, 26 Feb 2004 07:42:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKqe-0001Zz-00 for sip@ietf.org; Thu, 26 Feb 2004 07:42:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKp4-0001BV-00 for sip@ietf.org; Thu, 26 Feb 2004 07:41:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwKnN-0000p3-00 for sip@ietf.org; Thu, 26 Feb 2004 07:39:17 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwKae-0003dj-El for sip@ietf.org; Thu, 26 Feb 2004 07:26:08 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QCQ2YG024443 for ; Thu, 26 Feb 2004 13:26:06 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 13:26:01 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.124]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSKYZAZA; Thu, 26 Feb 2004 13:26:20 +0100 Message-ID: <403DE5D9.3020507@ericsson.com> Date: Thu, 26 Feb 2004 14:26:01 +0200 X-Sybari-Trust: 25846f6d c77f3eb6 6298249a 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: "Christer Holmberg (JO/LMF)" , sip , Rohan Mahy , Dean Willis References: <4035F586.1000405@ericsson.com> <403A4FA6.8040407@nortelnetworks.com> <403AFE24.9020504@ericsson.com> <403CFEAD.3050300@nortelnetworks.com> In-Reply-To: <403CFEAD.3050300@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2004 12:26:01.0905 (UTC) FILETIME=[B240AA10:01C3FC63] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: INFO Documentation (was Re: Defining new requests) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom. it seems that what you want is an update of the INFO spec, rather than fixing a few errata. I believe that we cannot meet your timeframe. In any event, it would be great we could start working on a solution for INFO in SIPPING, so that the ITU could reference it in the future. Thanks, Gonzalo Tom Taylor wrote: > Q.1912.5 is in the process of final approval. Logging errata may be > satisfactory -- I'd have to check. It would certainly be more > comfortable than reproducing the RFC with modifications in the ITU > document. If the IETF acts within the next two weeks we should be able > to remove the Annex from the Recommendation. > > Here is the current list of changes as reported at the beginning of the > Annex. > > "The SIP INFO method is documented in RFC 2976. However, that RFC refers > to RFC 2543, the previous version of the SIP specification, rather than > to RFC 3261. The text of this Annex reproduces RFC 2976 with changes to > reflect the updated reference. > > "The changes made are as follows: > > "Paragraph C.3.2.1: The references to the tables of RFC2543 were changed > to reflect the new table organization in RFC 3261. > > "Paragraph C.3.2: The tables 1 and 2 were replaced by new tables that > show the header fields defined as presented in RFC3261. All additional > headers (additional to RFC 2543) used within RFC3261 were here set to > optional with two exceptions. The Reply-To (only optional for the > INVITE) and Call-Info Header (only used for INVITE, OPTIONS, REGISTER to > give additional information about the caller or callee) are not used > with the INFO method. > > "Paragraph C.3.6: The reference was changed to the current SIP > specification, RFC 3261. > > > Gonzalo Camarillo wrote: > >> Tom, >> >> what is the timeframe here? As you know, we have had discussions in >> the past about either re-defining INFO so that it can only carry PSTN >> telephony signalling, or defining INFO packages. We could re-start >> those discussions, and once we reach a conclusion, clarify the rules >> to send INFO from the UAS within early dialogs in the same spec... >> >> If the ITU is in a hurry, other solutions may be better, like logging >> an errata against the INFO RFC. >> >> Gonzalo >> >> Tom Taylor wrote: >> >>> The ITU-T (Study Group 11, to be exact) had a different issue with >>> INFO: that the RFC depends on RFC 2543 rather than 3261. As a >>> result, they picked up the content of RFC 2976 as Annex C.3 of the >>> ISUP interworking specification Q.1912.5. If RFC 2976 ever gets >>> updated Annex C.3 can be deprecated. In the meantime, this INFO >>> question means we have some maintenance to perform. I think the best >>> solution will be to take Gonzalo's suggestion and say that INFO >>> follows the rules for UPDATE. We already have a normative dependency >>> on the UPDATE RFC. >>> >>> Gonzalo Camarillo wrote: >>> >>>> Christer, >>>> >>>> would the ITU-T be happier if we log an errata against the INFO RFC >>>> saying that UASs can send INFO within early dialogs? >>>> >>>> Gonzalo >>>> >>>> Christer Holmberg (JO/LMF) wrote: >>>> >>>>> Hi Gonzalo, >>>>> >>>>> Thanks for your reply! >>>>> >>>>> >>>>>> it seems that some people in the ITU-T are having some issues >>>>>> figuring out whether or not certain requests can be sent by the UAS >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> within an >>>>> >>>>>> early dialog. The confusion comes from statements like this one >>>>>> (taken from the INFO spec): >>>>>> >>>>>> " Unless stated otherwise, the protocol rules for the INFO >>>>>> request >>>>>> governing the usage of tags, Route and Record-Route, >>>>>> retransmission and reliability, CSeq incrementing and message >>>>>> formatting follow those in [1] as defined for the BYE request." >>>>>> >>>>>> Since a UAS does not send BYEs within an early dialog, but a >>>>>> non-2xx final response instead, to terminate the dialog, people >>>>>> assume that >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> INFO >>>>> >>>>>> cannot be sent in this situation either. >>>>>> >>>>>> Let's try to keep this in mind and clarify this point when/if we >>>>>> define new SIP methods. >>>>>> >>>>>> In any event, the clarification to this issue can be found in RFC >>>>>> 3398: >>>>>> >>>>>> "From the callee to the caller, if a message is received by a gateway >>>>>> before the call has been answered (i.e., ANM is received) it >>>>>> SHOULD be encapsulated in an INFO, provided that this will not be >>>>>> the first SIP message sent in the backwards direction (in which >>>>>> case it SHOULD be encapsulated in a provisional 1xx response)." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The problem is that the ITU-T interworking spec doesn't reference >>>>> RFC3398. The spec reference the INFO RFC, and that is also where I >>>>> think >>>>> the usage rules should be defined (not in another spec, RFC3398 in >>>>> this >>>>> case, simply using the method). >>>>> >>>>> The INFO RFC, as you said, currently says that INFO "follows the rules >>>>> of BYE" (whatever that means is another question :), and the rules for >>>>> BYE specifically says that it must not be sent backward before the >>>>> INVITE has finished. If the INFO RFC would say "follow the rules of >>>>> UPDATE" we would not have this problem, since the UPDATE spec >>>>> specifically allows the use of the method before the INVITE has >>>>> finished. >>>>> >>>>> Thanks! >>>>> >>>>> Christer Holmberg >>>>> Ericsson Finland >>>> >>>> >>>> >> >> >> This communication is confidential and intended solely for the >> addressee(s). Any unauthorized review, use, disclosure or distribution >> is prohibited. If you believe this message has been sent to you in >> error, please notify the sender by replying to this transmission and >> delete the message without disclosing it. Thank you. >> >> E-mail including attachments is susceptible to data corruption, >> interruption, unauthorized amendment, tampering and viruses, and we >> only send and receive e-mails on the basis that we are not liable for >> any such corruption, interception, amendment, tampering or viruses or >> any consequences thereof. >> >> -- 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 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Feb 26 08:03:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09250 for ; Thu, 26 Feb 2004 08:03:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLAT-000860-1G for sip-archive@odin.ietf.org; Thu, 26 Feb 2004 08:03:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QD38hB031118 for sip-archive@odin.ietf.org; Thu, 26 Feb 2004 08:03:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLAL-00084l-K1; Thu, 26 Feb 2004 08:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwL9q-00082s-90 for sip@optimus.ietf.org; Thu, 26 Feb 2004 08:02:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09241 for ; Thu, 26 Feb 2004 08:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwL9p-0003qg-00 for sip@ietf.org; Thu, 26 Feb 2004 08:02:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwL8s-0003mE-00 for sip@ietf.org; Thu, 26 Feb 2004 08:01:31 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AwL89-0003eS-00 for sip@ietf.org; Thu, 26 Feb 2004 08:00:45 -0500 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1QD0Aw01481; Thu, 26 Feb 2004 08:00:10 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FS3QX7XS; Thu, 26 Feb 2004 08:00:10 -0500 Received: from nortelnetworks.com (acart1ec.ca.nortel.com [47.129.129.121]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJLJ3; Thu, 26 Feb 2004 08:00:09 -0500 Message-ID: <403DEDD9.60704@nortelnetworks.com> Date: Thu, 26 Feb 2004 08:00:09 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Christer Holmberg (JO/LMF)" , sip , Rohan Mahy , Dean Willis References: <4035F586.1000405@ericsson.com> <403A4FA6.8040407@nortelnetworks.com> <403AFE24.9020504@ericsson.com> <403CFEAD.3050300@nortelnetworks.com> <403DE5D9.3020507@ericsson.com> In-Reply-To: <403DE5D9.3020507@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: INFO Documentation (was Re: Defining new requests) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As a first step, I'll submit the Q.1912.5 annex as an I-D. I expect we'll correct it to use UPDATE rather than BYE as the model in Geneva in the next couple of weeks, so what I submit will reflect that. Gonzalo Camarillo wrote: > Tom. > > it seems that what you want is an update of the INFO spec, rather than > fixing a few errata. I believe that we cannot meet your timeframe. In > any event, it would be great we could start working on a solution for > INFO in SIPPING, so that the ITU could reference it in the future. > > Thanks, > > Gonzalo > > Tom Taylor wrote: > >> Q.1912.5 is in the process of final approval. Logging errata may be >> satisfactory -- I'd have to check. It would certainly be more >> comfortable than reproducing the RFC with modifications in the ITU >> document. If the IETF acts within the next two weeks we should be >> able to remove the Annex from the Recommendation. >> >> Here is the current list of changes as reported at the beginning of >> the Annex. >> >> "The SIP INFO method is documented in RFC 2976. However, that RFC >> refers to RFC 2543, the previous version of the SIP specification, >> rather than to RFC 3261. The text of this Annex reproduces RFC 2976 >> with changes to reflect the updated reference. >> >> "The changes made are as follows: >> >> "Paragraph C.3.2.1: The references to the tables of RFC2543 were >> changed to reflect the new table organization in RFC 3261. >> >> "Paragraph C.3.2: The tables 1 and 2 were replaced by new tables that >> show the header fields defined as presented in RFC3261. All additional >> headers (additional to RFC 2543) used within RFC3261 were here set to >> optional with two exceptions. The Reply-To (only optional for the >> INVITE) and Call-Info Header (only used for INVITE, OPTIONS, REGISTER >> to give additional information about the caller or callee) are not >> used with the INFO method. >> >> "Paragraph C.3.6: The reference was changed to the current SIP >> specification, RFC 3261. >> >> >> Gonzalo Camarillo wrote: >> >>> Tom, >>> >>> what is the timeframe here? As you know, we have had discussions in >>> the past about either re-defining INFO so that it can only carry PSTN >>> telephony signalling, or defining INFO packages. We could re-start >>> those discussions, and once we reach a conclusion, clarify the rules >>> to send INFO from the UAS within early dialogs in the same spec... >>> >>> If the ITU is in a hurry, other solutions may be better, like logging >>> an errata against the INFO RFC. >>> >>> Gonzalo >>> >>> Tom Taylor wrote: >>> >>>> The ITU-T (Study Group 11, to be exact) had a different issue with >>>> INFO: that the RFC depends on RFC 2543 rather than 3261. As a >>>> result, they picked up the content of RFC 2976 as Annex C.3 of the >>>> ISUP interworking specification Q.1912.5. If RFC 2976 ever gets >>>> updated Annex C.3 can be deprecated. In the meantime, this INFO >>>> question means we have some maintenance to perform. I think the >>>> best solution will be to take Gonzalo's suggestion and say that INFO >>>> follows the rules for UPDATE. We already have a normative >>>> dependency on the UPDATE RFC. >>>> >>>> Gonzalo Camarillo wrote: >>>> >>>>> Christer, >>>>> >>>>> would the ITU-T be happier if we log an errata against the INFO RFC >>>>> saying that UASs can send INFO within early dialogs? >>>>> >>>>> Gonzalo >>>>> >>>>> Christer Holmberg (JO/LMF) wrote: >>>>> >>>>>> Hi Gonzalo, >>>>>> >>>>>> Thanks for your reply! >>>>>> >>>>>> >>>>>>> it seems that some people in the ITU-T are having some issues >>>>>>> figuring out whether or not certain requests can be sent by the UAS >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> within an >>>>>> >>>>>>> early dialog. The confusion comes from statements like this one >>>>>>> (taken from the INFO spec): >>>>>>> >>>>>>> " Unless stated otherwise, the protocol rules for the INFO >>>>>>> request >>>>>>> governing the usage of tags, Route and Record-Route, >>>>>>> retransmission and reliability, CSeq incrementing and message >>>>>>> formatting follow those in [1] as defined for the BYE >>>>>>> request." >>>>>>> >>>>>>> Since a UAS does not send BYEs within an early dialog, but a >>>>>>> non-2xx final response instead, to terminate the dialog, people >>>>>>> assume that >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> INFO >>>>>> >>>>>>> cannot be sent in this situation either. >>>>>>> >>>>>>> Let's try to keep this in mind and clarify this point when/if we >>>>>>> define new SIP methods. >>>>>>> >>>>>>> In any event, the clarification to this issue can be found in RFC >>>>>>> 3398: >>>>>>> >>>>>>> "From the callee to the caller, if a message is received by a >>>>>>> gateway >>>>>>> before the call has been answered (i.e., ANM is received) it >>>>>>> SHOULD be encapsulated in an INFO, provided that this will not be >>>>>>> the first SIP message sent in the backwards direction (in which >>>>>>> case it SHOULD be encapsulated in a provisional 1xx response)." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The problem is that the ITU-T interworking spec doesn't reference >>>>>> RFC3398. The spec reference the INFO RFC, and that is also where I >>>>>> think >>>>>> the usage rules should be defined (not in another spec, RFC3398 in >>>>>> this >>>>>> case, simply using the method). >>>>>> >>>>>> The INFO RFC, as you said, currently says that INFO "follows the >>>>>> rules >>>>>> of BYE" (whatever that means is another question :), and the rules >>>>>> for >>>>>> BYE specifically says that it must not be sent backward before the >>>>>> INVITE has finished. If the INFO RFC would say "follow the rules of >>>>>> UPDATE" we would not have this problem, since the UPDATE spec >>>>>> specifically allows the use of the method before the INVITE has >>>>>> finished. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Christer Holmberg >>>>>> Ericsson Finland >>>>> >>>>> >>>>> >>>>> >>> >>> >>> This communication is confidential and intended solely for the >>> addressee(s). Any unauthorized review, use, disclosure or >>> distribution is prohibited. If you believe this message has been sent >>> to you in error, please notify the sender by replying to this >>> transmission and delete the message without disclosing it. Thank you. >>> >>> E-mail including attachments is susceptible to data corruption, >>> interruption, unauthorized amendment, tampering and viruses, and we >>> only send and receive e-mails on the basis that we are not liable for >>> any such corruption, interception, amendment, tampering or viruses or >>> any consequences thereof. >>> >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 27 04:25:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21815 for ; Fri, 27 Feb 2004 04:25:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweEt-0000SY-Cp for sip-archive@odin.ietf.org; Fri, 27 Feb 2004 04:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R9OxLP001759 for sip-archive@odin.ietf.org; Fri, 27 Feb 2004 04:24:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweEI-0000Ji-Vf; Fri, 27 Feb 2004 04:24:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awdqt-00077O-7x for sip@optimus.ietf.org; Fri, 27 Feb 2004 04:00:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21200 for ; Fri, 27 Feb 2004 04:00:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awdqq-0007Os-00 for sip@ietf.org; Fri, 27 Feb 2004 04:00:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awdps-0007Jn-00 for sip@ietf.org; Fri, 27 Feb 2004 03:59:09 -0500 Received: from mgw1.noc.ntt.com ([210.163.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1AwdpD-0007A2-00 for sip@ietf.org; Fri, 27 Feb 2004 03:58:27 -0500 Received: from mop2.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id i1R8v4Oh015601; Fri, 27 Feb 2004 17:57:04 +0900 (JST) Received: from mip1.noc.ntt.com (mvi3.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HTQ00DBKJJ4TE@ntt.com>; Fri, 27 Feb 2004 17:57:04 +0900 (JST) Content-return: prohibited Date: Fri, 27 Feb 2004 17:51:14 +0900 From: "Ashir Ahmed" Subject: Re: [Sip] From Header To: "Jonathan Rosenberg" , "Anil Bollineni" Cc: "'xiao'tong liang'" , sip@ietf.org, sip-implementors@cs.columbia.edu, ps-sf-ia@ntt.com Message-id: <007401c3fd0e$db34dcb0$a844320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <017B1BB60535DF4285666089FA048AC20172EFF3@SONOMA.netscreen.com> <403D0370.5080902@dynamicsoft.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -Both To and From headers contain logical addresses. These headers are not used for routing purposes. -Contact header in general contains a SIP(S) URI for receiving subsequent requests. However, this header is NOT used in PUBLISH and MESSAGE requests as they do not expect any subsequent requests. Please find a general guideline on these message headers and URI scheme usage at http://www.softfront.co.jp/tech/ietfdoc/draft/draft-ashir-simple-message-guideline-01.txt Ashir ----- Original Message ----- From: "Jonathan Rosenberg" To: "Anil Bollineni" Cc: "'xiao'tong liang'" ; ; Sent: Thursday, February 26, 2004 5:20 AM Subject: Re: [Sip] From Header > Responses are sent to the Via address, though more commonly to the > source IP/port of the request when TCP is used, or when rport is used > (RFC 3581) with UDP. The IP/port in the Via effectively provide a > fallback, to be used for the server to re-initiate a connection to the > client in the event of failure to send the response. > > Subsequent requests in a dialog are sent to the Contact URI. > > From is a logical identifier, used for display and policy purposes. > Please, please don't muck with it. > > Let me take this opportunity to preach a little on the role of ALGs in a > network. > > As a general rule, ALGs are quite problematic. They don't work in > conjunction with most of the SIP security mechanisms, including S/MIME > but more importantly sips and TLS. Their spotty presence in a network, > generally undetectable to application entities in the network, cannot be > depended on, and therefore can never serve as a complete solution for an > application service provider. Worse yet, when (and I say when, not if) > one of these ALGs does something wrong that breaks a call flow, it > becomes almost impossible to diagnose and correct. Generally speaking, > application layer intelligence does not belong in the core of the > network; that brings us back to the days of single-service networks > where the whole network needs to be upgraded to support a new > application. ALGs are contrary to the hourglass model that is one of the > defining characteristics of IP. > > I much prefer solutions like ICE, STUN, TURN and MIDCOM, which separate > application layer intelligence from firewalls and NATs, and allow for > applications to do the right thing for themselves for the purposes of > NAT traversal. > > As such, the right model is to NOT build an ALG, but if you must, build > a full protocol-compliant entity that just so happens to ship with and > be co-resident in your firewall/nat. That entity must be directly > addressed by other SIP entities, rather than being a transparent element > in the network. It is only through this model that we can create robust > and secure SIP networks. > > -Jonathan R. > > > Anil Bollineni wrote: > > > The Via header tells that IP address/port where the response should be sent. > > It does not specify from where the request has been come, as the ports for > > sending request and receiving responses can be different. I think the only > > way we can tell is by seeing the sending ip and port in IP header of the > > packet. Please correct if I am wrong. > > > > Thanks, > > Anil > > > > > > This email contains material that is confidential. The content of this email > > is for the sole use of the intended recipient(s). Any review or distribution > > by persons other than the intended recipient(s) without the express > > permission of NetScreen Technologies, Inc. is strictly prohibited. If you > > are not the intended recipient, please contact the sender and delete/destroy > > all copies of this email and any related attachments. NetScreen does not > > guarantee the accuracy or completeness of third party materials or > > information. > > > > > > -----Original Message----- > > From: xiao'tong liang [mailto:boyliangxt@yahoo.com] > > Sent: Sunday, February 22, 2004 6:07 PM > > To: Anil Bollineni > > Subject: Re: [Sip] From Header > > > > Via header. > > > > -- > > xiaotong > > > > > > --- Anil Bollineni wrote: > > > >>Hi All, > >> > >> > >> > >> I understand from the following statement in > >>RFC, that From header > >>SHOULD not contain IP addresses/ports from whom the > >>request has come. If it > >>is so, I can't assume that the information is not > >>used to assume from where > >>(IP address/port) the request has come. Appreciate > >>your response to clarify > >>the point. > >> > >> > >> > >> As such, it is very important that the From URI > >>not contain IP addresses > >>or the FQDN > >> > >> of the host on which the UA is running, since > >>these are not logical > >> > >> names. > >> > >> > >> > >>Thank you, > >> > >>Anil > >> > >> > >> > >>This email contains material that is confidential. > >>The content of this email > >>is for the sole use of the intended recipient(s). > >>Any review or distribution > >>by persons other than the intended recipient(s) > >>without the express > >>permission of NetScreen Technologies, Inc. is > >>strictly prohibited. If you > >>are not the intended recipient, please contact the > >>sender and delete/destroy > >>all copies of this email and any related > >>attachments. NetScreen does not > >>guarantee the accuracy or completeness of third > >>party materials or > >>information. > >> > >> > >> > >> > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Mail SpamGuard - Read only the mail you want. > > http://antispam.yahoo.com/tools > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 27 17:05:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27467 for ; Fri, 27 Feb 2004 17:05:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq6e-0000dp-8N for sip-archive@odin.ietf.org; Fri, 27 Feb 2004 17:05:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RM5GYU002341 for sip-archive@odin.ietf.org; Fri, 27 Feb 2004 17:05:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq6R-0000YW-DE; Fri, 27 Feb 2004 17:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq60-0000XJ-TL for sip@optimus.ietf.org; Fri, 27 Feb 2004 17:04:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27415 for ; Fri, 27 Feb 2004 17:04:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awq5y-00059f-00 for sip@ietf.org; Fri, 27 Feb 2004 17:04:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awq52-00053t-00 for sip@ietf.org; Fri, 27 Feb 2004 17:03:37 -0500 Received: from smtp.epygilab.am ([212.126.211.246] helo=epygilab.am) by ietf-mx with esmtp (Exim 4.12) id 1Awq4L-0004qK-00 for sip@ietf.org; Fri, 27 Feb 2004 17:02:57 -0500 Received: from 127.0.0.1 ([192.168.0.142]) by epygilab.am (epygilab.am [192.168.0.156]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 13-md50000000019.tmp for ; Fri, 27 Feb 2004 18:02:43 +0400 Date: Fri, 27 Feb 2004 18:04:18 +0400 From: Simon Asryan Reply-To: Simon Asryan Organization: Epygi X-Priority: 3 (Normal) Message-ID: <346438022.20040227180418@epygilab.am> To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Processed: epygilab.am, Fri, 27 Feb 2004 18:02:43 +0400 (not processed: spam filter disabled) X-MDRemoteIP: 192.168.0.142 X-Return-Path: simon.asryan@epygilab.am X-MDaemon-Deliver-To: sip@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] rfc3265 Handling of forked requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, rfc3265 says 4.4.9. Handling of forked requests Each event package MUST specify whether forked SUBSCRIBE requests are allowed to install multiple subscriptions. If such behavior is not allowed, the first potential dialog- establishing message will create a dialog. All subsequent NOTIFY messages which correspond to the SUBSCRIBE message (i.e., match "To", "From", "From" header "tag" parameter, "Call-ID", "CSeq", "Event", and "Event" header "id" parameter) but which do not match the dialog would be rejected with a 481 response. Note that the 200-class response to the SUBSCRIBE can arrive after a matching NOTIFY has been received; such responses might not correlate to the same dialog established by the NOTIFY. Except as required to complete the SUBSCRIBE transaction, such non-matching 200-class responses are ignored. The question is, should the "CSeq" field of NOTIFY message participate in corresponding with SUBSCRIBE message? -- Best regards, Simon mailto:simon.asryan@epygilab.am _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Feb 27 17:51:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27468 for ; Fri, 27 Feb 2004 17:05:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq6e-0000dq-8a for sip-archive@odin.ietf.org; Fri, 27 Feb 2004 17:05:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RM5GeX002342 for sip-archive@odin.ietf.org; Fri, 27 Feb 2004 17:05:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq6S-0000Yi-Md; Fri, 27 Feb 2004 17:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq61-0000XO-Hn for sip@optimus.ietf.org; Fri, 27 Feb 2004 17:04:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27418 for ; Fri, 27 Feb 2004 17:04:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awq5z-00059k-00 for sip@ietf.org; Fri, 27 Feb 2004 17:04:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awq53-000541-00 for sip@ietf.org; Fri, 27 Feb 2004 17:03:37 -0500 Received: from smtp.epygilab.am ([212.126.211.246] helo=epygilab.am) by ietf-mx with esmtp (Exim 4.12) id 1Awq4L-0004qL-00 for sip@ietf.org; Fri, 27 Feb 2004 17:02:54 -0500 Received: from 127.0.0.1 ([192.168.0.142]) by epygilab.am (epygilab.am [192.168.0.156]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 29-md50000000019.tmp for ; Fri, 27 Feb 2004 18:14:51 +0400 Date: Fri, 27 Feb 2004 18:16:29 +0400 From: Simon Asryan Reply-To: Simon Asryan Organization: Epygi X-Priority: 3 (Normal) Message-ID: <973990826.20040227181629@epygilab.am> To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Processed: epygilab.am, Fri, 27 Feb 2004 18:14:51 +0400 (not processed: spam filter disabled) X-MDRemoteIP: 192.168.0.142 X-Return-Path: simon.asryan@epygilab.am X-MDaemon-Deliver-To: sip@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] rfc3265 Handling of forked requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, rfc3265 says 4.4.9. Handling of forked requests Each event package MUST specify whether forked SUBSCRIBE requests are allowed to install multiple subscriptions. If such behavior is not allowed, the first potential dialog- establishing message will create a dialog. All subsequent NOTIFY messages which correspond to the SUBSCRIBE message (i.e., match "To", "From", "From" header "tag" parameter, "Call-ID", "CSeq", "Event", and "Event" header "id" parameter) but which do not match the dialog would be rejected with a 481 response. Note that the 200-class response to the SUBSCRIBE can arrive after a matching NOTIFY has been received; such responses might not correlate to the same dialog established by the NOTIFY. Except as required to complete the SUBSCRIBE transaction, such non-matching 200-class responses are ignored. The question is, should the "CSeq" field of NOTIFY message participate in corresponding with SUBSCRIBE message? -- Best regards, Simon mailto:simon.asryan@epygilab.am _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Feb 28 02:52:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06198 for ; Sat, 28 Feb 2004 02:52:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwzGl-0003Hj-PE for sip-archive@odin.ietf.org; Sat, 28 Feb 2004 02:52:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S7qJLh012559 for sip-archive@odin.ietf.org; Sat, 28 Feb 2004 02:52:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwzGb-0003CU-7b; Sat, 28 Feb 2004 02:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwzFk-00031U-0S for sip@optimus.ietf.org; Sat, 28 Feb 2004 02:51:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06105 for ; Sat, 28 Feb 2004 02:51:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwzFg-00014A-00 for sip@ietf.org; Sat, 28 Feb 2004 02:51:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwzEq-0000wU-00 for sip@ietf.org; Sat, 28 Feb 2004 02:50:21 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AwzEC-0000nm-00 for sip@ietf.org; Sat, 28 Feb 2004 02:49:40 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1S7nANr010663; Sat, 28 Feb 2004 02:49:12 -0500 (EST) Message-ID: <404039AA.5010700@dynamicsoft.com> Date: Sat, 28 Feb 2004 01:48:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Dean Willis , Brian Stucker , sip@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Abstraction: SIP instance identifiers requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I don't think this unique instance identifier thing had much to do with > billing or debugging. I'm imagine a case something like the following: > > I have two offices, one on the west side of the building and one of the > east. They both have phones registered as fluffy. Because it is better for > lounging in the Sun, I spend the morning in the East office and afternoon in > the West. Right now I can't write a proxy that forward to the correct one. Sure you can! Thats what callerprefs is for. You would define a new callee-caps parameter, "exposure" with values of east, west, north and south. The two devices would each include a +sip.exposure contact header field parmeter indicating which one is on which side. Then, a caller wanting to reach the east side would do this: INVITE sip:fluffy@cisco.com Accept-Contact: *;+sip.exposure="east" which would do preferential routing to the east side. Note, of course, that caller prefs provides no guarantees. Things still work if you fork the call to both. It is this unreliability for routing tha made it unsuitable for the problem of getting a request to a specific instance. -Jonathan R. > > If I was using SUBSCRIBE to support event notification of provisioning > changes, I would not be able to identify which phone was subscribing. > > > On 2/17/04 11:16 AM, "Dean Willis" wrote: > > >>1) billing -- "Alice called Bob from phone ID000001 through gateway >>ID3344555 on Tuesday, March 1, 2011" >> >>2) Debugging -- "This request was responded to by node IDYIYIOHIHIUH, >>which is a Barfia model 9995 phone running Finux 21.05A and the Vocal >>user agent release 89.6" > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Feb 28 03:41:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06197 for ; Sat, 28 Feb 2004 02:52:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwzGl-0003Hk-Pq for sip-archive@odin.ietf.org; Sat, 28 Feb 2004 02:52:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S7qJGg012560 for sip-archive@odin.ietf.org; Sat, 28 Feb 2004 02:52:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwzGV-0003AV-5q; Sat, 28 Feb 2004 02:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwzFc-0002yO-HN for sip@optimus.ietf.org; Sat, 28 Feb 2004 02:51:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06064 for ; Sat, 28 Feb 2004 02:51:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwzFY-000136-00 for sip@ietf.org; Sat, 28 Feb 2004 02:51:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwzEg-0000ux-00 for sip@ietf.org; Sat, 28 Feb 2004 02:50:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AwzDZ-0000ht-00 for sip@ietf.org; Sat, 28 Feb 2004 02:49:01 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1S7mXNr010654; Sat, 28 Feb 2004 02:48:34 -0500 (EST) Message-ID: <4040321B.1010503@dynamicsoft.com> Date: Sat, 28 Feb 2004 01:15:55 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Orit Levin , sip@ietf.org Subject: Re: [Sip] SIP instance identifiers References: <403A5639.30303@cisco.com> In-Reply-To: <403A5639.30303@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i1S7mXNr010654 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable inline. Paul Kyzivat wrote: >=20 >=20 > Orit Levin wrote: >=20 >> I tend to agree with Paul (if I read him correctly). >=20 >=20 > I think maybe you don't read me as intended, because I don't entirely=20 > agree with you here. (At least if I understand you.) >=20 >> I think that GUID and the original GRID parameter are very different=20 >> things because of their properties (and obviously the resultant usage=20 >> cases). >=20 >=20 > If you are talking about the grid=3Dxxx parameter that Jonathan has=20 > proposed be used with GRUUs, then I don't think it has any signficance=20 > to this discussion at all. I agree, I dont see the relationship. >> 2. _GRUU format:_ GRUU (not GRID or GUID) is a SIP URI and is very=20 >> SIPish concept with the properties as defined in the GRUU draft. It IS= =20 >> the "SIP Instance Identifier". >=20 >=20 > The last sentence is debatable. It is *an* endpoint instance identifier= =20 > that is sip routable. But it isn't necessarily defined for as long as=20 > the device(s) it references are. And it isn't necessarily bound to the=20 > same device at all times. Right. The GRUU is not a device identifier. Its a URI whose property is=20 that it tends to route to a device with a particular device ID. The UML=20 in the GRUU spec tries to explain the relationship between them. >> 3. _GRUU signaling and usage:_ GRUU can be allocated either by=20 >> Registrar, or by UA, or by different means. My point is GRUU=20 >> identification (i.e. placement and signaling) during session=20 >> establishment and usage (especially outside the Registrar domain) MUST= =20 >> be identical for all cases. Moreover, it MUST be possible for the=20 >> Registrar domain to conceal the information about the allocation=20 >> method being used. >> >> 4. _Registration Procedure:_ We need to standardize the registration=20 >> procedure for both basic cases: GRUU allocated by Server (done) and=20 >> GRUU allocated by Client. In my opinion, both cases need to be under=20 >> the Registration/contact umbrella - which makes them SIP concepts!=20 >> Whether GRUU value is preserved during client's/server's reboots - it=20 >> doesn't change the concept. From usability point of view, it would be=20 >> very nice to keep the value as long as possible. >From the outside=20 >> user point of view - it doesn't need to know (and doesn't want to=20 >> know) what the registration durability of its peers is. >=20 >=20 > Jonathan should probably chime in here. I believe he argues that=20 > typically a UA can't tell whether it can generate its own GRUU, so they= =20 > should always be assigned by registrars. Correct. If a UA happens to be able to be able to generate a URI that it=20 KNOWS has the properties of a GRUU, this is going to be because it is=20 effectively co-located with a registrar responsible for a particular doma= in. >=20 >> 5. _Saving Registration Cycles and DB size_: By using GRUU we have the= =20 >> ability to contact a specific instance of SIP AOR. Once we point to a=20 >> specific entity, we MAY also need to point to specific sub-entities=20 >> inside this GRUU. This will save the registration burden from each of=20 >> these sub-entities, since they will be covered by GRUU=92s registratio= n=20 >> and routing. The original GRID parameters allowed for exactly this=20 >> functionality. The usage example is a conference factory which=20 >> generates foci and doesn=92t need to dynamically REGISTER each of them= =20 >> in order to achieve proper routing. BTW, the concept of =93internal=20 >> routing=94 to specific logical module inside SIP entity can be=20 >> generalized, decoupled from GRUU and be defined as a dedicated SIP=20 >> header. >=20 >=20 > Maybe it can be decoupled from GRUU, but I think it must be coupled to = a=20 > URL, not a message. So it must be a URL formatting convention and/or a=20 > url parameter. So maybe you could generalize the grid parameter to appl= y=20 > to all sip/sips urls, rather than coupling it to gruu. I haven't though= t=20 > thru where that might be useful. Sounds like ISDN subaddresssing. I think that this is a fair analogy to grid. I'm not sure I see cases=20 where it is useful to have the grid functionality separate from GRUUs.=20 Orit, can you give a specific example? -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Feb 28 18:24:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10241 for ; Sat, 28 Feb 2004 18:24:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDom-0001OG-DH for sip-archive@odin.ietf.org; Sat, 28 Feb 2004 18:24:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SNOOBe005284 for sip-archive@odin.ietf.org; Sat, 28 Feb 2004 18:24:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDoP-0001Lu-Pg; Sat, 28 Feb 2004 18:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwpTM-0006bu-Vi for sip@optimus.ietf.org; Fri, 27 Feb 2004 16:24:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25248 for ; Fri, 27 Feb 2004 16:24:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwpTL-0000ET-00 for sip@ietf.org; Fri, 27 Feb 2004 16:24:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwpSO-000090-00 for sip@ietf.org; Fri, 27 Feb 2004 16:23:40 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AwpRp-00003F-00; Fri, 27 Feb 2004 16:23:06 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i1RLKlQe009566; Fri, 27 Feb 2004 22:20:49 +0100 (CET) From: "Gunnar Hellstrom" To: , "Henning Schulzrinne" Cc: "Toip list" , "'Sipping@Ietf. Org'" Subject: [sip] Comment to draft-agrawal-sip-h323-interworking-reqs-06.txt about text support Date: Fri, 27 Feb 2004 22:22:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id i1RLKlQe009566 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable In section 6.1.5 of the sip-h323-interworking spec, there is a sentence: "The IWF SHOULD be able to map the common audio, video and application format names supported in H.323 to and from the equivalent RTP/AVP [RFC3550] names." It is good practice to always mention how the three main media of video, audio and text shall be handled in real time applications. audio and video are mentioned explicitly. It may not be evident to everybody that real time interactive text is capability declared in H.323 Annex G / H.245 by DataApplicationCapability.application =3D t140 So, in fact it is covered in the sentence requiring that "application" format namnes shall be mapped. The mapping should correspond to the RTP/AVP name text/t140 and corresponding names for inclusion of protection against loss. I seek your guidance how it can be made more clear that "text" capabiliti= es can be expressed in both H.323 and SIP systems and should be mapped. ( the spec is at http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-r= eqs -06.txt ) Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 29 02:21:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09835 for ; Sun, 29 Feb 2004 02:21:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLGT-0003s9-04 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 02:21:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T7LSiS014567 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 02:21:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLG9-0003e5-7N; Sun, 29 Feb 2004 02:21:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLFp-0003TA-JG for sip@optimus.ietf.org; Sun, 29 Feb 2004 02:20:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09729 for ; Sun, 29 Feb 2004 02:20:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxLFm-0007Ry-00 for sip@ietf.org; Sun, 29 Feb 2004 02:20:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxLEr-0007Ms-00 for sip@ietf.org; Sun, 29 Feb 2004 02:19:50 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxLEW-0007HB-02 for sip@ietf.org; Sun, 29 Feb 2004 02:19:28 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2004 23:30:24 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1T7JL4U029435; Sat, 28 Feb 2004 23:19:21 -0800 (PST) Received: from [172.16.37.243] (sjc-vpn3-75.cisco.com [10.21.64.75]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT64792; Sat, 28 Feb 2004 23:19:19 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 29 Feb 2004 05:38:40 +0900 Subject: Re: [Sip] From Port From: Cullen Jennings To: Anil Bollineni , Message-ID: In-Reply-To: <017B1BB60535DF4285666089FA048AC20172EFF0@SONOMA.netscreen.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3160916361_3906624" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_FONT_BIG,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3160916361_3906624 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The From does not have to contain anything useful at all. In general it should have something that is more like the address of record for the user instead of the the IP address and port that can be used to reach the device= . The contact is used to reach the device. So mine mike look like From: =B3Cullen Jennings=B2 If the only way to reach the proxy was on port 1234 then I might have to include that in my AOR but I would usually not put the port that the UA was using in the from.=20 On 2/20/04 1:00 PM, "Anil Bollineni" wrote: > Hi All, > For any SIP message, if UA or Proxy sending message than othe= r > than from port 5060, then it should be included in SIP from URI. For exam= ple, > if the Register message comes from 202.10.10.20:2218, the From header sho= uld > look like From: sip:joe@202.10.10.20:2218. Is it MUST if the port is diff= erent > than port 5060 then it should appear in the From header? > =20 > Thanks in Advance, > Anil > This email contains material that is confidential. The content of this em= ail > is for the sole use of the intended recipient(s). Any review or distribut= ion > by persons other than the intended recipient(s) without the express permi= ssion > of NetScreen Technologies, Inc. is strictly prohibited. If you are not th= e > intended recipient, please contact the sender and delete/destroy all copi= es of > this email and any related attachments. NetScreen does not guarantee the > accuracy or completeness of third party materials or information. >=20 > =20 >=20 --B_3160916361_3906624 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] From Port
The From does not have to contain anything useful at all. In general it sho= uld have something that is more like the address of record for the user inst= ead of the the IP address and port that can be used to reach the device. The= contact is used to reach the device. So mine mike look like

From: “Cullen Jennings” <sip:fluffy@cisco.com>

If the only way to reach the proxy was on port 1234 then I might have to in= clude that in my AOR but I would usually not put the port that the UA was us= ing in the from.


On 2/20/04 1:00 PM, "Anil Bollineni" <ABollineni@netscreen.com= > wrote:

Hi All,
            For= any SIP message, if UA or Proxy sending message than other than from port 5= 060, then it should be included in SIP from URI. For example, if the Registe= r message comes from 202.10.10.20:2218, the From header should look like Fro= m: sip:joe@202.10.10.20:2218. Is it MUST if the port is different than port = 5060 then it should appear in the From header?
 
Thanks in Advance,
Anil
This email contains material that is confidential. The content of this emai= l is for the sole use of the intended recipient(s). Any review or distributi= on by persons other than the intended recipient(s) without the express permi= ssion of NetScreen Technologies, Inc. is strictly prohibited. If you are not= the intended recipient, please contact the sender and delete/destroy all co= pies of this email and any related attachments. NetScreen does not guarantee= the accuracy or completeness of third party materials or information.

--B_3160916361_3906624-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 29 03:16:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12287 for ; Sun, 29 Feb 2004 03:16:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxM7R-0002Ge-W9 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 03:16:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T8GDqD008654 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 03:16:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxM7H-0002Dw-TO; Sun, 29 Feb 2004 03:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxM77-0002D6-Q7 for sip@optimus.ietf.org; Sun, 29 Feb 2004 03:15:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12278 for ; Sun, 29 Feb 2004 03:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxM75-0004o9-00 for sip@ietf.org; Sun, 29 Feb 2004 03:15:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxM67-0004iD-00 for sip@ietf.org; Sun, 29 Feb 2004 03:14:51 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxM5P-0004Xl-00 for sip@ietf.org; Sun, 29 Feb 2004 03:14:07 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Feb 2004 00:24:40 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1T8Da4U018761; Sun, 29 Feb 2004 00:13:36 -0800 (PST) Received: from [172.16.37.243] (tokyo-vpn-user258.cisco.com [10.70.83.2]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT65586; Sun, 29 Feb 2004 00:13:33 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 29 Feb 2004 17:08:40 +0900 From: Cullen Jennings To: Jonathan Rosenberg CC: Dean Willis , Brian Stucker , Message-ID: In-Reply-To: <404039AA.5010700@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Abstraction: SIP instance identifiers requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This just pushes the problem around but does not solve it. When both the phone boot, how do they know if they registers with the exposure set to east or west? We need something that makes one phone different from the other phone and configuration does not really help much because when the phones first boot they have no configuration. On 2/28/04 3:48 PM, "Jonathan Rosenberg" wrote: > > > Cullen Jennings wrote: > >> I don't think this unique instance identifier thing had much to do with >> billing or debugging. I'm imagine a case something like the following: >> >> I have two offices, one on the west side of the building and one of the >> east. They both have phones registered as fluffy. Because it is better for >> lounging in the Sun, I spend the morning in the East office and afternoon in >> the West. Right now I can't write a proxy that forward to the correct one. > > Sure you can! Thats what callerprefs is for. You would define a new > callee-caps parameter, "exposure" with values of east, west, north and > south. The two devices would each include a +sip.exposure contact header > field parmeter indicating which one is on which side. Then, a caller > wanting to reach the east side would do this: > > INVITE sip:fluffy@cisco.com > Accept-Contact: *;+sip.exposure="east" > > which would do preferential routing to the east side. > > Note, of course, that caller prefs provides no guarantees. Things still > work if you fork the call to both. It is this unreliability for routing > tha made it unsuitable for the problem of getting a request to a > specific instance. > > -Jonathan R. > >> >> If I was using SUBSCRIBE to support event notification of provisioning >> changes, I would not be able to identify which phone was subscribing. >> >> >> On 2/17/04 11:16 AM, "Dean Willis" wrote: >> >> >>> 1) billing -- "Alice called Bob from phone ID000001 through gateway >>> ID3344555 on Tuesday, March 1, 2011" >>> >>> 2) Debugging -- "This request was responded to by node IDYIYIOHIHIUH, >>> which is a Barfia model 9995 phone running Finux 21.05A and the Vocal >>> user agent release 89.6" >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 29 07:44:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19391 for ; Sun, 29 Feb 2004 07:44:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQIm-0006HS-K5 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 07:44:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TCiCba024142 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 07:44:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQIb-0006Fd-24; Sun, 29 Feb 2004 07:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQIT-0006FF-T5 for sip@optimus.ietf.org; Sun, 29 Feb 2004 07:43:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19383 for ; Sun, 29 Feb 2004 07:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQIT-0005Yk-00 for sip@ietf.org; Sun, 29 Feb 2004 07:43:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQHV-0005U7-00 for sip@ietf.org; Sun, 29 Feb 2004 07:42:54 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AxQGe-0005Ph-00 for sip@ietf.org; Sun, 29 Feb 2004 07:42:00 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1TCfwqY014163 for ; Sun, 29 Feb 2004 13:41:58 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Feb 2004 13:41:58 +0100 Received: from ericsson.com (rvi2-92-44.sw.ericsson.se [153.88.92.44]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF4SFBD; Sun, 29 Feb 2004 13:41:57 +0100 Message-ID: <4041DE0D.9050802@ericsson.com> Date: Sun, 29 Feb 2004 14:41:49 +0200 X-Sybari-Trust: 4fbaa78e c77f3eb6 614305f2 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'Tom Taylor'" , "'Christer Holmberg (JO/LMF)'" , "'sip'" , "'Rohan Mahy'" , "'Dean Willis'" Subject: Re: [Sip] Re: INFO Documentation (was Re: Defining new requests) References: <475FF955A05DD411980D00508B6D5FB00B3EF7B2@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00B3EF7B2@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Feb 2004 12:41:58.0310 (UTC) FILETIME=[6B8DBC60:01C3FEC1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Keith, > This is an revision requirement to INFO, not to an interworking > specification, so it should be in SIP, not in SIPPING. It is the core > INFO RFC that is itself not complete enough in this area. we are already discussing this in *SIP*, not in *SIPPING*. What I am missing from your comment? Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 29 07:46:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19477 for ; Sun, 29 Feb 2004 07:46:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQKr-0006gY-9e for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 07:46:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TCkL89025696 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 07:46:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQKa-0006bg-SJ; Sun, 29 Feb 2004 07:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQKU-0006av-CD for sip@optimus.ietf.org; Sun, 29 Feb 2004 07:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19447 for ; Sun, 29 Feb 2004 07:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQKT-0005jp-00 for sip@ietf.org; Sun, 29 Feb 2004 07:45:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQJb-0005em-00 for sip@ietf.org; Sun, 29 Feb 2004 07:45:04 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AxQJ4-0005Ze-00 for sip@ietf.org; Sun, 29 Feb 2004 07:44:30 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1TCiTqY014413 for ; Sun, 29 Feb 2004 13:44:29 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Feb 2004 13:44:29 +0100 Received: from ericsson.com (rvi2-92-44.sw.ericsson.se [153.88.92.44]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF4SF27; Sun, 29 Feb 2004 13:44:27 +0100 Message-ID: <4041DEA4.4050103@ericsson.com> Date: Sun, 29 Feb 2004 14:44:20 +0200 X-Sybari-Trust: c2599a27 c77f3eb6 614305f2 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'Tom Taylor'" , "'Christer Holmberg (JO/LMF)'" , "'sip'" , "'Rohan Mahy'" , "'Dean Willis'" Subject: Re: [Sip] Re: INFO Documentation (was Re: Defining new requests) References: <475FF955A05DD411980D00508B6D5FB00B3EF7B2@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00B3EF7B2@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Feb 2004 12:44:29.0070 (UTC) FILETIME=[C569E2E0:01C3FEC1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Keith, OK, I re-read the thread and I have noticed that you were referencing my last email. What I actually meant was that we should see whether we deprecate INFO so that it only transports PSTN stuff, or, on the other hand, we define INFO packages. We had some discussions about that some time ago. So, we need to discuss which requirements we need to fulfill, and that should be done in SIPPING. The actual document updating INFO will be done in SIP, as you suggest. Thanks, Gonzalo Drage, Keith (Keith) wrote: > This is an revision requirement to INFO, not to an interworking specification, so it should be in SIP, not in SIPPING. It is the core INFO RFC that is itself not complete enough in this area. > > Note that part of that revision should also be to update the RFC 2543 references to RFC 3261. > > regards > > Keith > > >>-----Original Message----- >>From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>Sent: 26 February 2004 12:26 >>To: Tom Taylor >>Cc: Christer Holmberg (JO/LMF); sip; Rohan Mahy; Dean Willis >>Subject: [Sip] Re: INFO Documentation (was Re: Defining new requests) >> >> >>Tom. >> >>it seems that what you want is an update of the INFO spec, >>rather than >>fixing a few errata. I believe that we cannot meet your timeframe. In >>any event, it would be great we could start working on a solution for >>INFO in SIPPING, so that the ITU could reference it in the future. >> >>Thanks, >> >>Gonzalo >> >>Tom Taylor wrote: >> >> >>>Q.1912.5 is in the process of final approval. Logging >> >>errata may be >> >>>satisfactory -- I'd have to check. It would certainly be more >>>comfortable than reproducing the RFC with modifications in the ITU >>>document. If the IETF acts within the next two weeks we >> >>should be able >> >>>to remove the Annex from the Recommendation. >>> >>>Here is the current list of changes as reported at the >> >>beginning of the >> >>>Annex. >>> >>>"The SIP INFO method is documented in RFC 2976. However, >> >>that RFC refers >> >>>to RFC 2543, the previous version of the SIP specification, >> >>rather than >> >>>to RFC 3261. The text of this Annex reproduces RFC 2976 >> >>with changes to >> >>>reflect the updated reference. >>> >>>"The changes made are as follows: >>> >>>"Paragraph C.3.2.1: The references to the tables of RFC2543 >> >>were changed >> >>>to reflect the new table organization in RFC 3261. >>> >>>"Paragraph C.3.2: The tables 1 and 2 were replaced by new >> >>tables that >> >>>show the header fields defined as presented in RFC3261. All >> >>additional >> >>>headers (additional to RFC 2543) used within RFC3261 were >> >>here set to >> >>>optional with two exceptions. The Reply-To (only optional for the >>>INVITE) and Call-Info Header (only used for INVITE, >> >>OPTIONS, REGISTER to >> >>>give additional information about the caller or callee) are >> >>not used >> >>>with the INFO method. >>> >>>"Paragraph C.3.6: The reference was changed to the current SIP >>>specification, RFC 3261. >>> >>> >>>Gonzalo Camarillo wrote: >>> >>> >>>>Tom, >>>> >>>>what is the timeframe here? As you know, we have had >> >>discussions in >> >>>>the past about either re-defining INFO so that it can only >> >>carry PSTN >> >>>>telephony signalling, or defining INFO packages. We could re-start >>>>those discussions, and once we reach a conclusion, clarify >> >>the rules >> >>>>to send INFO from the UAS within early dialogs in the same spec... >>>> >>>>If the ITU is in a hurry, other solutions may be better, >> >>like logging >> >>>>an errata against the INFO RFC. >>>> >>>>Gonzalo >>>> >>>>Tom Taylor wrote: >>>> >>>> >>>>>The ITU-T (Study Group 11, to be exact) had a different >> >>issue with >> >>>>>INFO: that the RFC depends on RFC 2543 rather than 3261. As a >>>>>result, they picked up the content of RFC 2976 as Annex >> >>C.3 of the >> >>>>>ISUP interworking specification Q.1912.5. If RFC 2976 ever gets >>>>>updated Annex C.3 can be deprecated. In the meantime, this INFO >>>>>question means we have some maintenance to perform. I >> >>think the best >> >>>>>solution will be to take Gonzalo's suggestion and say that INFO >>>>>follows the rules for UPDATE. We already have a >> >>normative dependency >> >>>>>on the UPDATE RFC. >>>>> >>>>>Gonzalo Camarillo wrote: >>>>> >>>>> >>>>>>Christer, >>>>>> >>>>>>would the ITU-T be happier if we log an errata against >> >>the INFO RFC >> >>>>>>saying that UASs can send INFO within early dialogs? >>>>>> >>>>>>Gonzalo >>>>>> >>>>>>Christer Holmberg (JO/LMF) wrote: >>>>>> >>>>>> >>>>>>>Hi Gonzalo, >>>>>>> >>>>>>>Thanks for your reply! >>>>>>> >>>>>>> >>>>>>> >>>>>>>>it seems that some people in the ITU-T are having some issues >>>>>>>>figuring out whether or not certain requests can be >> >>sent by the UAS >> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>within an >>>>>>> >>>>>>> >>>>>>>>early dialog. The confusion comes from statements like >> >>this one >> >>>>>>>>(taken from the INFO spec): >>>>>>>> >>>>>>>>" Unless stated otherwise, the protocol rules for the INFO >>>>>>>>request >>>>>>>> governing the usage of tags, Route and Record-Route, >>>>>>>> retransmission and reliability, CSeq >> >>incrementing and message >> >>>>>>>> formatting follow those in [1] as defined for >> >>the BYE request." >> >>>>>>>>Since a UAS does not send BYEs within an early dialog, but a >>>>>>>>non-2xx final response instead, to terminate the >> >>dialog, people >> >>>>>>>>assume that >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>INFO >>>>>>> >>>>>>> >>>>>>>>cannot be sent in this situation either. >>>>>>>> >>>>>>>>Let's try to keep this in mind and clarify this point >> >>when/if we >> >>>>>>>>define new SIP methods. >>>>>>>> >>>>>>>>In any event, the clarification to this issue can be >> >>found in RFC >> >>>>>>>>3398: >>>>>>>> >>>>>>>>"From the callee to the caller, if a message is >> >>received by a gateway >> >>>>>>>>before the call has been answered (i.e., ANM is received) it >>>>>>>>SHOULD be encapsulated in an INFO, provided that this >> >>will not be >> >>>>>>>>the first SIP message sent in the backwards direction >> >>(in which >> >>>>>>>>case it SHOULD be encapsulated in a provisional 1xx response)." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>The problem is that the ITU-T interworking spec doesn't >> >>reference >> >>>>>>>RFC3398. The spec reference the INFO RFC, and that is >> >>also where I >> >>>>>>>think >>>>>>>the usage rules should be defined (not in another spec, >> >>RFC3398 in >> >>>>>>>this >>>>>>>case, simply using the method). >>>>>>> >>>>>>>The INFO RFC, as you said, currently says that INFO >> >>"follows the rules >> >>>>>>>of BYE" (whatever that means is another question :), >> >>and the rules for >> >>>>>>>BYE specifically says that it must not be sent backward >> >>before the >> >>>>>>>INVITE has finished. If the INFO RFC would say "follow >> >>the rules of >> >>>>>>>UPDATE" we would not have this problem, since the UPDATE spec >>>>>>>specifically allows the use of the method before the INVITE has >>>>>>>finished. >>>>>>> >>>>>>>Thanks! >>>>>>> >>>>>>>Christer Holmberg >>>>>>>Ericsson Finland >>>>>> >>>>>> >>>>>> >>>> >>>>This communication is confidential and intended solely for the >>>>addressee(s). Any unauthorized review, use, disclosure or >> >>distribution >> >>>>is prohibited. If you believe this message has been sent to you in >>>>error, please notify the sender by replying to this >> >>transmission and >> >>>>delete the message without disclosing it. Thank you. >>>> >>>>E-mail including attachments is susceptible to data corruption, >>>>interruption, unauthorized amendment, tampering and >> >>viruses, and we >> >>>>only send and receive e-mails on the basis that we are not >> >>liable for >> >>>>any such corruption, interception, amendment, tampering or >> >>viruses or >> >>>>any consequences thereof. >>>> >>>> >> >>-- >>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 >> >> >>This communication is confidential and intended solely for >>the addressee(s). Any unauthorized review, use, disclosure or >>distribution is prohibited. If you believe this message has >>been sent to you in error, please notify the sender by >>replying to this transmission and delete the message without >>disclosing it. Thank you. >> >>E-mail including attachments is susceptible to data >>corruption, interruption, unauthorized amendment, tampering >>and viruses, and we only send and receive e-mails on the >>basis that we are not liable for any such corruption, >>interception, amendment, tampering or viruses or any >>consequences thereof. >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP 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 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 29 08:34:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21423 for ; Sun, 29 Feb 2004 08:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxR4u-0002kc-Kv for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 08:34:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TDXucc010512 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 08:33:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxR42-0002bO-Aq; Sun, 29 Feb 2004 08:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxR3s-0002aW-G6 for sip@optimus.ietf.org; Sun, 29 Feb 2004 08:32:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21392 for ; Sun, 29 Feb 2004 08:32:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxR3r-0002Vq-00 for sip@ietf.org; Sun, 29 Feb 2004 08:32:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxR2t-0002RR-00 for sip@ietf.org; Sun, 29 Feb 2004 08:31:51 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AxR2f-0002Nk-00 for sip@ietf.org; Sun, 29 Feb 2004 08:31:37 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 24252; Sun, 29 Feb 2004 08:31:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Feb 2004 08:30:38 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A1DA@zoe.office.snowshore.com> Thread-Topic: sip-history-info-02: counter starter Thread-Index: AcP+vojJX8w7oTV0SUaRSqOBxZwBHQ== From: "Eric Burger" To: "Mary H. Barnes (E-mail)" Cc: "SIP List (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] sip-history-info-02: counter starter Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable In section 4.3.3.1, the draft states "The index for this entry is = RECOMMENDED to start at 1." On the one hand, why would the first proxy start at anything other than = 1? On the other hand, I could see doing it for debugging purposes: I set = proxy A to start at 1000 and proxy B to start at 100000, and then I get = an extra level of (non-interoperable, but yet still useful for debugging = purposes) history information. I would either state some reasons why it is only recommended (or = should), or make it a must. Personally, I like debugging stuff, so I = would leave it as is. rjs: I would also plan on a torture test where a proxy receives a = message with a history-info index of, say, 32767 :-) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 29 12:25:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02193 for ; Sun, 29 Feb 2004 12:25:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxUgq-0001ci-Po for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 12:25:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1THPKHs006238 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 12:25:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxUga-0001am-Ju; Sun, 29 Feb 2004 12:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxUgV-0001a0-Cu for sip@optimus.ietf.org; Sun, 29 Feb 2004 12:24:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02135 for ; Sun, 29 Feb 2004 12:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxUgT-0004hC-00 for sip@ietf.org; Sun, 29 Feb 2004 12:24:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxUfW-0004c5-00 for sip@ietf.org; Sun, 29 Feb 2004 12:23:58 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AxUeZ-0004Uk-00 for sip@ietf.org; Sun, 29 Feb 2004 12:22:59 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1THMWNr011104; Sun, 29 Feb 2004 12:22:33 -0500 (EST) Message-ID: <40421FBC.8090807@dynamicsoft.com> Date: Sun, 29 Feb 2004 12:22:04 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] Moving forward on non-invite issues References: <1077135359.2249.102.camel@localhost.localdomain> In-Reply-To: <1077135359.2249.102.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Its late, I'm tired, so there is a good chance that what I am saying below makes no sense. It occurs to me that there is another solution (and I dont recall if we discussed it), which can alleviate many of the problems in the problems draft. The idea is that we define two separate NIT timeouts - one for a client or proxy, and one for a server that generates its own responses (as opposed to forwarding ones generated by others). The server one is 1/2 the size of the client one. We could, for example, keep the client one at 32 and make the server one 16. In this case, a UAS would HAVE to send a 408 if it cant complete the transaction in 16s. However, this 408 will not arrive too late at any upstream elements, since all of them have still 16s remaining. AFAICT, this approach has the following impacts on the problems in your problems draft: 1.1 is solved. You reply immediately, if not, a UAS has to reply within 16s with a 408. The race then becomes possibly if it takes 16 for the response to propagate - if thats a problem, then the noninvite transaction duration itself is too small for that network. 1.2 is not solved. I see this is quite separate from the other problems. TCP does solve it tho. 1.3 is solved. You should get a response now before the transaction completes. 1.4 is solved. 408 is still useful. Its always sent by the uas before the upstream transactions terminate. 1.5 is sort of solved, but not completely. If an element has failed, you'll not get a 408 at all, so the proxy still waits too long to get a response from the failed element. Need to think about that some more. 1.6 is still a problem; thats fundamentally unsolvable without some kind of negotiation or mandatory minimum. This is, to some degree, a vairation on the Timeleft approach in your futures draft. -Jonathan R. Robert Sparks wrote: > All - > > At the request of the chairs, I split the non-invite > draft into three parts : > > - the description of the problems > - the things we seem to have consensus to fix now > - the things we might do in the future but need to > argue over more. > > > The resulting drafts are available in the repository: > http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-problems-00.txt > http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-actions-00.txt > http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-future-00.txt > > > My recommendation is to LC the problems and actions drafts > as soon as it is feasible to do so and send them to the IESG. > > RjS > > ps - if you prefer reading xml2rfc's html output, you > can get that at: > http://www.nostrum.com/~rjsparks/draft-sparks-sip-nit-problems-00.html > http://www.nostrum.com/~rjsparks/draft-sparks-sip-nit-actions-00.html > http://www.nostrum.com/~rjsparks/draft-sparks-sip-nit-future-00.html > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 29 17:05:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12334 for ; Sun, 29 Feb 2004 17:05:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZ3m-0002j3-5W for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 17:05:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TM5IgN010415 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 17:05:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZ3b-0002gC-Fl; Sun, 29 Feb 2004 17:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZ38-0002c8-Cf for sip@optimus.ietf.org; Sun, 29 Feb 2004 17:04:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12269 for ; Sun, 29 Feb 2004 17:04:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZ36-0005w2-00 for sip@ietf.org; Sun, 29 Feb 2004 17:04:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZ2A-0005ko-00 for sip@ietf.org; Sun, 29 Feb 2004 17:03:39 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AxZ0k-0005Nk-00 for sip@ietf.org; Sun, 29 Feb 2004 17:02:10 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1TM1VU01777; Sun, 29 Feb 2004 14:01:32 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Feb 2004 16:01:32 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF579089@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Eric Burger'" Cc: "SIP List (E-mail)" Date: Sun, 29 Feb 2004 16:01:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FF0F.95889C3A" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] RE: sip-history-info-02: counter starter Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3FF0F.95889C3A Content-Type: text/plain That's a good point; I honestly can't remember if there was a specific reason why we had a RECOMMENDED rather than a MUST. But, I don't think it would necessarily cause interoperability problems, it just would make it a bit more difficult for the end applications to handle as they would likely have to normalize the indices back to 1 (I can't see the value in an application in wanting to use or know that different proxies might start at different indices and that certainly wasn't the intent). So, unless someone has a compelling reason why we should keep it as RECOMMENDED, I'll make the change to MUST in the next rev. Mary. -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Sunday, February 29, 2004 7:31 AM To: Barnes, Mary [NGC:B622:EXCH] Cc: SIP List (E-mail) Subject: sip-history-info-02: counter starter In section 4.3.3.1, the draft states "The index for this entry is RECOMMENDED to start at 1." On the one hand, why would the first proxy start at anything other than 1? On the other hand, I could see doing it for debugging purposes: I set proxy A to start at 1000 and proxy B to start at 100000, and then I get an extra level of (non-interoperable, but yet still useful for debugging purposes) history information. I would either state some reasons why it is only recommended (or should), or make it a must. Personally, I like debugging stuff, so I would leave it as is. rjs: I would also plan on a torture test where a proxy receives a message with a history-info index of, say, 32767 :-) ------_=_NextPart_001_01C3FF0F.95889C3A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: sip-history-info-02: counter starter

That's a good point;  I honestly can't remember = if there was a specific reason why we had a RECOMMENDED rather than a = MUST.  But,  I don't think it would necessarily cause = interoperability problems, it just would make it a bit more difficult = for the end applications to handle as they would likely have to = normalize the indices back to 1 (I can't see the value in an = application in wanting to use or know that different proxies might = start at different indices and that certainly wasn't the intent).  = So, unless someone has a compelling reason why we should keep it as = RECOMMENDED, I'll make the change to MUST in the next rev.

Mary.

-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com] =
Sent: Sunday, February 29, 2004 7:31 AM
To: Barnes, Mary [NGC:B622:EXCH]
Cc: SIP List (E-mail)
Subject: sip-history-info-02: counter starter


In section 4.3.3.1, the draft states "The index = for this entry is RECOMMENDED to start at 1."

On the one hand, why would the first proxy start at = anything other than 1?

On the other hand, I could see doing it for debugging = purposes: I set proxy A to start at 1000 and proxy B to start at = 100000, and then I get an extra level of (non-interoperable, but yet = still useful for debugging purposes) history information.

I would either state some reasons why it is only = recommended (or should), or make it a must.  Personally, I like = debugging stuff, so I would leave it as is.

rjs: I would also plan on a torture test where a = proxy receives a message with a history-info index of, say, 32767 = :-)

------_=_NextPart_001_01C3FF0F.95889C3A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Feb 29 17:46:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13786 for ; Sun, 29 Feb 2004 17:46:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZhO-0005Rt-6b for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 17:46:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TMkEnN020882 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 17:46:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZhC-0005Ls-UR; Sun, 29 Feb 2004 17:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZgg-0005EZ-4A for sip@optimus.ietf.org; Sun, 29 Feb 2004 17:45:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13662 for ; Sun, 29 Feb 2004 17:45:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZgd-0001ka-00 for sip@ietf.org; Sun, 29 Feb 2004 17:45:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZfr-0001cT-00 for sip@ietf.org; Sun, 29 Feb 2004 17:44:40 -0500 Received: from brazilnut.cc.columbia.edu ([128.59.59.203] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1AxZet-0001SV-00 for sip@ietf.org; Sun, 29 Feb 2004 17:43:39 -0500 Received: from cs.columbia.edu (UBAHN.dhcp.ietf59.or.kr [218.37.228.104]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i1TMhR6B015085 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 29 Feb 2004 17:43:30 -0500 (EST) Message-ID: <40426B13.60102@cs.columbia.edu> Date: Sun, 29 Feb 2004 17:43:31 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Drage, Keith (Keith)" , "'Tom Taylor'" , "'Christer Holmberg (JO/LMF)'" , "'sip'" , "'Rohan Mahy'" , "'Dean Willis'" Subject: Re: [Sip] Re: INFO Documentation (was Re: Defining new requests) References: <475FF955A05DD411980D00508B6D5FB00B3EF7B2@en0033exch001u.uk.lucent.com> <4041DEA4.4050103@ericsson.com> In-Reply-To: <4041DEA4.4050103@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit At least one possible use case is for location updates during emergency calls. I'll discuss this option during the relevant SIPPING segment. (At this point, I'm not arguing that this is how it should be done, just that it as a plausible option.) Gonzalo Camarillo wrote: > Keith, > > OK, I re-read the thread and I have noticed that you were referencing my > last email. What I actually meant was that we should see whether we > deprecate INFO so that it only transports PSTN stuff, or, on the other > hand, we define INFO packages. We had some discussions about that some > time ago. > > So, we need to discuss which requirements we need to fulfill, and that > should be done in SIPPING. The actual document updating INFO will be > done in SIP, as you suggest. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip